Données structurées Schema : le guide JSON-LD pour une mis en place facile

Les données structurées sont un code invisible pour vos visiteurs, mais lisible par les moteurs, qui décrit ce que contient chaque page : votre entreprise, vos services, vos articles, votre fil d’Ariane. Elles s’écrivent avec le vocabulaire Schema.org, le plus souvent au format JSON-LD. Pour une PME, l’essentiel tient en quatre schémas bien posés, et une règle : ne balisez jamais ce que le visiteur ne peut pas voir. Voici lesquels, dans quel ordre, avec l’erreur que nous corrigeons le plus souvent : LocalBusiness plaqué sur une entreprise sans établissement physique.

En bref

• Schema.org est le vocabulaire, JSON-LD est le format : Google recommande généralement JSON-LD quand il se gère simplement.
• Une PME a besoin de peu : Organization (accueil), BreadcrumbList, le schéma de contenu adapté (Article, Service, Product) et LocalBusiness uniquement si elle reçoit du public à une adresse réelle.
• LocalBusiness décrit un lieu physique : le poser sur une activité itinérante ou 100 % à distance, c’est balisage trompeur.
• Un plugin comme RankMath génère le JSON-LD, mais ne décide pas à votre place de ce qui est vrai : il faut le paramétrer.
• Aucun résultat enrichi n’est garanti, et le balisage n’est pas un levier de classement direct.

Table des matières

• Schema.org, JSON-LD, Microdata : ce qu’on mélange souvent
• À quoi servent vraiment les données structurées
• Les quatre schémas qu’une PME doit poser
• L’erreur LocalBusiness : balisage d’un lieu qui n’existe pas
• RankMath : régler les snippets sans se piéger
• Tester, déployer, surveiller
• Notre point de vue : le balisage est un sujet d’architecture
• Coût et mise en place : où cela s’intègre dans un projet
• Checklist avant de publier
• FAQ
• Sources

Schema.org, JSON-LD, Microdata : ce qu’on mélange souvent

Première confusion, et elle coûte cher en temps : Schema.org n’est pas un format de code. C’est un dictionnaire de types (Organization, Product, Article…) et de propriétés (name, address, price…). Google le présente ainsi dans sa documentation sur le fonctionnement du balisage : les données structurées sont un format normalisé pour décrire et classer le contenu d’une page, et Schema.org fournit le sens.

Pour écrire ce vocabulaire, trois syntaxes existent :

Google précise que les trois formats lui conviennent si le balisage est valide et correctement mis en œuvre. Notre préférence va pourtant au JSON-LD, pour une raison très concrète : le bloc est indépendant du gabarit. Vous modifiez le design, le balisage ne casse pas. Avec des microdonnées éparpillées dans le HTML, chaque refonte devient une chasse au trésor.

À quoi servent vraiment les données structurées

Soyons nets, parce que le marché est plein de promesses. Les données structurées peuvent aider Google à comprendre une page et la rendre éligible à un résultat enrichi (étoiles, fil d’Ariane, informations produit). Éligible, pas garanti : Google indique que l’affichage dépend de l’algorithme, du contexte de recherche, du lieu et de l’appareil, selon ses consignes générales.

Les gains de clic existent, mais viennent de l’apparence, pas d’un bonus de position. Dans des études de cas publiées par Google, Rotten Tomatoes a mesuré un taux de clic supérieur de 25 % sur des pages enrichies, et Nestlé 82 % de plus sur ses pages en résultats enrichis. Ce sont des géants, avec des volumes sans commune mesure avec ceux d’une PME du Gard : prenez ces chiffres comme un ordre de grandeur de ce que l’apparence peut changer, pas comme une prévision.

Côté classement, la prudence est de mise. Semrush notait en 2022 qu’aucune preuve ne montrait un effet direct du balisage sur les positions, tout en soulignant son intérêt pour l’apparence et l’expérience de recherche. Notre lecture : le balisage ne fait pas monter une page, il évite qu’elle soit mal comprise. C’est un travail de fondation, comme l’arborescence du site ou la preuve d’expertise décrite dans notre article sur l’EEAT en SEO.

Et pour la visibilité dans les moteurs de réponse IA ? Nous structurons nos sites pour être cités par ces moteurs, mais nous ne vendons aucune promesse : un balisage propre rend une entité plus lisible, il ne garantit aucune citation. Pour le travail de fond sur ce sujet, voyez notre approche de la visibilité SGE sur Google.

