Schema LocalBusiness : créer un balisage local fiable sans surpromesse

Le type Schema.org LocalBusiness permet de décrire une entreprise locale dans un format lisible par les machines : nom, adresse, téléphone, URL, horaires et catégorie. Il aide un moteur à interpréter les informations déjà présentes, mais ne crée ni établissement, ni contenu local, ni droit à un résultat enrichi. Ce guide traite exclusivement du balisage JSON-LD. L’optimisation de la fiche Google, les pages « métier + ville » et la conversion d’une page service restent des intentions séparées.

1. Comprenez ce que LocalBusiness dit — et ce qu’il ne fait pas

Schema.org fournit un vocabulaire partagé. LocalBusiness est un sous-type d’Organization et de Place : il sert à décrire une organisation qui possède une dimension locale. Google documente ce type pour communiquer l’adresse, les horaires, des départements et d’autres propriétés. Le code n’est pas un texte caché destiné à répéter des mots-clés ; c’est une représentation structurée des faits accessibles sur la page.

Google précise que le balisage peut rendre une page éligible à certaines présentations, sans garantir qu’elles apparaîtront. L’algorithme, la requête, la qualité du site, les politiques et la disponibilité de la fonctionnalité interviennent. Une validation verte signifie que la syntaxe et les propriétés requises sont reconnues ; elle ne signifie pas que la page sera mieux classée ou qu’un panneau local sera créé.

Le balisage ne remplace pas la gestion d’une fiche Google Business Profile. Il ne rend pas éligible une adresse virtuelle, ne vérifie pas un établissement et ne corrige pas une fiche suspendue. Il complète aussi le contenu visible du site, lequel doit déjà répondre à l’utilisateur. Avant le code, assurez-vous que le projet suit la checklist d’un site professionnel.

2. Placez l’entité sur la page qui la décrit réellement

Google indique que LocalBusiness peut être ajouté à toute page, tout en recommandant une page contenant les informations de l’entreprise. Pour une TPE mono-établissement, la page de contact ou une page « À propos » complète convient souvent. Pour plusieurs implantations, chaque page établissement porte son entité locale. La page d’accueil peut décrire l’organisation ou le siège selon le contenu visible, mais elle ne doit pas déclarer artificiellement toutes les adresses.

Choisissez une URL canonique, publique et indexable. La page doit afficher au minimum le nom et l’adresse utilisés dans le code, ainsi que les coordonnées utiles. Si l’adresse est volontairement masquée parce que l’activité se déplace chez le client, n’ajoutez pas une adresse privée invisible uniquement pour remplir une propriété. Le balisage doit rester cohérent avec la politique de confidentialité et la représentation publique de l’activité.

Évitez d’injecter un LocalBusiness complet sur chaque article de blog et chaque page de service sans raison. La répétition n’ajoute pas d’établissements et complique la maintenance. Une entité correctement identifiée peut être référencée depuis les autres graphes du site. Si le CMS duplique automatiquement le balisage, vérifiez qu’il n’entre pas en conflit avec une extension SEO ou un thème.

La page doit enfin avoir une intention humaine autonome. Pour les zones réellement servies, suivez le guide sur le SEO local « métier + ville » au lieu de créer une entité LocalBusiness par commune.

3. Choisissez le sous-type le plus précis sans inventer une profession

Schema.org propose LocalBusiness puis des sous-types actuels comme Store, Restaurant, Electrician, Plumber, Locksmith ou DaySpa. Google recommande le sous-type le plus précis disponible. Le type générique ProfessionalService est déprécié par Schema.org : ne le choisissez plus pour un nouveau balisage. Parcourez la hiérarchie officielle et sélectionnez le type qui décrit réellement l’activité principale de l’établissement ; à défaut de sous-type adapté, utilisez LocalBusiness sans inventer une profession. N’utilisez pas un restaurant pour un traiteur sans salle uniquement parce que le résultat vous paraît plus attractif.

Une entreprise peut relever de plusieurs types. La documentation Google accepte un tableau de types pour certains cas et donne l’exemple d’une activité cumulant Electrician, Plumber et Locksmith. Utilisez cette possibilité seulement si les activités sont réellement exercées et visibles. Le champ additionalType n’est pas pris en charge de la même manière dans l’exemple Google ; suivez la documentation actuelle plutôt qu’un tutoriel ancien.

Ne confondez pas le type Schema.org avec la catégorie Google Business Profile, le code APE ou l’objet social. Ces référentiels ont des finalités différentes. Le guide sur les identifiants SIREN, SIRET, RNE et code APE montre déjà qu’un code administratif ne résume pas toute l’activité ou le service proposé.

4. Préparez une source de vérité avant d’écrire le JSON

Listez le nom public, l’URL canonique, un identifiant stable, l’adresse, les coordonnées géographiques si elles sont justifiées, le téléphone, les horaires, les images, la gamme de prix lorsqu’elle apporte une information, et les profils officiels. Déterminez qui valide chaque valeur. Les données structurées ne doivent pas être maintenues dans un fichier isolé que l’équipe locale ignore.

