Schema LocalBusiness : le guide JSON‑LD pour PME

Le balisage LocalBusiness est un bloc de données structurées, écrit en JSON‑LD, qui décrit votre établissement dans un langage que Google comprend directement : nom, adresse, téléphone, horaires, zone de service. Publiez‑le dès aujourd’hui, à condition qu’il reproduise fidèlement votre fiche Google Business Profile.

Concrètement, voici ce qu’il faut faire dans l’heure qui suit la lecture de cet article :

Créer un bloc JSON‑LD contenant name, address (ou areaServed), telephone, url et openingHoursSpecification.
Vérifier que le nom, l’adresse et le téléphone (le trio NAP) sont identiques mot pour mot entre le site, le schéma et la fiche Google Business Profile.
Insérer ce bloc dans le <head> de la page d’accueil ou de la page établissement, jamais en double avec un plugin concurrent.

Un point mérite d’être clarifié avant d’aller plus loin : le schéma rend votre entreprise plus lisible pour les moteurs, mais il ne remplace jamais votre fiche Google Business Profile pour l’apparition dans le pack local. C’est un renfort de clarté, pas un levier de classement direct.

Points clés

Un schema LocalBusiness fiable repose sur trois piliers indissociables : cohérence NAP stricte, choix du sous‑type le plus précis, et validation systématique avant mise en ligne.

Point	Détails
Priorité absolue	Publier un bloc JSON‑LD avec name, address (ou areaServed), telephone, url et openingHoursSpecification identiques à la fiche Google Business Profile.
Sous‑type précis	Préférer Restaurant, Dentist ou ProfessionalService à LocalBusiness générique pour débloquer des propriétés métier utiles.
Multi‑établissements	Attribuer un @id stable et unique par page établissement, relié au siège via parentOrganization si besoin.
Validation en trois temps	Tester avec Rich Results Test, confirmer avec Schema.org Validator, puis surveiller Search Console après mise en ligne.
Accompagnement possible	It-pascaud propose un audit du balisage LocalBusiness suivi d’une implémentation et d’une maintenance mensuelle pour les PME locales.

Table des matières

Quels champs inclure dans votre schema local business ?
Deux blocs JSON‑LD prêts à copier pour votre site
Faut-il utiliser LocalBusiness ou un sous‑type spécifique ?
Comment gérer plusieurs établissements ou une zone de service ?
Comment implémenter le schema selon votre plateforme ?
Comment valider votre balisage sans erreur ?
Quelles erreurs de schema local business coûtent le plus cher ?
Quelle checklist d’audit suivre avant de publier votre schema ?
Faut-il internaliser ou externaliser l’implémentation du schema ?
L’audit et la mise en place de votre schema LocalBusiness par It-pascaud
Questions fréquentes sur le schema local business
Sources

Quels champs inclure dans votre schema local business ?

Cinq propriétés forment le socle d’un balisage LocalBusiness correct : name, address, telephone, url et openingHoursSpecification. Schema documente l’ensemble des propriétés disponibles pour ce type et recommande d’utiliser le sous‑type le plus précis possible plutôt que le type générique.

Le champ address attend un objet PostalAddress avec streetAddress, addressLocality, postalCode et addressCountry renseigné au format ISO à deux lettres (FR pour la France, par exemple). Beaucoup de blocs échouent simplement parce que ce sous‑objet est mal structuré ou parce que le pays est écrit en toutes lettres au lieu du code ISO.

Pour le téléphone, adoptez systématiquement le format international avec l’indicatif pays, du type +33 2 43 XX XX XX. Un numéro écrit en format local pur (“02 43…”) reste lisible par un humain, mais complique l’association automatique avec les données déjà connues de Google sur votre entreprise.

Conseil de pro : ne recopiez jamais vos horaires à la main dans une chaîne de texte libre. Utilisez la structure OpeningHoursSpecification avec dayOfWeek, opens et closes : c’est la seule notation que les moteurs interprètent de façon fiable, comme le précise la spécification OpeningHoursSpecification de Schema.org.