Les quatre schémas qu’une PME doit poser

Inutile de coller trente types sur chaque page. Google recommande de choisir une fonctionnalité à mettre en œuvre et de décrire le contenu de la page concernée. Pour une PME, voici l’ossature qui couvre 90 % des besoins.

1. Organization sur la page d’accueil

C’est le schéma d’identité. Google recommande de placer Organization sur la page d’accueil ou sur une page décrivant l’entreprise, sans garantir qu’une fonctionnalité en résultera. Il porte votre nom légal, votre logo, votre URL, vos profils officiels (réseaux sociaux, annuaires) et un moyen de contact.

Exemple minimal, à adapter avec vos vraies informations :

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://www.exemple-pme.fr/#organisation",
  "name": "Exemple PME",
  "url": "https://www.exemple-pme.fr/",
  "logo": "https://www.exemple-pme.fr/logo.png",
  "sameAs": [
    "https://www.linkedin.com/company/exemple-pme"
  ],
  "contactPoint": {
    "@type": "ContactPoint",
    "contactType": "customer service",
    "email": "contact@exemple-pme.fr"
  }
}

Le champ @id est sous-estimé : il donne à votre entreprise un identifiant stable que les autres blocs (Article, Service) peuvent référencer. Vous construisez ainsi un seul graphe cohérent plutôt qu’un empilement de blocs qui s’ignorent.

2. BreadcrumbList sur les pages internes

Le fil d’Ariane se balise simplement. Google documente BreadcrumbList avec des éléments ListItem ordonnés : name et position sont requis, et item peut être omis pour le dernier élément. À condition que le fil soit réellement affiché sur la page, et qu’il reflète une arborescence logique.

3. Le schéma de contenu : Article, Service ou Product

Une page de blog reçoit Article, avec auteur, date de publication et de mise à jour. Une page de prestation reçoit Service, rattaché à l’Organization par son @id. Une fiche produit e-commerce reçoit Product, avec prix, disponibilité et avis uniquement s’ils sont visibles sur la page.

Une règle s’applique à tous : le contenu balisé doit être celui que voit l’utilisateur. Un avis client absent de la page n’a rien à faire dans le JSON-LD.

4. LocalBusiness, seulement si le lieu existe

C’est le schéma le plus mal utilisé. On y vient.

L’erreur LocalBusiness : balisage d’un lieu qui n’existe pas

Schema.org définit LocalBusiness comme une entreprise ou une succursale physique particulière, avec des propriétés comme address, openingHours et priceRange. Google, dans sa documentation sur les établissements locaux, recommande le sous-type le plus précis et les propriétés Organization applicables.

Le mot clé est « physique ». Pourtant, nous auditons régulièrement des sites qui déclarent un LocalBusiness pour :

• un consultant ou un artisan qui intervient chez ses clients, sans accueil du public ;
• une société domiciliée chez un dirigeant ou dans une boîte aux lettres de domiciliation ;
• une activité 100 % en ligne, avec une adresse de siège purement administrative ;
• une entreprise qui liste vingt villes « desservies » comme autant d’adresses fictives.

Le problème est double. D’abord, vous annoncez des horaires d’ouverture et une adresse où personne ne peut se rendre : c’est une information fausse, donc un balisage trompeur. Google indique qu’un balisage trompeur, non représentatif du contenu principal ou invisible pour l’utilisateur peut empêcher l’affichage d’un résultat enrichi. Ensuite, c’est une bombe à retardement : le jour où une action manuelle tombe, vous perdez l’éligibilité aux résultats enrichis. Google précise que cette action n’affecte pas le classement dans les résultats Web, mais perdre un affichage que vous aviez gagné reste un gâchis.

Comment décider en trois questions

1. Un client peut-il se présenter à cette adresse, à des horaires précis ? Oui : LocalBusiness (ou son sous-type le plus précis) est légitime. Non : restez sur Organization.
2. L’adresse et les horaires sont-ils affichés sur le site ? Si non, ne les mettez pas dans le balisage.
3. Avez-vous plusieurs établissements ? Un bloc par lieu réel, chacun sur sa page dédiée, jamais une adresse inventée par ville.

