Les données structurées LocalBusiness servent à décrire une entreprise locale dans un format que les moteurs de recherche peuvent interpréter plus facilement. Pour une TPE, l’objectif n’est pas d’ajouter une couche technique invisible pour « faire du SEO ». Le bon objectif est plus simple : faire correspondre le code, les pages visibles et les profils publics de l’entreprise.
Concrètement, LocalBusiness peut aider à clarifier le nom de l’établissement, son adresse, son téléphone, son site, ses horaires, ses services, ses profils officiels et parfois sa zone d’intervention. Mais ces informations doivent rester fidèles à ce que le visiteur peut vérifier sur la page. Google rappelle dans ses règles générales sur les données structurées qu’un balisage correct ne garantit pas l’affichage d’un résultat enrichi, et que les données doivent représenter le contenu principal visible.
La méthode saine consiste donc à partir de vos informations réelles, à les afficher clairement sur le site, puis à les traduire en JSON-LD, le format recommandé par Google pour les données structurées.
Comprendre le rôle de LocalBusiness
LocalBusiness est un type défini par Schema.org pour représenter une entreprise locale ou un établissement rattaché à une organisation. Il peut s’agir d’un restaurant, d’un salon, d’un artisan, d’un cabinet, d’une agence ou d’un commerce physique. Schema.org propose aussi des sous-types plus précis, mais une TPE n’a pas toujours besoin de chercher la catégorie parfaite dès le départ.
Le rôle de ce balisage est descriptif. Il indique à une machine : voici l’entreprise dont parle cette page, voici ses coordonnées, voici où elle se situe ou intervient, voici comment la contacter. Il ne remplace pas le contenu éditorial, la page contact, la fiche Google Business Profile ni les informations légales.
Sur un site de petite entreprise, LocalBusiness est surtout utile lorsque le site présente une activité liée à une zone géographique. C’est le cas d’un artisan qui intervient dans plusieurs villes, d’un restaurant qui reçoit dans un quartier, d’un commerçant avec boutique, d’une profession libérale sur rendez-vous ou d’une agence qui cible un territoire.
Si votre site vend uniquement un service national ou 100 % en ligne, une donnée structurée Organization peut parfois être plus adaptée que LocalBusiness. Le choix dépend de ce que la page décrit réellement.
Commencer par les informations visibles
Avant d’écrire le moindre JSON-LD, vérifiez que les informations importantes sont visibles sur le site. Un balisage LocalBusiness ne doit pas contenir une adresse, un service, une zone ou un horaire que l’utilisateur ne retrouve nulle part.
Pour une TPE, la base visible à contrôler est la suivante :
- nom commercial utilisé auprès des clients ;
- raison sociale si elle est pertinente pour les mentions ou la confiance ;
- activité principale ;
- adresse publique, ou zone desservie si l’adresse n’est pas destinée à recevoir du public ;
- téléphone ou moyen de contact principal ;
- horaires d’accueil, d’ouverture ou de réponse ;
- URL du site ;
- page contact ;
- services réellement proposés ;
- profils publics utiles, par exemple fiche Google, réseau social professionnel ou plateforme de réservation.
Cette étape rejoint un principe déjà abordé dans notre méthode pour rendre les informations de l’entreprise compréhensibles par les IA : les systèmes automatisés traitent mieux une information stable, explicite et vérifiable. Le même principe vaut pour les visiteurs humains. Une adresse cachée dans le pied de page, un ancien numéro sur la fiche Google et une zone différente sur la page service créent de la confusion.
Si vous avez une seule action à faire avant le balisage, faites celle-ci : créez une fiche interne de référence avec le nom exact, les coordonnées, les horaires, la zone, les services et les liens publics. Ensuite, alignez le site et les profils externes sur cette fiche.
Choisir les propriétés utiles pour une TPE
La documentation Google sur les données structurées Local Business s’appuie sur le vocabulaire Schema.org et donne des exemples de propriétés selon les cas. Pour une petite entreprise, il vaut mieux commencer avec un balisage sobre, exact et maintenable plutôt qu’un bloc trop ambitieux qui sera vite faux.
Les propriétés les plus utiles sont souvent :
| Propriété | À quoi elle sert | À vérifier côté page |
|---|---|---|
@type |
indique le type d’entité, par exemple LocalBusiness ou un sous-type |
le type correspond à l’activité réelle |
name |
nom de l’entreprise ou de l’établissement | même nom sur le site et les profils publics |
url |
URL canonique du site ou de la page | URL accessible et indexable |
telephone |
téléphone principal | numéro visible et actuel |
address |
adresse structurée avec PostalAddress |
adresse publique cohérente |
openingHoursSpecification |
horaires structurés | horaires visibles ou faciles à vérifier |
areaServed |
zone desservie | zone annoncée clairement sur la page |
sameAs |
liens vers profils officiels | profils réellement contrôlés par l’entreprise |
image ou logo |
image représentative | image accessible et pertinente |
Schema.org détaille le type PostalAddress, utile pour séparer la rue, le code postal, la ville et le pays. Cette structure réduit les ambiguïtés par rapport à une adresse écrite en bloc libre.
Il n’est pas nécessaire de tout renseigner. Une propriété absente vaut mieux qu’une propriété approximative. Par exemple, si vos horaires varient souvent et que vous ne les maintenez pas sur le site, évitez de publier des horaires figés dans le JSON-LD. Si vos prix dépendent de chaque projet, n’ajoutez pas une grille artificielle.
Garder la cohérence avec Google Business Profile
Pour une entreprise locale, la fiche Google Business Profile est souvent l’une des sources publiques les plus consultées. Les consignes Google Business Profile demandent de représenter l’établissement tel qu’il existe réellement. C’est exactement le niveau d’exigence à reprendre sur le site.
Comparez au minimum :
- le nom de l’établissement ;
- la catégorie principale ;
- l’adresse ou la zone desservie ;
- le numéro de téléphone ;
- les horaires ;
- le lien vers le site ;
- les services ;
- les photos principales ;
- les liens de prise de rendez-vous ou de réservation.
Notre article sur la manière de relier son site à sa fiche Google Business Profile donne une base de contrôle. Le point important ici est d’éviter les versions concurrentes d’une même entreprise. Si votre fiche Google indique « Agence Digi Paris », votre site « Agence Digi » et votre JSON-LD une autre appellation, vous compliquez inutilement l’interprétation.
La cohérence ne veut pas dire copier tout le contenu de la fiche. Le site doit rester la source la plus complète : pages services, preuves, méthode, contact, réalisations, FAQ si elle est utile. La fiche locale doit surtout confirmer les informations opérationnelles et renvoyer vers la bonne page.
Placer le balisage sur les bonnes pages
Le balisage doit être placé sur la page qu’il décrit. Pour une TPE avec un seul établissement, on peut souvent l’ajouter sur la page d’accueil et/ou la page contact, à condition que ces pages présentent bien l’entreprise. Pour une activité avec plusieurs établissements, il faut plutôt créer une page par établissement et associer chaque balisage à la bonne adresse.
Évitez trois erreurs fréquentes :
- mettre la même adresse sur toutes les pages locales alors que chaque page ne décrit pas un établissement distinct ;
- déclarer une zone très large sans preuve de présence, de service ou de contenu utile ;
- ajouter des avis, notes ou services dans le JSON-LD alors qu’ils ne sont pas visibles sur la page.
Si vous développez des pages par ville, reprenez d’abord une méthode éditoriale propre pour créer une page locale utile sans contenu dupliqué. Le JSON-LD arrive ensuite pour préciser ce qui existe réellement sur la page : ville, service, contact, établissement ou zone desservie.
Pour une page service, le balisage LocalBusiness n’est pas toujours le seul élément pertinent. Une page peut aussi contenir une structure de page, un fil d’Ariane ou un contenu éditorial. Mais il faut éviter l’empilement technique sans logique. Le balisage principal doit correspondre au sujet principal de l’URL.
Exemple simple de JSON-LD à adapter
Voici un exemple volontairement limité. Il montre la logique, pas un modèle universel à copier :
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "LocalBusiness",
"@id": "https://www.exemple.fr/#localbusiness",
"name": "Entreprise Exemple",
"url": "https://www.exemple.fr/",
"telephone": "+33123456789",
"address": {
"@type": "PostalAddress",
"streetAddress": "10 rue Exemple",
"postalCode": "75000",
"addressLocality": "Paris",
"addressCountry": "FR"
},
"areaServed": "Paris et proche couronne",
"sameAs": [
"https://www.google.com/maps?cid=0000000000000000000"
]
}
</script>
Avant de l’utiliser, adaptez-le à votre situation réelle. Si vous ne recevez pas à cette adresse, ne la présentez pas comme une adresse ouverte au public. Si vous intervenez seulement sur rendez-vous, dites-le dans le contenu visible. Si vous avez plusieurs établissements, ne mélangez pas leurs adresses dans un seul bloc.
La documentation d’introduction de Google sur les données structurées rappelle que le vocabulaire Schema.org donne le cadre, mais que les règles propres à Google Search déterminent l’éligibilité aux fonctionnalités de recherche. Autrement dit : un JSON-LD techniquement valide ne suffit pas si le contenu est trompeur, incomplet ou incohérent.
Contrôler sans promettre de résultat
Une fois le balisage ajouté, contrôlez trois niveaux.
D’abord, contrôlez la cohérence humaine. Le visiteur doit voir les mêmes informations que celles décrites dans le JSON-LD : entreprise, adresse, horaires, zone, contact, services. C’est le contrôle le plus important.
Ensuite, contrôlez la technique. La page doit être accessible, indexable, rapide à charger et présente dans le sitemap si elle doit être découverte. Les informations importantes ne doivent pas être bloquées par robots.txt, masquées derrière une connexion ou uniquement affichées dans une image.
Enfin, contrôlez la maintenance. À chaque changement d’adresse, de téléphone, d’horaire ou d’offre, mettez à jour le site, la fiche Google Business Profile et le JSON-LD dans la même séquence. C’est souvent là que les petites entreprises perdent la cohérence au fil du temps.
Les données structurées peuvent améliorer la compréhension d’une page, mais elles ne garantissent pas un résultat enrichi, un meilleur classement ou une citation par un assistant. Elles doivent être vues comme une couche de clarification au service d’un contenu déjà propre.
Prochaine étape
Prenez la page contact et la page d’accueil. Vérifiez que le nom, l’activité, la zone, les coordonnées et les horaires sont visibles, exacts et cohérents avec votre fiche Google. Ensuite seulement, ajoutez un JSON-LD LocalBusiness sobre avec les mêmes informations.
Si vous trouvez une contradiction, corrigez d’abord le contenu visible. Un balisage local efficace n’est pas celui qui en dit le plus, mais celui qui décrit précisément une entreprise réelle, accessible et compréhensible.