geo (latitude/longitude) si vous avez un point de vente physique facilement géolocalisable.
sameAs pour lier vos profils sociaux et fiches d’annuaires officiels, ce qui aide les moteurs à confirmer l’identité de l’entité.
priceRange quand une fourchette de prix simple (€, €€, €€€) a du sens pour votre activité.
aggregateRating et offers uniquement si les notes ou promotions affichées dans le code sont réellement visibles sur la page. Un balisage d’avis invisible à l’écran est une pratique à risque, pas un raccourci gratuit.

Une entreprise qui ne dispose que du strict minimum (name, address, telephone, url) reste tout à fait valide. L’enrichissement vient ensuite, propriété par propriété, jamais en bloc.

Deux blocs JSON‑LD prêts à copier pour votre site

Voici un bloc minimal, suffisant pour la majorité des pages établissement d’une PME de services :

{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "@id": "https://www.exemple.fr/#organization",
  "name": "Nom de votre entreprise",
  "url": "https://www.exemple.fr",
  "telephone": "+33243000000",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "40 rue Exemple",
    "addressLocality": "Ville",
    "postalCode": "72000",
    "addressCountry": "FR"
  }
}

Et voici un bloc enrichi, adapté à une entreprise qui veut aussi afficher horaires, positionnement tarifaire et présence sociale :

{
  "@context": "https://schema.org",
  "@type": "ProfessionalService",
  "@id": "https://www.exemple.fr/#organization",
  "name": "Nom de votre entreprise",
  "url": "https://www.exemple.fr",
  "telephone": "+33243000000",
  "priceRange": "€€",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "40 rue Exemple",
    "addressLocality": "Ville",
    "postalCode": "72000",
    "addressCountry": "FR"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 48.0061,
    "longitude": 0.1996
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "09:00",
      "closes": "18:00"
    }
  ],
  "sameAs": [
    "https://www.facebook.com/exemple",
    "https://www.linkedin.com/company/exemple"
  ]
}

Élément	Bloc minimal	Bloc enrichi
Propriétés incluses	name, url, telephone, address	+ geo, openingHoursSpecification, priceRange, sameAs
Cas d’usage type	Page établissement simple, activité récente	Commerce ou service avec horaires fixes et présence sociale active
Effort de mise à jour	Faible	Modéré, à revoir à chaque changement d’horaire

Trois réglages à ne jamais négliger en adaptant ces blocs :

L’@id doit rester une URL stable et unique par établissement, jamais recopiée d’un site tiers.
Chaque valeur de sameAs doit pointer vers un profil que vous contrôlez réellement, pas un profil homonyme.
Les jours de la semaine dans dayOfWeek s’écrivent en anglais (Monday, Tuesday…) car ce sont des valeurs schema.org normalisées, pas du texte à traduire.

Faut-il utiliser LocalBusiness ou un sous‑type spécifique ?

Un sous‑type précis déverrouille des propriétés métier que le type générique LocalBusiness n’admet pas. Un restaurant qui se déclare simplement LocalBusiness perd l’accès à servesCuisine et à menu ; en se déclarant Restaurant, il gagne ces deux propriétés sans rien perdre du socle commun (name, address, telephone).

Même logique pour un cabinet dentaire : le type Dentist autorise medicalSpecialty et une relation employee vers un Physician, ce qui aide les moteurs à comprendre non seulement où vous êtes, mais ce que vous faites précisément. Schema.org recommande explicitement ce choix du type le plus spécifique disponible dans sa hiérarchie de types.

L’erreur classique consiste à empiler plusieurs @type contradictoires sur la même entité, par exemple ["LocalBusiness", "Organization", "Store"] sans hiérarchie claire. Un tableau @type est parfaitement valide quand les types sont compatibles (["LocalBusiness", "Restaurant"] fonctionne, puisque Restaurant hérite déjà de LocalBusiness), mais mélanger des branches distinctes de l’arborescence schema.org sème la confusion plutôt que de la lever. Mieux vaut un seul type bien choisi qu’une liste qui essaie de tout couvrir.

