Aller au contenu
SEO AcquisitionRéférencement · Versailles

Données structurées en SEO : le guide pratique (JSON-LD & Schema.org)

Par Mohamed Debbah · 21 août 2026 · 9 min de lecture

Comment intégrer les données structurées Schema.org pour des rich snippets, un meilleur CTR et un SEO/GEO optimisé ? Exemples JSON-LD et méthode de validation.

Un moteur de recherche lit du texte. Il en déduit des choses, souvent correctement, parfois non. Les données structurées suppriment cette déduction : elles déclarent explicitement que « 129 » est un prix en euros, que « 4,7 » est une note moyenne portant sur 340 avis, et que l'entreprise décrite est la même que celle du profil LinkedIn associé.

C'est un traducteur universel, et il ne s'adresse plus seulement à Google : les moteurs de réponse génératifs s'appuient massivement sur ces déclarations pour établir des faits fiables sur une entreprise ou un produit. Ce guide donne le vocabulaire, les types indispensables par secteur, des modèles JSON-LD valides à copier, la méthode de validation, et les erreurs qui déclenchent des sanctions. (Dernière mise à jour : août 2026. Ce sujet évolue vite : vérifiez le statut des résultats enrichis dans la documentation officielle Google avant tout chantier.)

1. Qu'est-ce qu'une donnée structurée et pourquoi est-ce vital en SEO ?

Une donnée structurée est un balisage ajouté au code d'une page pour décrire son contenu dans un vocabulaire normalisé, compréhensible par les machines. Sur votre page, un visiteur lit « À partir de 129 €, en stock » ; un moteur voit une suite de caractères. Avec le balisage, il reçoit une déclaration sans ambiguïté : "price": "129.00", "availability": "InStock". Cette déclaration conditionne l'affichage d'éléments enrichis dans les résultats (prix, disponibilité, étoiles, fil d'Ariane) et alimente la compréhension de votre entité par les moteurs.

HTML, microdonnées et JSON-LD

Trois formats coexistent pour exprimer le vocabulaire Schema.org :

FormatPrincipeStatut
MicrodonnéesAttributs itemprop insérés dans les balises HTMLSupporté, mais fragile (casse à chaque modification du template)
RDFaExtension HTML issue du web sémantiqueSupporté, peu utilisé
JSON-LDBloc script type=application/ld+json indépendant du HTML✅ Format recommandé par Google

JSON-LD s'est imposé parce qu'il sépare le fond de la forme : le balisage vit dans un bloc autonome et ne dépend pas de la structure visuelle. Vous pouvez refondre entièrement votre design sans casser vos données structurées, ce qui n'est pas le cas des microdonnées. Un point de vocabulaire souvent confondu : Schema.org est le dictionnaire (il définit les types comme Product et leurs propriétés comme price), JSON-LD est la syntaxe qui permet de l'écrire. On écrit du vocabulaire Schema.org au format JSON-LD.

L'impact sur le CTR

Un résultat enrichi occupe davantage d'espace, affiche des informations décisives avant le clic et se distingue visuellement. Sur une même requête, un résultat produit enrichi montre le prix, la disponibilité, la note et le nombre d'avis là où un résultat classique n'a qu'un titre et deux lignes. Le premier capte davantage de clics à position égale : c'est le levier le plus rapide qui existe en SEO, aucune amélioration de classement, aucun contenu produit, simplement une meilleure occupation de l'espace dont vous disposez déjà. La nuance : aucun balisage ne garantit un affichage enrichi. Google décide au cas par cas selon la requête, l'appareil et sa propre évaluation. Le balisage rend éligible, il ne déclenche pas.

⚠️ Attention aux résultats enrichis FAQ et HowTo. Depuis 2023, Google a fortement restreint puis retiré les résultats enrichis FAQPage pour la quasi-totalité des sites, comme il l'avait fait pour HowTo. Ces types restent des vocabulaires Schema.org parfaitement valides, et Google indique que le balisage inutilisé ne pose aucun problème (inutile de le retirer en urgence). Mais il ne faut plus les présenter comme des leviers d'affichage enrichi : les prestataires qui vous vendent encore des « blocs FAQ dans la SERP » travaillent avec des informations périmées. La tendance est constante : Google réduit les traitements visuels accordés aux contenus tiers au profit de ses propres surfaces de réponse. Vérifiez toujours le statut courant dans la documentation officielle.

Le rôle des données structurées pour le GEO et les IA