Pour une activité qui se déplace, la bonne approche est d’utiliser Organization, de décrire les prestations avec Service, et de travailler la zone d’intervention dans le contenu visible : pages de réalisations, mentions de villes réelles, témoignages. Notre article sur la visibilité locale sur Google détaille ce travail, et celui sur le SEO local à Lyon montre comment l’appliquer à une métropole sans multiplier les fausses adresses.

RankMath : régler les snippets sans se piéger

Sur WordPress, RankMath génère du JSON-LD sans que vous écriviez une ligne. C’est un vrai gain de temps, à condition de comprendre ce qu’il produit. Les intitulés exacts des menus évoluent selon les versions, vérifiez donc chez vous, mais la logique reste la même.

Le réglage global : qui êtes-vous ?

Dans les réglages de titres et métas, vous indiquez si le site représente une personne ou une organisation, avec nom, logo et profils. C’est ce réglage qui alimente le schéma d’identité de la page d’accueil. Deux pièges classiques :

• choisir « entreprise locale » par réflexe alors que vous n’avez pas de local ouvert au public : relisez la section précédente ;
• laisser un logo ou un nom par défaut, ce qui produit un balisage incomplet ou incohérent avec le site.

Le réglage par page : un type par intention

RankMath permet d’attribuer un schéma à chaque contenu. Par défaut, les articles sont typés Article. Pour les pages de prestation, un type adapté (Service, ou Product en e-commerce) évite de laisser un type générique. Le réflexe à garder : ouvrir la page, ne cocher que ce qui correspond à du contenu réellement visible.

Les snippets FAQ et avis

Le générateur de FAQ est tentant : on l’applique à toutes les pages pour « gagner de la place ». Résultat typique : des questions balisées qui n’apparaissent pas à l’écran, ou répétées à l’identique sur cinquante pages. Le principe de Google est clair : les données structurées doivent représenter fidèlement le contenu de la page et ce contenu doit être visible. Même logique pour les notes : pas d’AggregateRating sur une page sans avis affichés.

Quand le plugin ne suffit plus

Plugin ou pas, le résultat doit être relu. Les conflits sont fréquents : le thème sort son propre balisage, une extension e-commerce en ajoute un autre, et la page affiche trois Organization différentes. Pour un site sur mesure ou une boutique complexe, nous écrivons le graphe JSON-LD directement dans le code, avec un identifiant unique par entité. C’est ce que nous appelons éviter le plat de spaghettis numérique : un seul graphe, lisible, maintenable.

Tester, déployer, surveiller

La procédure recommandée par Google, décrite dans sa documentation sur les établissements locaux, se transpose à tout type de balisage :

1. ajouter les propriétés obligatoires et recommandées ;
2. suivre les consignes de Google ;
3. valider avec le test des résultats enrichis ;
4. déployer sur quelques pages, puis utiliser l’inspection d’URL ;
5. demander une nouvelle exploration si nécessaire.

Avant cela, vérifiez que les pages sont accessibles : ni bloquées par robots.txt, ni en noindex, ni derrière une authentification. Un balisage parfait sur une page non explorée ne sert à rien.

Une bonne habitude de PME : refaire un test après chaque mise à jour du thème, du plugin SEO ou après une migration. Une migration mal préparée fait souvent disparaître le balisage sans que personne ne s’en aperçoive, et c’est exactement le genre de régression qu’une maintenance de site régulière attrape.

Notre point de vue : le balisage est un sujet d’architecture

Nous voyons chaque semaine le même scénario : une PME installe un plugin, active tous les schémas, obtient un tableau vert dans l’outil de test et pense le sujet réglé. Un tableau vert prouve que la syntaxe est valide. Il ne prouve pas que le balisage dit vrai.

Chez Auda-Design, nous travaillons simultanément l’image, la technique et la visibilité. Cette position change la façon de traiter les données structurées : elles ne sont pas une couche SEO ajoutée à la fin, mais le reflet de l’architecture du site. Si les pages sont mal structurées, si l’entité de l’entreprise n’est pas clairement définie, aucun JSON-LD ne rattrape le problème. À l’inverse, un site pensé dès le départ avec une arborescence claire, un nom d’entreprise cohérent et des pages de services distinctes se balise presque naturellement.