Comment gérer plusieurs établissements ou une zone de service ?

Chaque établissement physique doit avoir sa propre page et son propre bloc LocalBusiness, avec un @id unique et stable qui ne change jamais, même après une refonte du site. C’est ce @id qui permet aux moteurs de relier durablement l’entité à ses autres apparitions dans le code (fil d’Ariane, articles, avis).

Créez une page dédiée par adresse physique, chacune avec son propre bloc JSON‑LD complet.
Reliez chaque établissement au siège via la propriété parentOrganization, si votre structure a une entité mère juridique distincte.
Pour une entreprise qui intervient chez le client sans accueillir de public (plombier itinérant, coach à domicile, consultant), remplacez address par areaServed et listez les villes ou départements couverts.
Si vous publiez un annuaire d’établissements, structurez‑le en ItemList référençant chaque page LocalBusiness plutôt que de dupliquer les mêmes informations sur une page unique.

Conseil de pro : si vous n’avez pas d’adresse publique, ne “fabriquez” jamais une adresse fictive pour remplir le champ address. Utilisez areaServed et assurez‑vous que cette zone correspond exactement à celle déclarée sur votre fiche Google Business Profile : un écart entre les deux crée une confusion que les moteurs pénalisent en clarté, pas en trafic direct, mais qui finit par coûter cher en confiance.

Comment implémenter le schema selon votre plateforme ?

Sur WordPress, deux voies coexistent. La première consiste à utiliser un plugin dédié comme Local Business Schema Generator, qui génère le JSON‑LD automatiquement à partir des champs renseignés dans l’administration. La seconde consiste à injecter le bloc manuellement via un extrait de code dans le <head>, ce qui donne plus de contrôle mais demande une vigilance particulière.

Le piège le plus fréquent sur WordPress reste la duplication : un thème qui génère déjà un schema LocalBusiness minimal, plus un plugin SEO qui en génère un second, aboutissent à deux blocs concurrents sur la même page. Google ne “fusionne” pas ces deux blocs, il les lit tous les deux, et une divergence entre eux (un téléphone différent, par exemple) sème le doute sur l’entité réelle.

Sur Webflow, il n’existe pas d’équivalent plugin natif pour ce type de schéma. La méthode standard consiste à coller le bloc JSON‑LD directement dans le champ Custom Code de la section <head>, au niveau de la page établissement ou, si votre structure le permet, au niveau du template partagé par toutes les pages établissement.

Pour un site sur mesure, la bonne pratique change d’échelle dès que vous dépassez trois ou quatre localités. Plutôt que de coder chaque bloc à la main :

Centralisez les champs NAP dans une source unique (base de données, fichier de configuration) pour que le nom, l’adresse et le téléphone ne soient jamais ressaisis à la main sur chaque page.
Générez le JSON‑LD à partir d’un template versionné, pour que la moindre correction de format se propage automatiquement à toutes les pages établissement.
Gardez une convention stricte pour les @id, en général basée sur l’URL canonique de chaque page.

Conseil de pro : avant toute mise en production, comparez le rendu du bloc JSON‑LD entre l’environnement de test et le site en ligne. Un plugin de cache agressif ou une minification mal réglée peut casser silencieusement la syntaxe JSON, ce qui rend le bloc invalide sans qu’aucune erreur ne s’affiche visuellement sur la page.

Comment valider votre balisage sans erreur ?

Trois outils suffisent pour couvrir l’essentiel du contrôle qualité, à condition de les utiliser dans l’ordre.