Le nom correspond à celui présenté au public, sans slogan ni liste de villes. Le téléphone doit être le moyen principal destiné aux clients, avec indicatif national et régional dans le format international lorsque cela convient. L’URL pointe vers la page de l’établissement, pas une redirection de campagne. L’image doit être accessible, représentative et utilisable par l’entreprise.

L’adresse est un objet PostalAddress. Renseignez streetAddress, addressLocality, postalCode et addressCountry, ainsi que la région lorsque c’est pertinent. Ne mélangez pas le complément d’adresse avec une accroche marketing. Les coordonnées geo demandent une précision suffisante et doivent pointer le lieu réel, pas le centre de la ville ou une zone commerciale plus connue.

Les liens sameAs peuvent identifier des profils officiels qui représentent bien la même entité. Ne les utilisez pas comme catalogue de citations ou de partenaires. Une page d’annuaire incontrôlée n’est pas forcément une identité officielle. Vérifiez régulièrement que chaque URL fonctionne et appartient encore à l’entreprise.

5. Construisez un JSON-LD minimal avant d’ajouter des propriétés

Google recommande généralement JSON-LD pour sa facilité de maintenance. Le bloc est placé dans un élément script de type application/ld+json, dans le head ou le body selon l’architecture. Commencez avec le contexte Schema.org, le type précis, un identifiant, le nom, l’URL, le téléphone et l’adresse. Google indique actuellement name et address comme propriétés requises pour son utilisation LocalBusiness, puis liste d’autres propriétés recommandées.

L’identifiant @id peut être une URL stable suivie d’un fragment, par exemple l’URL de la page établissement avec « #localbusiness ». Il ne doit pas forcément correspondre à une page distincte ; il sert à reconnaître l’entité dans le graphe. Réutilisez exactement le même identifiant lorsque d’autres objets décrivent cette entreprise. Ne changez pas l’@id à chaque refonte visuelle.

{
  "@context": "https://schema.org",
  "@type": "Electrician",
  "@id": "https://exemple.fr/etablissements/nantes#localbusiness",
  "name": "Exemple Électricité",
  "url": "https://exemple.fr/etablissements/nantes",
  "telephone": "+33200000000",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "10 rue Exemple",
    "postalCode": "44000",
    "addressLocality": "Nantes",
    "addressCountry": "FR"
  }
}

Cet exemple est fictif et ne doit pas être copié tel quel. Remplacez chaque valeur par un fait visible, contrôlé et propre à l’établissement. Ajoutez progressivement image, geo, openingHoursSpecification ou priceRange. Une propriété utile et fiable vaut mieux qu’un graphe très long rempli de données approximatives.

Si le CMS produit déjà Organization, WebSite ou BreadcrumbList, reliez les objets au lieu de créer plusieurs entreprises concurrentes. Inspectez le code HTML rendu, pas seulement l’éditeur. Deux extensions peuvent générer chacune un LocalBusiness avec des noms ou adresses différents sans que l’utilisateur le voie.

6. Encodez les horaires comme des données opérationnelles

openingHoursSpecification associe un ou plusieurs jours à une heure d’ouverture et de fermeture. Utilisez un format horaire valide et regroupez les jours qui partagent exactement les mêmes plages. Pour une fermeture complète, la documentation Google montre opens et closes à 00:00. Pour un établissement ouvert toute la journée, elle documente 00:00 à 23:59. Vérifiez la convention actuelle avant chaque implémentation.

Les horaires saisonniers peuvent utiliser validFrom et validThrough. Ils conviennent à une période connue ; ils ne remplacent pas une mise à jour de dernière minute. Si les horaires visibles sur la page changent, le JSON-LD doit changer en même temps. Évitez un calendrier manuel séparé qui finit par diverger.

Une activité uniquement sur rendez-vous ne doit pas annoncer une disponibilité publique continue si ce n’est pas vrai. Expliquez le fonctionnement dans le contenu visible, puis ne balisez que ce que le vocabulaire décrit sans ambiguïté. Une donnée structurée n’est pas l’endroit pour détailler toutes les règles de réservation.

Le téléphone, les horaires et le parcours de contact influencent l’expérience réelle. Si l’équipe ne peut pas répondre en continu, organisez le rappel grâce aux méthodes de délai de réponse annoncé et de politique de rappel en équipe, sans afficher une disponibilité fictive.

7. Créez une entité distincte pour chaque établissement réel

Google demande de définir chaque emplacement comme un type LocalBusiness. Sur un réseau, chaque page établissement porte son propre @id, son adresse, son téléphone, ses horaires et son URL. La marque ou l’organisation commune peut être décrite séparément puis reliée selon le modèle choisi. Ne placez pas toutes les adresses dans un seul objet LocalBusiness comme s’il s’agissait d’un même lieu.

