Schema markup local : la checklist pour TPE

Le schema markup local ne crée pas une présence locale et ne garantit aucun gain de classement. Il rend lisibles, pour les moteurs de recherche, des informations déjà présentes sur votre site : nom, adresse, téléphone, services, zones d’intervention. C’est un travail d’alignement des preuves existantes, pas de magie.

Cette checklist s’adresse aux TPE, artisans, commerçants et prestataires qui veulent baliser correctement leur site, sans copier-coller le même bloc JSON-LD sur chaque page.

Schema technique simplifie sur : À quoi sert vraiment le schema markup local ?

1. À quoi sert vraiment le schema markup local ?

Le schema markup local est un vocabulaire standardisé, défini par Schema.org, qui permet de décrire une page dans un format compréhensible par les machines. Vous ajoutez un bloc JSON-LD dans le code de la page : il décrit ce que la page montre déjà, pas ce que vous aimeriez que Google croie.

Google utilise ces données structurées pour mieux comprendre le contenu d’une page, c’est ce que précise la documentation Google Search Central. Cela peut aider Google à interpréter ces informations et, dans certains contextes, participer à l’éligibilité à des affichages enrichis. Google ne présente pas les données structurées comme une garantie de classement.

Trois effets distincts à garder en tête :

Clarification : Google comprend mieux l’entité décrite (entreprise, service, zone).
Éligibilité aux affichages enrichis : possible, non garanti.
Classement : Google ne présente pas le schema comme un signal de ranking.

Il n’existe pas de « schema Google Business Profile ». Cette formulation circule, mais aucun balisage ne synchronise votre site avec votre fiche GBP. L’objectif est la cohérence : les mêmes informations sur le site, dans le schema et dans la fiche. Le schema ne corrige pas une fiche GBP incohérente, il peut amplifier le conflit.

Comparatif visuel des options liees au schema local. Quel schema choisir selon la page ?

2. Quel schema choisir selon la page ?

La règle de base : une page = un balisage qui décrit principalement ce que cette page montre. Ne pas coller un LocalBusiness complet sur chaque URL du site.

Type de page	Schema recommandé	Champs utiles	Erreurs à éviter
Accueil / Contact	`LocalBusiness` ou sous-type métier	`name`, `address`, `telephone`, `url`, `openingHoursSpecification`	Baliser des horaires ou services absents de la page
Page prestation	`Service` lié au prestataire via `@id`	`name`, `description`, `provider`, `areaServed`	Dupliquer le `LocalBusiness` complet inutilement
Page service + ville	`Service` avec `areaServed`	`name`, `areaServed`, `provider`	Créer la page uniquement pour le balisage, sans contenu local réel
Entreprise avec adresse publique	`LocalBusiness` ou sous-type	`address` complète	Inventer des coordonnées GPS non vérifiées
Entreprise à domicile / zone	`LocalBusiness` ou sous-type, sans adresse publique si elle n’est pas affichée, avec `areaServed` si la zone est visible	`areaServed`, `telephone`, `url`	Publier une adresse personnelle non souhaitée ou incohérente avec le choix GBP
Multi-établissements	Un `LocalBusiness` par établissement, sur sa propre page	`name`, `address`, `url` propre à chaque antenne	Fusionner tous les établissements dans un seul bloc, mélanger horaires et téléphones

Quelques arbitrages utiles :

Accueil/contact : c’est la page de l’entité principale. Le LocalBusiness y décrit l’établissement dans son ensemble. C’est ici que le @id est défini, les autres pages pourront y faire référence.
Page prestation : le Service décrit le service principal de la page. Le provider référence l’entité via son @id, sans répéter tout le bloc LocalBusiness.
Page service + ville : le balisage schema pages services locales n’est justifié que si la page contient un contenu local réel, exemples de chantiers, informations spécifiques à la zone, témoignages locaux. Une page vide avec un H1 « Plombier à Chartres » ne mérite pas de schema.
Multi-établissements : idéalement une page par établissement, avec une URL propre et un bloc LocalBusiness distinct. Un restaurant avec deux adresses à Paris et Lyon = deux pages, deux blocs, deux fiches GBP.

