Générateur de schema LocalBusiness

Comment générer le schema LocalBusiness

Un établissement par page, une page par établissement. Le générateur écrit le balisage et le bloc visible à partir des mêmes valeurs, pour qu'ils ne divergent jamais.

1. Choisissez le type le plus précis. Bakery, Restaurant, Dentist, Plumber et les autres sont des sous-types de LocalBusiness et en héritent tout. LocalBusiness ne sert que si rien de plus précis ne convient.
2. Renseignez le nom et l'adresse à la française. Ce sont les deux seules propriétés obligatoires. Numéro et voie dans streetAddress, code postal à cinq chiffres dans postalCode, commune dans addressLocality, FR dans addressCountry.
3. Écrivez les horaires en règles, une par ligne. Jours en français ou en anglais : le balisage écrira de toute façon Monday. Une coupure du midi fait deux lignes ; un bar ouvert le samedi de 18:00 à 02:00 n'en fait qu'une ; des congés annuels sont une plage de dates suivie de fermé.
4. Lisez les avertissements avant de copier. Coordonnées trop peu précises, gamme de prix trop longue, partie d'adresse manquante, plages qui se chevauchent le même jour : chacun est une chose que Google ignore ou lit autrement que prévu.
5. Collez les deux sorties. Le JSON-LD va dans la page de l'établissement ; le bloc d'adresse et le tableau des horaires, là où les visiteurs les lisent. Régénérez les deux à chaque changement d'horaires.

L'adresse et le téléphone, au format français

Un générateur de schema LocalBusiness transforme les informations d'un établissement en données structurées LocalBusiness au format JSON-LD — le balisage que Google lit pour les horaires, l'adresse et les services d'un établissement local. Deux propriétés seulement sont obligatoires, name et address ; tout le reste est recommandé. La difficulté française est ailleurs : dans la façon d'écrire l'adresse, le téléphone et les horaires.

• Code postal, puis commune. La Poste place le code postal et la localité sur la même ligne, la dernière de l'adresse, et le code postal compte cinq chiffres en France comme outre-mer. Dans le balisage, chaque partie a sa propriété : streetAddress « 12 rue d'Austerlitz », postalCode « 69004 », addressLocality « Lyon », addressCountry « FR ».
• La région est facultative. L'adresse postale française n'a pas de ligne région : addressRegion peut rester vide, ou porter la région si vous suivez à la lettre la consigne de Google d'inclure autant de propriétés que possible. Le générateur ne réclame que la voie, la commune et le pays.
• Le téléphone en +33. Le plan de numérotation de l'ARCEP distingue le format national, qui commence par 0, du format international, +33 suivi du numéro sans ce 0 : 04 65 71 23 45 devient +33 4 65 71 23 45. Le numéro de l'exemple appartient à un bloc que l'ARCEP réserve aux œuvres audiovisuelles : il ne peut ni appeler ni être appelé.

Le bloc visible liste, sous l'intitulé « Adresse », les parties dans l'ordre des propriétés — voie, commune, code postal, pays. Sur la page, présentez-les dans l'ordre postal, 12 rue d'Austerlitz, 69004 Lyon : mêmes valeurs, autre ordre.

Horaires : coupure du midi, minuit passé, jours fermés

Pour dayOfWeek, Google accepte les valeurs de schema.org — Monday pour lundi — ou leurs noms courts, pas une traduction : le JSON-LD écrit donc toujours les jours en anglais. Le formulaire, lui, lit les abréviations françaises (lun, mar… dim, ou le nom complet) comme les anglaises, fermé comme closed, et 24h pour un jour sans fermeture. Un commerce avec coupure du midi s'écrit ainsi :

mar-sam 09:00-12:30          # le matin
      mar-sam 14:30-19:00          # l'après-midi : la coupure fait deux lignes
      dim     fermé                # opens et closes à 00:00
      lun     fermé
      2027-08-02..2027-08-22 lun-dim fermé    # congés annuels : validFrom / validThrough

La coupure produit deux spécifications pour les mêmes jours ; la fiche d'établissement Google procède de même, avec plusieurs plages horaires saisies en entrées séparées pour un jour donné. Le générateur ne signale un jour répété que si ses plages se chevauchent, ou si l'une des lignes le déclare fermé : là, les deux règles se contredisent vraiment.

Trois encodages viennent directement de la documentation de Google. Fermé toute la journée : opens et closes valent tous deux 00:00. Ouvert 24 h/24 : 00:00 et 23:59. Et pour les horaires dépassant minuit — un bar ouvert le samedi de 18 h à 2 h —, une seule OpeningHoursSpecification, sam 18:00-02:00, et non une règle jusqu'à 23:59 suivie d'une autre dès 00:00, que l'outil signale.

Congés annuels : le balisage et la fiche d'établissement ne l'écrivent pas pareil

Fermer trois semaines en août, c'est dans le balisage une spécification datée : Google définit validFrom et validThrough comme le début et la fin d'une fermeture saisonnière, au format AAAA-MM-JJ, et son propre exemple est une entreprise fermée pendant les vacances d'hiver. La ligne 2027-08-02..2027-08-22 lun-dim fermé du formulaire produit exactement cela, à côté des horaires habituels, qui restent valables le reste de l'année.

Dans la fiche d'établissement Google, la même fermeture ne passe pas par les horaires exceptionnels : l'aide de Google les réserve aux ajustements et fermetures de six jours consécutifs au maximum, et demande de marquer l'établissement comme temporairement fermé à partir de sept jours. Pour les jours fériés, elle conseille de confirmer ses horaires même quand ils ne changent pas. Deux surfaces, deux écritures : mettez-les à jour ensemble, avec les mêmes dates.

Ce que le balisage ne remplace pas

Le balisage décrit l'établissement sur votre site ; pour le classement local, c'est la fiche d'établissement Google que son aide présente comme le levier. Elle explique que les résultats à proximité reposent principalement sur la pertinence, la distance et la popularité, et rappelle qu'il n'existe aucun moyen d'obtenir une meilleure place contre rémunération. D'où une règle simple : nom, adresse, téléphone et horaires identiques dans la fiche et dans le JSON-LD.

Ce qui mérite d'être juste dans le balisage, parce que Google en écrit la conséquence :

• La précision des coordonnées. Au moins cinq décimales pour latitude et longitude, avec un point ; l'outil avertit en dessous.
• La gamme de prix. La documentation française donne elle-même 10-15 € ou €€€ en exemple, en moins de 100 caractères, faute de quoi Google n'affiche aucune gamme de prix.
• Le nom des services. Un department se nomme {store name} {department name} — gMart et gMart Pharmacy dans l'exemple de Google —, sauf s'il porte sa propre marque.
• Un @id par établissement. Google n'en parle pas, mais dès que le site compte plusieurs boutiques, un @id stable par page évite que d'autres lecteurs du JSON-LD — agrégateurs, extensions, agents — fusionnent deux adresses. Une page par établissement, un nœud par page.

Les étoiles de votre propre établissement : non

La case en bas du formulaire existe pour être refusée. Les consignes de Google sur les extraits d'avis sont nettes : si l'entité évaluée contrôle les avis la concernant, les pages LocalBusiness ou Organization ne peuvent pas bénéficier d'étoiles, y compris quand les avis passent par un widget tiers intégré, comme celui des avis Google sur l'établissement. Les propriétés review et aggregateRating de LocalBusiness ne sont recommandées que pour les sites qui recueillent des avis sur d'autres établissements locaux : un annuaire, un guide. Le détail, droit français compris, est sur le générateur de schema avis.