Schema LocalBusiness: comment ajouter les données structurées pour le SEO local?

En bref: le balisage LocalBusiness décrit votre établissement à Google dans un format lisible par une machine, à condition de refléter fidèlement la page. Il rend éligible à certaines présentations enrichies, mais il ne promet ni affichage ni gain de classement direct.

Ce guide déroule une implémentation complète en six étapes, du choix du type au contrôle de l'exploration, avec un exemple de code réel pour un commerce fictif. Chaque étape commence par l'action à réaliser, puis précise les détails utiles et les pièges.

Ce que le schema LocalBusiness apporte (et ce qu'il ne promet pas)

Le balisage LocalBusiness est un ensemble de données structurées, c'est-à-dire des informations écrites dans un vocabulaire normalisé (Schema.org) que les moteurs lisent sans interprétation. Il permet de communiquer à Google des données sur un établissement: horaires, départements, et dans certains cas des avis. Selon Google Search Central, ces données doivent concerner l'établissement lui-même et respecter les consignes de Google.

Ses limites sont tout aussi importantes. Un balisage valide peut rendre une page éligible à certaines présentations enrichies, sans garantir leur affichage. L'affichage dépend du contexte de recherche, de la localisation, de l'appareil et de la pertinence des données. Il n'existe pas non plus de gain de classement direct promis par ce balisage.

À noter

Une action manuelle de Google visant les données structurées retire l'éligibilité aux présentations enrichies. Elle n'affecte pas, en revanche, le classement de la page dans la recherche Web.

Ce balisage est donc une brique de précision, pas un levier à lui seul. Il s'intègre dans une démarche plus large, détaillée dans notre guide sur la méthode complète de SEO local sur Google. Ici, nous nous concentrons sur le code et sa mise en place.

Prérequis avant d'écrire le code

Avant de toucher au JSON-LD, vérifiez qu'une page décrit réellement l'établissement, avec ses informations visibles: nom, adresse, téléphone, horaires. Le balisage doit en être le reflet, jamais l'unique source. Côté budget, rien à prévoir: le balisage est gratuit, et le seul coût est le temps de mise en place et de vérification.

Données à rassembler

Rassemblez les valeurs exactes dans un document de travail, en les copiant depuis la page publiée plutôt qu'en les ressaisissant de mémoire.

• le nom de l'établissement, tel qu'il apparaît sur la page;

• l'adresse postale complète;

• le téléphone avec indicatif pays;

• l'URL complète de la page;

• les horaires habituels;

• les coordonnées GPS (latitude et longitude).

Accès techniques et outils

Il vous faut un accès à l'édition du HTML, au CMS ou au gestionnaire de balises. Prévoyez aussi les deux outils de test gratuits que nous utiliserons à l'étape 6: le Rich Results Test et le Schema Markup Validator.

Étape 1: choisir le bon type et créer un objet par établissement

Commencez par identifier le type Schema.org qui décrit votre activité. C'est une décision de modélisation: elle conditionne la lecture de tout le reste.

Sous-type le plus précis

Utilisez le sous-type LocalBusiness le plus spécifique correspondant à l'activité, par exemple Restaurant, DaySpa ou HealthClub, plutôt que le type générique lorsqu'un sous-type existe. Condition essentielle: le type choisi doit décrire réellement l'activité de l'établissement. Un type plus précis n'est pas un avantage s'il est inexact.

Un objet par localisation

Chaque localisation d'une entreprise locale se déclare comme un objet LocalBusiness distinct. Pour une enseigne présente dans plusieurs villes, un seul objet « enseigne » regroupant toutes les adresses brouille l'information. Chaque établissement reçoit son nom, son adresse, ses horaires et son téléphone.

Plusieurs types d'activité

Si l'établissement exerce réellement plusieurs activités, déclarez un tableau dans @type, par exemple Electrician, Plumber et Locksmith. D'après Google, additionalType n'est pas pris en charge dans ce cas. Gardez cette option pour des activités effectives, pas pour élargir artificiellement votre couverture.

Dernier repère: LocalBusiness est un sous-type de Organization. Cette filiation prépare l'étape des propriétés complémentaires, que nous retrouverons dans les conseils de maintenance.

Étape 2: renseigner les propriétés requises et recommandées

Remplissez d'abord les deux propriétés que Google liste comme requises, puis ajoutez les compléments recommandés qui s'appliquent à votre cas. Le tableau ci-dessous les distingue.

Une règle de bon sens s'applique à tout: n'ajoutez que les informations applicables et cohérentes avec celles visibles sur la page. Une propriété vide ou approximative fait plus de tort qu'une propriété absente.

Nom et adresse postale

L'adresse doit être un objet PostalAddress décrivant l'emplacement physique. Décomposez-la en rue, ville, code postal et pays plutôt qu'en une seule chaîne de texte. Elle doit correspondre au lieu réellement décrit par la page, pas à une adresse de domiciliation sans lien avec l'accueil du public.

Téléphone et URL

L'URL doit être complète et fonctionnelle, protocole inclus. Le téléphone doit comporter l'indicatif pays et l'indicatif régional, sous la forme internationale. Un numéro écrit comme on le compose depuis chez soi laisse la machine deviner le pays.

Étape 3: encoder les horaires, les coordonnées, les départements et les horaires spéciaux

Traduisez maintenant les informations pratiques en propriétés structurées. C'est l'étape où les erreurs de format sont les plus nombreuses, car chaque champ attend une syntaxe précise.

Horaires par jour

Déclarez les horaires avec openingHoursSpecification, sous forme d'objet ou de tableau. Créez un bloc par plage de jours partageant les mêmes heures. Les heures d'ouverture et de fermeture suivent le format hh:mm:ss dans la référence Google, par exemple 07:00:00. Les horaires doivent décrire le lieu réel et rester alignés sur ceux affichés à l'écran.

Coordonnées GPS

La propriété geo contient une latitude et une longitude avec au moins cinq décimales de précision. Récupérez-les depuis un outil cartographique en vérifiant qu'elles pointent bien sur l'entrée de l'établissement, pas sur le centre de la commune.

Départements et horaires spéciaux

La propriété department sert à déclarer une entité réellement distincte au sein de l'établissement, par exemple une pharmacie dans un magasin, avec ses informations propres (nom, horaires, téléphone). N'en créez pas pour de simples rayons ou services sans identité autonome.

Pour déroger aux horaires habituels, utilisez specialOpeningHoursSpecification: fermeture saisonnière, jour férié, horaires exceptionnels. Ces horaires remplacent les horaires généraux sur la période concernée, que vous délimitez par des dates. Pour la façon d'exprimer une fermeture sur la journée entière, consultez la référence Google au moment de coder.

Étape 4: assembler le JSON-LD complet d'un établissement

Assemblez les propriétés dans une balise script de type application/ld+json. Google recommande JSON-LD parmi les trois formats pris en charge (JSON-LD, Microdata et RDFa). Le choix du format ne dispense pas de respecter les propriétés et règles propres à LocalBusiness.

Notre exemple concerne un commerce fictif: une boulangerie lyonnaise, donc le sous-type Bakery. Les coordonnées, le numéro et l'URL sont inventés pour l'illustration.

Version minimale

La version minimale valide ne contient que name et address, les deux propriétés requises.

<script type="application/ld+json">
{
 "@context": "https://schema.org",
 "@type": "Bakery",
 "name": "Boulangerie Les Trois Épis",
 "address": {
 "@type": "PostalAddress",
 "streetAddress": "12 rue des Halles",
 "addressLocality": "Lyon",
 "postalCode": "69001",
 "addressCountry": "FR"
 }
}
</script>

Elle est correcte, mais elle laisse Google sans horaires, sans téléphone et sans coordonnées précises.

Version complète

La version enrichie ajoute les compléments recommandés.

<script type="application/ld+json">
{
 "@context": "https://schema.org",
 "@type": "Bakery",
 "name": "Boulangerie Les Trois Épis",
 "url": "https://www.example.fr/boulangerie-lyon",
 "telephone": "+33-4-78-00-00-00",
 "address": {
 "@type": "PostalAddress",
 "streetAddress": "12 rue des Halles",
 "addressLocality": "Lyon",
 "postalCode": "69001",
 "addressCountry": "FR"
 },
 "geo": {
 "@type": "GeoCoordinates",
 "latitude": 45.76700,
 "longitude": 4.83500
 },
 "openingHoursSpecification": [
 {
 "@type": "OpeningHoursSpecification",
 "dayOfWeek": ["Tuesday", "Wednesday", "Thursday", "Friday", "Saturday"],
 "opens": "07:00:00",
 "closes": "19:30:00"
 },
 {
 "@type": "OpeningHoursSpecification",
 "dayOfWeek": "Sunday",
 "opens": "07:00:00",
 "closes": "13:00:00"
 }
 ]
}
</script>

Lisons-le dans l'ordre. @context indique le vocabulaire Schema.org, et @type précise le sous-type le plus spécifique. name et address reprennent le minimum requis, avec une adresse décomposée. url et telephone respectent l'URL complète et l'indicatif pays. geo affiche cinq décimales. Enfin, le tableau d'horaires contient un bloc pour les jours partageant les mêmes heures, et un second pour le dimanche.

Ce qui apporte une vraie valeur? Les horaires, le téléphone et les coordonnées, car ce sont les informations que les internautes cherchent sur un lieu. Le lundi n'apparaît pas: l'établissement est fermé ce jour-là, et l'absence de bloc le traduit.

Étape 5: placer le balisage sur la bonne page

Placez le JSON-LD sur la page qu'il décrit. LocalBusiness peut être ajouté à n'importe quelle page du site, mais il est plus pertinent là où figurent les informations de l'entreprise ou de la localisation concernée. Ne créez jamais une page vide uniquement pour héberger des données structurées.

Page d'accueil ou page de localisation

Pour un établissement unique, la page d'accueil ou la page de contact porte naturellement l'objet. Pour une entreprise multi-établissements, prévoyez une page par localisation, chacune avec son propre objet. Dans les projets que nous accompagnons, c'est souvent là que se révèle la qualité de l'architecture: une page locale qui n'a rien de propre à dire se balise mal.

JSON-LD injecté en JavaScript

Le JSON-LD peut être généré par JavaScript, via un CMS, un framework ou un gestionnaire de balises. Dans ce cas, testez l'URL publiée et vérifiez le HTML rendu, afin de confirmer que Google peut explorer et traiter le balisage. Cette précaution compte surtout pour les balisages injectés côté client.

Étape 6: tester le balisage et contrôler l'exploration

Testez avant et après la mise en ligne, avec deux outils aux rôles différents, puis contrôlez que Google peut accéder aux pages.

Les deux validateurs

Le Rich Results Test vérifie l'éligibilité aux fonctionnalités de résultats enrichis de Google. Le Schema Markup Validator contrôle plus largement le vocabulaire Schema.org, y compris les types sans validation spécifique à Google. Utilisez les deux: l'un répond à « Google peut-il en faire quelque chose? », l'autre à « mon vocabulaire est-il correct? ».

Point de vigilance

Un test sans erreur ne garantit pas l'affichage dans les résultats de recherche. Il confirme que le code est lisible et éligible, rien de plus.

Inspection d'URL et recrawl

Après le déploiement, testez quelques pages avec l'outil d'inspection d'URL de la Search Console. Vérifiez qu'elles ne sont bloquées ni par robots.txt, ni par une balise noindex, ni par une connexion obligatoire. Si nécessaire, demandez un nouveau crawl. Google précise que la découverte, l'exploration et la réindexation peuvent prendre plusieurs jours: inutile de multiplier les demandes dès le lendemain.

Les erreurs fréquentes à éviter

Voici les pièges que l'on rencontre le plus souvent lors des audits, regroupés par nature.

• Balisage non conforme au contenu visible: horaires, nom, adresse, téléphone, URL ou prestations différents de ceux de la page, contenu masqué ou sans rapport, données périmées. Google demande des données visibles, exactes, pertinentes et à jour.

• Type mal choisi: type générique alors qu'un sous-type existe, un seul objet pour plusieurs établissements, ou additionalType utilisé à la place d'un tableau @type.

• Formats approximatifs: coordonnées avec moins de cinq décimales, téléphone sans indicatif, URL incomplète.

• Fausse sécurité: se fier au seul résultat « valide » du test et en déduire une garantie d'affichage.

Point de vigilance

L'auto-attribution d'étoiles est une erreur classique. Une entreprise qui contrôle les avis ne peut pas obtenir d'étoiles pour elle-même, y compris si des avis tiers sont intégrés sur son propre site. Dans cette documentation, les avis LocalBusiness concernent les sites qui recueillent des avis sur d'autres entreprises locales.

Pour chacun de ces points, le remède est le même: comparer le code à la page affichée, ligne par ligne, avant chaque mise en ligne.

Conseils pratiques pour un balisage durable

Un balisage juste le jour de sa publication peut devenir faux trois mois plus tard. La durabilité tient à deux habitudes: compléter intelligemment, puis entretenir.

Compléter avec Organization

LocalBusiness étant un sous-type de Organization, Google recommande d'ajouter aussi les champs Organization pertinents: url, logo, sameAs, adresse, téléphone et identité de marque. Ils peuvent contribuer à la compréhension et à la désambiguïsation de l'entreprise. N'indiquez que des profils et identifiants exacts de l'entité ou de la localisation concernée. Un lien sameAs vers le profil d'une autre agence, par exemple, serait une erreur.

Maintenance et mises à jour

Mettez à jour le JSON-LD à chaque changement d'horaires, d'adresse ou de téléphone, en même temps que le contenu visible. Prévoyez aussi un contrôle périodique sur un échantillon de pages, en particulier après une refonte ou un changement de CMS, moments où les balises disparaissent ou se dupliquent sans bruit.

Côté vocabulaire, Schema.org a publié la version 30.1 le 16 septembre 2026. Les notes de version citées ne signalent pas de changement matériel du modèle LocalBusiness de base: votre implémentation actuelle n'a donc pas à être reprise pour cette raison.

L'essentiel à retenir

Un type précis, un objet par établissement, name et address renseignés, des compléments exacts, un placement sur la page décrite, puis deux validateurs et une inspection d'URL.

Le meilleur balisage LocalBusiness est celui qui reste fidèle à la réalité de votre établissement, semaine après semaine: sa valeur tient à son exactitude, pas à son volume.