Collez l’URL de la page ou le code brut dans l’outil de test des résultats enrichis pour vérifier que Google détecte bien le type LocalBusiness et ses propriétés.
Passez le même code dans le Schema.org Validator, qui vérifie la conformité stricte à la spécification, indépendamment de ce que Google choisit d’afficher ou non.
Une fois le site en production, surveillez le rapport de données structurées dans Search Console : il signale les erreurs détectées lors des passages de crawl réels, avec un décalage de quelques jours par rapport à une modification.

La distinction entre erreur et avertissement compte. Une erreur bloquante (une propriété requise manquante, une syntaxe JSON cassée) empêche Google d’exploiter le bloc entier. Un avertissement, comme une propriété recommandée absente, laisse le balisage fonctionnel mais incomplet. Corrigez les erreurs en priorité absolue ; traitez les avertissements au fil de vos mises à jour de contenu, sans urgence artificielle.

Quelles erreurs de schema local business coûtent le plus cher ?

L’incohérence NAP reste l’erreur la plus fréquente et la plus dommageable. Quand le numéro de téléphone du schéma diffère de celui affiché sur la page, ou que l’adresse du schéma ne correspond plus à la fiche Google Business Profile après un déménagement, les moteurs perdent en confiance sur l’identité réelle de l’établissement, même si chaque source individuellement semble correcte.

Trois autres erreurs reviennent régulièrement dans les audits :

Des horaires figés dans le code alors que l’établissement a changé de rythme depuis (fermeture le samedi, nouveaux horaires d’été), ce qui crée un décalage entre la promesse du schéma et la réalité vécue par le client.
Des propriétés aggregateRating ou review balisées dans le code sans que la note ou l’avis correspondant ne soit visible nulle part sur la page, une pratique qui expose à un rejet pur et simple du bloc enrichi.
Deux blocs LocalBusiness dupliqués sur la même page, souvent issus d’un conflit entre thème et plugin, qui sème la confusion plutôt que de la renforcer.

Le schéma renforce la cohérence NAP perçue par les moteurs, mais il ne suffit jamais à lui seul à garantir une position dans le pack local : c’est un signal de clarté, pas un raccourci de classement.

La bonne routine consiste à revoir le bloc JSON‑LD à chaque changement opérationnel réel (déménagement, nouveaux horaires, nouveau numéro), plus une revue mensuelle systématique même sans changement connu. Beaucoup d’agences ajoutent un contrôle automatisé au moment de la mise en ligne d’une page, pour repérer une régression avant qu’elle n’atteigne la production.

Quelle checklist d’audit suivre avant de publier votre schema ?

Avant de mettre en ligne un bloc LocalBusiness, six points méritent une vérification systématique, dans cet ordre précis :

Le trio NAP (nom, adresse, téléphone) est identique, caractère pour caractère, entre le site, le schéma et la fiche Google Business Profile.
L’@id est unique, stable, et ne change pas d’une mise à jour à l’autre.
openingHoursSpecification reflète les horaires réels du jour, pas ceux d’il y a six mois.
sameAs ne pointe que vers des profils que vous contrôlez réellement.
areaServed correspond exactement à la zone déclarée sur Google Business Profile, si vous n’avez pas d’adresse publique.
Aucune propriété makesOffer ou aggregateRating n’est balisée sans preuve visible correspondante sur la page.

Conseil de pro : gardez un registre simple de vos blocs JSON‑LD par page, avec la date de dernière vérification. Ce réflexe de gouvernance, plus qu’un outil sophistiqué, évite la majorité des dérives que l’on retrouve dans les audits.

Cette checklist est celle qu’applique l’équipe d’It-pascaud lors de ses audits pour les PME et associations locales accompagnées depuis Le Mans, en s’appuyant sur les méthodes d’optimisation du référencement local documentées par ailleurs sur le site.

Faut-il internaliser ou externaliser l’implémentation du schema ?

Pour un site à un seul établissement, sans logique multi‑localités, la question ne se pose pas vraiment : copier et adapter le bloc minimal de cet article, puis le valider avec le Rich Results Test, prend moins d’une heure à quiconque sait ouvrir le code source d’une page.