Sous-types utiles : Plumber, Electrician, Restaurant, LegalService… Schema.org liste les sous-types de LocalBusiness. Utilisez-en un seulement si votre activité correspond clairement, un sous-type imprécis est moins utile qu’un LocalBusiness bien renseigné.

Checklist des points a verifier. Checklist LocalBusiness, données NAP et cohérence GBP

3. Checklist LocalBusiness, données NAP et cohérence GBP

Les données NAP SEO local (Name, Address, Phone) sont le socle des données structurées entreprise locale. Leur cohérence entre le site, le schema et la fiche Google Business Profile est plus importante que la sophistication du balisage.

Champs à vérifier

name : nom commercial exact, sans mots-clés ajoutés, identique à la fiche GBP.
address : bloc PostalAddress avec streetAddress, addressLocality, postalCode, addressCountry. Identique dans le footer, la page contact et la fiche GBP.
telephone : numéro principal stable, format international recommandé (+33…).
url : URL canonique de la page ou du site.
openingHoursSpecification : uniquement si les horaires sont visibles sur la page et à jour.

Cohérence avec Google Business Profile

Google Business Profile a ses propres règles sur le nom, l’adresse et les zones desservies. Le schema ne corrige pas une fiche incohérente.

Avant de baliser :

[ ] Le nom de l’entreprise est identique sur le site, dans le schema et dans la fiche GBP.
[ ] L’adresse (ou l’absence d’adresse publique) est cohérente entre les trois sources.
[ ] Le numéro de téléphone est le même partout.
[ ] Les horaires balisés correspondent aux horaires affichés sur la page et dans la fiche GBP.
[ ] Le type d’activité (@type) reflète réellement le métier exercé.
[ ] Les informations sont cohérentes avec les sources publiques pertinentes (annuaires officiels, pages de résultats locaux), sans chercher à multiplier les citations pour le seul bénéfice SEO.

Comparatif visuel des options liees a 5. Exemples JSON LD et validation

4. Services, zones desservies et pages locales

Baliser un service

Le type Service de Schema.org décrit une prestation. Il se place sur la page dédiée à ce service, pas sur l’accueil. Champs utiles :

name : intitulé du service.
description : description visible sur la page.
provider : référence à l’entité LocalBusiness via @id.
areaServed : zones réellement couvertes, visibles dans le contenu.

areaServed schema : zones réelles, pas liste de communes

La propriété areaServed déclare les zones d’intervention. Elle doit refléter les zones réellement desservies, mentionnées dans le contenu de la page, et cohérentes avec les zones déclarées dans la fiche GBP.

Ce qu’il ne faut pas faire : lister vingt communes dans areaServed parce qu’elles sont proches, sans que le contenu en parle. Ce type d’empilement opportuniste ne trompe pas les systèmes d’évaluation.

Format recommandé pour le balisage schema service ville :

"areaServed": [
  { "@type": "City", "name": "Chartres" },
  { "@type": "City", "name": "Dreux" }
]

Ou, si la zone est large : "areaServed": "Eure-et-Loir", une chaîne de texte simple suffit.

Un consultant qui intervient dans tout un département peut utiliser "@type": "AdministrativeArea" avec le nom du département. Un artisan multi-agences utilisera un areaServed distinct par établissement.

Pages locales : quand les créer ?

Une page « service + ville » ne mérite un balisage que si elle apporte un contenu spécifique à cette zone. Sans contenu différenciant, c’est une page dupliquée. Le schema ne la rend pas légitime, il signale simplement ce que la page montre déjà.

5. Exemples JSON-LD et validation

Exemple minimal LocalBusiness

{
  "@context": "https://schema.org",
  "@type": "Plumber",
  "@id": "https://www.exemple.fr/#etablissement",
  "name": "Dupont Plomberie",
  "url": "https://www.exemple.fr",
  "telephone": "+33612345678",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "12 rue des Artisans",
    "addressLocality": "Chartres",
    "postalCode": "28000",
    "addressCountry": "FR"
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "08:00",
      "closes": "18:00"
    }
  ]
}

Ce bloc va sur la page d’accueil ou la page contact, là où ces informations sont visibles. Pas d’avis, pas de coordonnées GPS inventées, pas de réseaux sociaux non vérifiés.

Exemple minimal Service