C'est le déplacement le plus important de ces deux dernières années, et il redonne de la valeur au balisage indépendamment des résultats enrichis. Les moteurs de réponse (ChatGPT, Perplexity, AI Overviews, Gemini) doivent établir des faits fiables avant de recommander une entreprise ou un produit ; un contenu balisé leur fournit des affirmations non ambiguës plutôt que des déductions. Concrètement : la désambiguïsation d'entité (un Organization avec sameAs vers vos profils officiels évite qu'un moteur vous confonde avec un homonyme), des faits déclarés plutôt qu'extraits (prix, zone d'intervention, horaires), et la cohérence inter-sources. Précision honnête : Google indique qu'aucun balisage spécifique n'est requis pour figurer dans les AI Overviews ; le balisage n'est pas un sésame, il contribue à la compréhension et à la fiabilité perçue de vos informations. C'est le champ du GEO, détaillé aussi dans mon guide des données structurées pour l'IA.

2. Les types indispensables par secteur

E-commerce : Product, Offer, AggregateRating. Le balisage le plus rentable : il conditionne à la fois l'affichage enrichi et l'éligibilité aux fiches gratuites de Google Shopping. Propriétés déterminantes : name, sku, gtin13, brand, image, offers (avec price, priceCurrency, priceValidUntil, availability), aggregateRating et review uniquement si les avis sont réellement affichés, shippingDetails et MerchantReturnPolicy, et ProductGroup avec hasVariant pour les déclinaisons. Règle absolue : cohérence stricte entre la page visible, le balisage et le flux marchand. C'est le socle d'une bonne fiche produit SEO.

Entreprises locales : LocalBusiness, Organization. LocalBusiness est une spécialisation d'Organization : renseignez name, address (au format PostalAddress), geo, telephone, openingHoursSpecification, areaServed, priceRange, sameAs.

⚠️ Le piège des avis auto-hébergés. Depuis 2019, Google n'affiche plus d'étoiles issues d'avis que l'entreprise publie sur elle-même (les self-serving reviews). Baliser un aggregateRating sur votre propre LocalBusiness à partir de témoignages collectés sur votre site ne produira aucun affichage enrichi. Les avis de votre fiche Google Business Profile, eux, remontent indépendamment de tout balisage : c'est un pilier du référencement local.

Blogs et médias : Article, BreadcrumbList. Article (ou BlogPosting) déclare l'auteur, les dates et l'éditeur ; il contribue aux signaux d'E-E-A-T (un auteur identifié et relié à un profil via sameAs envoie un signal de paternité que le texte seul ne porte pas). BreadcrumbList est probablement le balisage au meilleur rapport effort/résultat : il affiche le chemin de navigation à la place de l'URL brute, améliore le taux de clic, et clarifie l'architecture pour les moteurs. Simple, sans risque, et systématiquement sous-exploité.

3. Générer et intégrer du JSON-LD sans casser son site

Étape 1, choisir le bon schéma. Sur schema.org, identifiez le type le plus spécifique qui décrit votre page (la hiérarchie descend de Thing à Organization à LocalBusiness à Restaurant), et ne renseignez que des propriétés correspondant à un contenu réellement visible.

Étape 2, générer le code. Modèle Organization, à placer sur la page d'accueil :

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://exemple.fr/#organization",
  "name": "Nom de l'entreprise",
  "url": "https://exemple.fr/",
  "logo": { "@type": "ImageObject", "url": "https://exemple.fr/logo.png" },
  "description": "Description factuelle de l'activité en une à deux phrases.",
  "email": "contact@exemple.fr",
  "telephone": "+33123456789",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "12 rue de la République",
    "addressLocality": "Lyon",
    "postalCode": "69002",
    "addressCountry": "FR"
  },
  "sameAs": [
    "https://www.linkedin.com/company/exemple",
    "https://fr.wikipedia.org/wiki/Exemple"
  ]
}

Modèle BreadcrumbList, à placer sur les pages internes :

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "Accueil", "item": "https://exemple.fr/" },
    { "@type": "ListItem", "position": 2, "name": "Chaussures de running", "item": "https://exemple.fr/chaussures-running/" },
    { "@type": "ListItem", "position": 3, "name": "Chaussures de trail homme" }
  ]
}

Notez l'absence de propriété item sur le dernier élément : c'est la page courante, la déclarer serait redondant. La propriété @id du premier exemple crée un identifiant unique permettant de relier vos blocs entre eux : un Article peut ainsi référencer l'organisation par son @id plutôt que de la redéclarer entièrement. C'est une pratique de graphe propre, que peu de sites appliquent. La référence complète est la documentation Google sur les données structurées.

Étape 3, méthode d'intégration : extension CMS (SEOPress, Rank Math, Yoast : rapide mais parfois incomplète et source de doublons), intégration native dans le thème (contrôle total, recommandée sur les sites à fort enjeu), ou Google Tag Manager (contournement côté client, jamais un choix par défaut car peu lu par les autres moteurs et robots d'IA).

💬 Conseil de terrain, le doublon invisible. L'erreur la plus fréquente que je rencontre en audit n'est pas l'absence de balisage, c'est le balisage en double. Le thème déclare un Product, l'extension SEO en déclare un autre, une application d'avis en ajoute un troisième, et le résultat n'est plus interprétable. Avant d'ajouter quoi que ce soit, affichez le code source d'une page type et cherchez toutes les occurrences de application/ld+json. Vous serez souvent surpris.

4. Valider, tester et auditer son balisage