Le calcul change dès que trois facteurs s’accumulent : plusieurs adresses à gérer, une équipe sans compétence développeur en interne, ou un besoin de génération automatisée pour éviter les ressaisies manuelles répétées. Dans ce cas, le risque n’est plus le temps perdu mais l’erreur silencieuse. Un @id mal géré ou une incohérence NAP qui se propage sur dix pages coûte largement plus cher à corriger après coup qu’à cadrer correctement dès le départ.

L’audit et la mise en place de votre schema LocalBusiness par It-pascaud

Vous savez maintenant ce qu’il faut écrire dans le code. Reste à s’assurer que ce code tienne dans le temps, sans erreur de syntaxe qui passe inaperçue pendant des mois. It-pascaud propose un audit ciblé du balisage LocalBusiness suivi, si besoin, de son implémentation et de sa maintenance mensuelle, intégrés à ses formules d’accompagnement web pour les PME et associations du Mans et alentours.

Concrètement, la prestation couvre le diagnostic de vos blocs JSON‑LD existants (ou leur création s’ils n’existent pas encore), la mise en cohérence avec votre fiche Google Business Profile, et une revue régulière pour éviter que des horaires obsolètes ou un numéro mal recopié ne s’installent durablement. Ce suivi s’inscrit dans une approche plus large, détaillée sur la page consacrée au rôle du référencement local dans la visibilité d’une entreprise régionale. Pour démarrer, la première étape consiste simplement à consulter la présentation des services proposés par It-pascaud et à demander un point sur l’état actuel de votre balisage.

Questions fréquentes sur le schema local business

Le schema LocalBusiness améliore-t-il directement mon classement dans le pack local ?
Non, pas directement. Il renforce la clarté et la cohérence de votre entité auprès des moteurs, mais c’est votre fiche Google Business Profile qui reste le facteur déterminant pour l’apparition dans le pack local.

Puis-je utiliser plusieurs @type sur un même bloc LocalBusiness ?
Oui, à condition que les types soient compatibles dans la hiérarchie schema.org, comme ["LocalBusiness", "Restaurant"]. Évitez en revanche d’empiler des types issus de branches différentes sans lien logique entre eux.

Que faire si mon entreprise n’a pas d’adresse physique publique ?
Remplacez la propriété address par areaServed et listez les villes ou zones couvertes, en veillant à ce que cette zone corresponde exactement à celle déclarée sur votre fiche Google Business Profile.

Le format JSON‑LD est-il obligatoire pour le schema local business ?
Ce n’est pas une obligation stricte, mais c’est le format que Google recommande et privilégie pour les données structurées, car il s’insère facilement dans le <head> sans modifier la structure visuelle de la page.

À quelle fréquence dois-je vérifier mon balisage LocalBusiness ?
Une revue à chaque changement opérationnel réel (horaires, adresse, téléphone) est indispensable, complétée par un contrôle mensuel systématique même en l’absence de changement connu, pour repérer les erreurs silencieuses avant qu’elles ne s’accumulent.

Sources

Pour approfondir ou vérifier un point technique précis, ces ressources restent les plus fiables :

Recommandation

Jérémy Pascaud

Je suis Jérémy Pascaud, fondateur de IT-Pascaud, une agence web spécialisée dans la création de sites internet et l’accompagnement digital. Passionné par le numérique, j’aide les entreprises à développer leur présence en ligne avec des solutions modernes, performantes et adaptées à leurs objectifs.J’interviens principalement sur la conception de sites web, l’optimisation des performances et le conseil stratégique, avec une approche centrée sur l’efficacité et l’expérience utilisateur. Mon objectif est de proposer des solutions sur mesure, à la fois esthétiques et fonctionnelles.À travers IT-Pascaud, je mets un point d’honneur à offrir un accompagnement personnalisé, basé sur l’écoute, la réactivité et la confiance.

Voir la biographie complète