Quand LocalBusiness est adapté
Schema.org définit LocalBusiness comme un établissement physique particulier ou une branche d’une organisation. Il convient donc mieux à une implantation réelle qu’à une activité uniquement en ligne sans établissement local.
Google recommande d’utiliser le sous-type le plus précis lorsqu’il correspond réellement à l’activité : Restaurant, Dentist, Store ou autre type disponible plutôt que rester systématiquement sur LocalBusiness.
Les informations essentielles à garder cohérentes
- Nom réel de l’établissement.
- Adresse postale.
- Téléphone lorsque pertinent.
- URL de la page correspondant à l’établissement.
- Horaires d’ouverture lorsqu’ils sont affichés et maintenus.
- Coordonnées géographiques si elles représentent correctement le lieu.
Données structurées et contenu visible
Le JSON-LD ne doit pas devenir une base d’informations différente de la page. Les données structurées doivent décrire ce que l’utilisateur peut raisonnablement retrouver et vérifier.
Si les horaires, l’adresse ou le téléphone changent, le balisage doit évoluer en même temps que les informations publiques du site.
Schema.org et exigences Google ne sont pas identiques
Schema.org définit un vocabulaire très large. Google utilise une partie de ces propriétés dans ses fonctionnalités et publie ses propres règles d’éligibilité.
Une propriété valide dans Schema.org n’implique donc pas automatiquement un affichage particulier dans Google. Le balisage aide à décrire l’entité mais ne garantit pas un résultat enrichi.
Décrire une implantation locale réelle
LocalBusiness sert à décrire un établissement physique ou une branche locale identifiable. Il est donc particulièrement pertinent lorsque la page présente réellement un lieu avec son adresse, ses horaires et ses informations de contact. Le balisage doit représenter cette réalité et non être ajouté simplement parce qu’une entreprise souhaite renforcer son SEO local.
Une activité exclusivement en ligne n’a pas besoin d’être artificiellement transformée en établissement physique. Commencez par déterminer précisément quelle entité la page représente avant de choisir le type Schema.org.
Choisir le sous-type le plus précis lorsqu’il correspond à l’activité
Schema.org propose des sous-types plus spécifiques pour de nombreuses activités. Lorsqu’un type correspond clairement à l’établissement présenté, il fournit une description plus précise qu’un LocalBusiness générique. Cette précision doit néanmoins rester factuelle et être cohérente avec ce que l’utilisateur voit sur la page.
Ajouter plusieurs types approximatifs ne rend pas automatiquement le balisage plus riche. Une entité correctement décrite avec un type adapté et des propriétés fiables est généralement plus compréhensible qu’un objet contenant des catégories choisies uniquement pour multiplier les signaux.
Distinguer l’organisation de ses établissements
Une entreprise peut posséder plusieurs lieux physiques tout en restant une seule organisation. La marque au niveau global et chaque implantation locale ne décrivent donc pas nécessairement la même entité. Une page d’établissement peut porter l’adresse, le téléphone et les horaires de ce lieu précis, tandis que les informations générales de l’organisation sont gérées à un autre niveau.
Cette distinction évite de réunir plusieurs adresses dans un objet ambigu et facilite les modifications lorsque seul un établissement déménage, ferme temporairement ou change ses horaires.
Maintenir une cohérence avec les informations visibles
Le JSON-LD ne doit pas devenir une base de données parallèle contenant des informations différentes de celles proposées aux visiteurs. Si l’adresse, le téléphone ou les horaires changent, le balisage doit être mis à jour en même temps que la page. Une syntaxe parfaitement valide peut malgré tout décrire une information devenue fausse.
Lors de l’audit, comparez donc les propriétés importantes avec le contenu réellement visible et avec la page locale à laquelle elles se rapportent.
Prévoir la maintenance de plusieurs implantations
Plus une entreprise possède de lieux, plus le risque de données obsolètes augmente. Une procédure simple peut prévoir qu’un changement d’adresse, d’horaires ou de contact entraîne systématiquement le contrôle de la page locale et de son balisage. Cela évite qu’une ancienne information reste cachée dans le code pendant plusieurs mois.
Lorsque plusieurs équipes administrent les établissements, la responsabilité de la mise à jour doit être suffisamment claire pour que les données structurées suivent les changements opérationnels.
Valider sans confondre syntaxe et résultat
Un outil de validation peut signaler une erreur de syntaxe ou une propriété manquante, mais une validation réussie ne garantit pas un affichage particulier dans les résultats. Schema.org définit un vocabulaire large, tandis que les moteurs appliquent leurs propres règles aux fonctionnalités qu’ils prennent en charge.
Le contrôle doit donc distinguer trois choses : JSON-LD syntaxiquement correct, description fidèle de l’établissement et respect des exigences éventuelles de la fonctionnalité recherchée.
Sources officielles utiles
Ces références servent à vérifier les mécanismes décrits. Elles ne garantissent ni positionnement, ni indexation, ni citation par un moteur ou une IA.
Passer du diagnostic à l’action
Un audit SEO permet de repérer les problèmes techniques et structurels réellement présents sur votre site avant de prioriser les corrections. Lancer un audit SEO.
Continuer à comprendre votre visibilité
À lire aussi