Deux outils officiels : le test des résultats enrichis de Google vérifie l'éligibilité aux affichages enrichis (il ne signale que les types que Google exploite réellement), et le Schema Markup Validator (validator.schema.org) valide la conformité au vocabulaire, indépendamment de ce que Google exploite (utile pour les types sans résultat enrichi associé, désormais le cas de FAQPage). Méthode : testez une page de chaque gabarit (accueil, catégorie, fiche produit, article) plutôt qu'une page au hasard, car une erreur de gabarit se répercute sur des milliers d'URL.

Dans Search Console, l'onglet Améliorations liste les types détectés. Les erreurs rendent l'élément inéligible (propriété obligatoire manquante) et se traitent en priorité ; les avertissements signalent des propriétés recommandées mais facultatives (l'élément reste éligible, n'y consacrez pas trois jours sur des pages sans enjeu) ; et les variations soudaines de volume sont le vrai signal : une chute brutale du nombre d'éléments valides indique presque toujours une régression introduite par une mise en production. C'est un contrôle à intégrer à la recette de tout chantier SEO technique.

5. Erreurs fréquentes à éviter

  1. Baliser du contenu non visible (le spammy structured markup) : la seule erreur de cette liste qui expose à une action manuelle. Déclarer un aggregateRating de 4,9 sans avis affiché entre exactement dans ce cadre. Règle : tout ce qui est balisé doit être visible et vérifiable par un visiteur.
  2. Les incohérences balisage/page (129 € affiché, 119 € déclaré) : sur un e-commerce, ces écarts déclenchent des refus d'affichage marchand.
  3. Le surbalisage : déclarer quinze types ne multiplie pas vos chances, cela dilue le signal et multiplie les points de rupture.
  4. Le balisage en double (thème + extension + apps) : contradictoire et souvent invalide.
  5. Ne pas mettre à jour lors des refontes : une refonte casse silencieusement le balisage. Ajoutez un contrôle des données structurées à votre recette de mise en production.
  6. Poursuivre des résultats enrichis qui n'existent plus : produire du FAQPage ou HowTo en escomptant un affichage retiré. Vérifiez toujours la documentation officielle avant d'engager un chantier.
  7. Confondre éligibilité et garantie : un balisage valide vous rend éligible, Google décide de l'affichage. Ne promettez jamais un affichage enrichi à votre direction.

Bien implémentées, les données structurées sont un des rares chantiers SEO dont l'effet est rapide, mesurable et sans contrepartie. Mal implémentées (doublons, incohérences, contenu non visible), elles deviennent un risque. Le contrôle par gabarit, intégré à un audit SEO, est ce qui sépare les deux.

Questions fréquentes

Les données structurées sont-elles un facteur de positionnement direct ?

Non. Google a confirmé à plusieurs reprises que les données structurées ne constituent pas un facteur de classement en tant que tel. Leur effet est indirect mais réel : elles conditionnent l'éligibilité aux résultats enrichis, qui améliorent le taux de clic à position égale, et le taux de clic influence la performance globale d'une page. Elles renforcent également la compréhension sémantique de votre contenu et l'identification de votre entité, ce qui compte de plus en plus pour les moteurs de réponse génératifs. En résumé : elles ne vous font pas monter, elles vous font mieux exister à la position que vous occupez.

Peut-on ajouter des données structurées via Google Tag Manager ?

Oui techniquement, et Google interprète le balisage injecté par GTM puisqu'il exécute le JavaScript. Ce n'est cependant pas la méthode à privilégier. L'injection côté client crée une dépendance à l'exécution du script, ajoute un délai avant que le balisage soit disponible, et surtout reste largement invisible pour les autres moteurs et pour les robots d'IA qui ne rendent pas systématiquement le JavaScript. GTM est une solution de contournement acceptable quand vous n'avez aucun accès au code source, jamais un choix par défaut.

Puis-je avoir une pénalité Google à cause de mauvaises données structurées ?

Oui. Google applique des actions manuelles pour balisage trompeur ou abusif (le spammy structured markup). Les cas typiques sont le balisage de contenu invisible pour l'utilisateur, les avis auto-attribués ou fabriqués, les prix et disponibilités ne correspondant pas à la page, et l'usage d'un type sans rapport avec le contenu réel. En pratique, une erreur technique de bonne foi n'entraîne pas de sanction : l'élément est simplement jugé inéligible. Le risque concerne le balisage volontairement décorrélé du contenu visible.

Quelle est la différence entre Schema.org et JSON-LD ?

Schema.org est le vocabulaire : un dictionnaire partagé qui définit les types (Product, Article, LocalBusiness) et leurs propriétés (name, price, author). Il est maintenu par un consortium regroupant Google, Microsoft, Yahoo et Yandex. JSON-LD est le format d'écriture : la syntaxe qui permet d'exprimer ce vocabulaire dans un bloc de code autonome. On écrit donc du Schema.org au format JSON-LD. Les microdonnées et RDFa sont deux autres formats pour le même vocabulaire, mais JSON-LD est celui que Google recommande.

À lire ensuite

Discutons de votre visibilité à Versailles

Pré-audit offert et devis sous 48 h. Réponse d’un consultant, pas d’un commercial.

ou appelez directement : +33 7 68 01 52 91