Notre exigence est simple : un bloc de balisage par fait réel, visible sur la page, rattaché à une entité unique. Pas de LocalBusiness pour faire joli, pas de FAQ fantôme, pas d’avis imaginaires. Les faux prophètes du SEO vendent du « schéma magique » ; nous préférons un balisage sobre, vérifiable, qui survit aux refontes.

David

Coût et mise en place : où cela s’intègre dans un projet

Le balisage n’est presque jamais un projet isolé. Il s’intègre à la création ou à la refonte du site, parce que c’est là qu’on décide de la structure des pages. Nos tarifs publiés donnent des repères : une création de site internet se situe entre 2 500 et 8 000 €, une refonte entre 3 000 et 15 000 €, un site e-commerce entre 5 000 et 25 000 €, et la maintenance entre 80 et 800 € par mois. Le balisage fait partie de la réflexion technique sur chaque projet.

Si votre site existe déjà et que vous soupçonnez un balisage faux ou cassé, la bonne séquence est : audit du JSON-LD existant, nettoyage des doublons, puis écriture d’un graphe propre. Nous prenons en charge cette démarche dans le cadre d’une création ou refonte de site, avec le même interlocuteur pour le design, la technique et la visibilité. Si vous gérez aussi un catalogue produit, notre page création de site e-commerce détaille l’approche.

Pensez aussi à la conformité : un site qui collecte des données doit rester en règle, et notre diagnostic RGPD en 10 points vous aide à vérifier le reste de votre technique en parallèle.

Checklist avant de publier

• Un seul Organization par site, avec un @id stable.
• LocalBusiness uniquement pour un lieu réel ouvert au public, avec adresse et horaires affichés.
• Chaque propriété balisée correspond à un élément visible sur la page.
• Pas de page créée uniquement pour porter du balisage.
• Test des résultats enrichis passé, puis inspection d’URL sur quelques pages avant généralisation.
• Contrôle après chaque mise à jour du thème, du plugin ou migration.

FAQ

Les données structurées améliorent-elles le classement Google ?

Pas directement. Elles aident Google à comprendre la page et peuvent la rendre éligible à un résultat enrichi, sans garantie d’affichage. L’effet utile est surtout sur l’apparence du résultat et donc sur l’envie de cliquer.

JSON-LD ou Microdata : lequel choisir ?

Google accepte JSON-LD, Microdata et RDFa si le balisage est valide, mais recommande généralement JSON-LD quand il se gère simplement. Pour une PME, c’est aussi le plus facile à maintenir, car le bloc est séparé du design.

Puis-je utiliser LocalBusiness si je n’ai pas de local ?

Non, ce n’est pas adapté : Schema.org le définit comme une entreprise ou une succursale physique. Utilisez Organization et décrivez vos prestations avec Service. Si vous recevez du public à une adresse réelle, LocalBusiness redevient pertinent, avec le sous-type le plus précis.

RankMath suffit-il pour poser mes schémas ?

Pour un site WordPress simple, il couvre l’essentiel une fois bien paramétré. Il faut toutefois vérifier le type choisi, l’identité de l’entreprise et l’absence de doublons avec le thème. Sur un site sur mesure ou un e-commerce complexe, un graphe écrit à la main est plus fiable.

Comment vérifier que mon balisage est correct ?

Passez chaque type de page dans le test des résultats enrichis de Google, puis déployez sur quelques pages et utilisez l’inspection d’URL. Vérifiez aussi que les pages ne sont pas bloquées par robots.txt ou noindex.

Sources

• Présentation du fonctionnement du balisage de données structurées (Google Search Central)
• Intro to How Structured Data Markup Works (Google Search Central)
• Organization Schema Markup (Google Search Central)
• Données structurées spécifiques aux établissements locaux (Google Search Central)
• Balisage de fil d’Ariane (Google Search Central)
• Consignes générales relatives aux données structurées (Google Search Central)
• LocalBusiness, type Schema.org
• Utiliser les microdonnées en HTML (MDN)
• Qu’est-ce que le balisage Schema ? (Semrush)

Recommandations

• Architecture d’information d’un site d’entreprise : guide PME
• Internationaliser son site web d’entreprise : guide PME
• Design mobile first : méthode, pièges et bénéfices pour une PME
• Avantages refonte site internet : guide PME 2026