Un département peut utiliser la propriété department lorsqu’il possède des caractéristiques distinctes, comme des horaires ou un numéro propres. La documentation Google donne l’exemple d’une pharmacie dans un magasin et prévoit des règles de nommage. N’utilisez pas department pour transformer chaque service commercial en établissement indépendant.

Le balisage suit l’architecture, il ne la décide pas. Construisez d’abord les pages et la gouvernance avec le guide du SEO local multi-établissements. Ensuite seulement, associez une entité par page. Si un lieu ferme ou déménage, traitez l’URL et la fiche avant de mettre à jour le JSON-LD.

8. Validez la syntaxe, l’éligibilité et le rendu réellement indexable

Le test des résultats enrichis de Google indique si le balisage est reconnu pour les fonctionnalités prises en charge et signale erreurs et avertissements. Le validateur Schema.org contrôle plus largement le vocabulaire. Utilisez les deux : un code peut être valide selon Schema.org mais non exploité par une fonctionnalité Google, ou contenir une propriété supportée avec un format incorrect.

Corrigez toutes les erreurs critiques. Pour les avertissements, demandez si la propriété manque réellement ou ne s’applique pas à votre activité. N’inventez jamais une gamme de prix, une image ou des coordonnées pour obtenir un voyant vert. Contrôlez aussi la page avec l’inspection d’URL de Search Console, car un code ajouté par JavaScript peut ne pas apparaître comme prévu dans le HTML rendu.

Déployez d’abord sur une ou deux pages. Testez l’URL publiée, pas seulement un extrait collé dans l’outil. Comparez les valeurs structurées avec le contenu visible, le canonical et la fiche locale. Soumettez le sitemap existant selon le processus normal ; la présence d’un balisage ne justifie pas de demander manuellement l’indexation de toutes les pages.

9. Écartez les raccourcis qui fragilisent la confiance

Ne balisez pas une adresse invisible ou fictive, un service non proposé, un horaire théorique, un numéro de campagne périmé ou une ville simplement desservie. N’utilisez pas le champ name comme liste de mots-clés. Les données doivent représenter le contenu principal et être à jour. Google peut ignorer le balisage ou appliquer une action manuelle lorsqu’il enfreint les règles.

Soyez particulièrement prudent avec review et aggregateRating. La documentation LocalBusiness de Google précise que la note agrégée est recommandée pour les sites qui recueillent des avis sur d’autres entreprises. Les avis « auto-hébergés » par l’entreprise à propos d’elle-même ne sont pas éligibles aux étoiles de type LocalBusiness ou Organization selon les règles de snippets d’avis. N’ajoutez pas des avis invisibles, déplacés ou provenant d’une autre agence.

Ne confondez pas erreur de validation et problème SEO général. Une page peut ne pas recevoir de trafic malgré un JSON-LD parfait parce qu’elle ne répond pas à une demande, n’est pas maillée ou duplique une autre page. À l’inverse, une page utile peut être indexée sans données structurées. Le code clarifie ; il ne remplace pas la proposition éditoriale.

10. Reliez la maintenance aux événements de l’entreprise

Créez une checklist déclenchée par un changement d’adresse, de téléphone, d’horaire, de nom, de site, de catégorie ou d’établissement. La même demande met à jour le contenu visible, le JSON-LD, la fiche locale et les supports essentiels. Conservez la date, la personne qui valide et les URL testées.

Une fois par trimestre, explorez quelques pages avec le test des résultats enrichis et le validateur Schema.org. Surveillez les rapports Search Console disponibles sans conclure qu’une absence de rapport signifie une pénalité. Les fonctionnalités et propriétés reconnues évoluent ; revenez à la documentation officielle avant d’ajouter une propriété suggérée par un plugin.

Documentez enfin la propriété du code. Le prestataire peut implémenter, mais l’entreprise doit savoir où se trouve le modèle, quelles données l’alimentent et comment le désactiver en cas de conflit. Lors d’un changement de CMS, incluez les données structurées dans le plan de migration et de recette.

Sources officielles et primaires : Google Search Central — données structurées LocalBusiness ; Google Search Central — règles générales des données structurées ; Schema.org — définition et propriétés de LocalBusiness ; Schema.org — dépréciation de ProfessionalService ; Google — test des résultats enrichis ; Schema.org — validateur officiel. Consultées le 3 août 2026. Les propriétés prises en charge et les présentations de résultats peuvent évoluer ; aucune donnée structurée ne garantit un résultat enrichi ni une position.

En résumé

Un bon Schema LocalBusiness est court, exact et maintenable. Il décrit l’entité visible sur la page, choisit le type le plus précis, utilise une identité stable et traite chaque établissement réel séparément. Les validateurs contrôlent la syntaxe et l’éligibilité technique, jamais la véracité ni un gain de classement. La maintenance doit suivre chaque changement opérationnel.