{
  "@context": "https://schema.org",
  "@type": "Service",
  "name": "Débouchage canalisation",
  "description": "Intervention rapide pour débouchage de canalisations en Eure-et-Loir.",
  "provider": {
    "@id": "https://www.exemple.fr/#etablissement"
  },
  "areaServed": {
    "@type": "AdministrativeArea",
    "name": "Eure-et-Loir"
  }
}

Le provider référence l’entité via son @id, défini dans le bloc LocalBusiness de l’accueil. Pas besoin de répéter toutes les informations de l’établissement.

Validation

Deux outils, deux périmètres :

Rich Results Test (Google) : vérifie l’éligibilité aux affichages enrichis selon les règles Google Search.
Schema Markup Validator (Schema.org) : vérifie la validité du vocabulaire Schema.org.

Un schema valide Schema.org n’est pas forcément éligible aux enrichissements Google. Les deux tests sont complémentaires.

Avant publication : vérifications obligatoires
[ ] Le contenu visible de la page correspond aux données balisées.
[ ] Le NAP (nom, adresse, téléphone) est identique sur le site, dans le schema et dans la fiche GBP.
[ ] Les services et zones balisés sont réels et présents dans le contenu.
[ ] Le schema a été testé avec le Rich Results Test et le Schema Markup Validator.
[ ] Aucune donnée inventée (horaires, coordonnées GPS, avis) n’est incluse.
[ ] Chaque page a son propre balisage adapté à son contenu.

Conclusion : aligner, pas inventer

Le schema markup local relie des preuves déjà présentes, NAP, services, zones, pages locales, fiche GBP. Il aide Google à comprendre qui vous êtes, où vous êtes et ce que vous faites. Il ne remplace ni une fiche GBP solide, ni des pages utiles, ni une activité locale réelle.

Commencez par l’essentiel : un LocalBusiness bien renseigné sur la page d’accueil ou contact, avec un NAP cohérent. Ajoutez un Service sur chaque page de prestation qui le justifie. N’allez pas plus loin tant que ces bases ne sont pas solides.

Pour aller plus loin : optimiser votre fiche Google Business Profile · corriger la cohérence NAP · créer des pages locales SEO utiles · structurer vos pages services

Checklist finale

[ ] La page affiche-t-elle les informations balisées ?
[ ] Le NAP est-il identique sur le site, dans le schema et dans la fiche GBP ?
[ ] Le @type décrit-il le contenu principal de la page ?
[ ] Les zones areaServed sont-elles réelles et visibles dans le contenu ?
[ ] Le @id de l’établissement est-il cohérent entre les pages ?
[ ] Les tests Rich Results Test et Schema Markup Validator sont-ils passés ?

FAQ

Quelques points souvent mal compris sur le schema markup local.

Le schema markup local améliore-t-il le classement ?
Google ne présente pas les données structurées comme un signal de ranking. Elles aident à comprendre une page et peuvent, dans certains contextes, participer à l’éligibilité à des affichages enrichis, ce qui peut améliorer le taux de clic, sans garantie.

Organization ou LocalBusiness ?
Organization décrit une entité globale (groupe, marque, association). LocalBusiness décrit un établissement avec une présence physique ou une zone d’intervention locale. Pour une TPE, un artisan ou un commerce, LocalBusiness, ou un de ses sous-types, est le bon choix.

Puis-je baliser plusieurs villes ?
Oui, via areaServed avec plusieurs entrées. Chaque ville listée doit correspondre à une zone réellement desservie, mentionnée dans le contenu de la page. Lister des villes pour le seul bénéfice SEO, sans contenu associé, n’a pas de valeur.

Que mettre dans areaServed ?
Les zones où vous intervenez réellement : ville, département, région, selon votre activité. Utilisez City, AdministrativeArea ou une chaîne de texte simple. Restez cohérent avec ce que déclare votre fiche GBP dans la section « zones desservies ».

Dois-je baliser chaque page du site ?
Non. Seules les pages qui affichent des informations structurables méritent un balisage. Une page « À propos » générique ou un article de blog n’ont pas besoin d’un LocalBusiness. Balisez ce que la page montre, pas ce que vous aimeriez qu’elle montre.

Schema markup local : la checklist pour relier site web, services et fiche Google