Données structurées : le guide complet 2026 (Schema.org, JSON-LD, rich snippets et IA)

Les données structurées sont un balisage normalisé, le plus souvent en JSON-LD et basé sur le vocabulaire Schema.org, qui décrit explicitement le contenu d'une page aux machines : « ceci est un produit, à ce prix, noté 4,6/5 ».

Elles ne sont pas un facteur de classement direct. Elles peuvent rendre une page éligible à certaines fonctionnalités enrichies de Google et fournir des informations explicites sur son contenu. Pour les fonctionnalités d’IA de Google Search, aucun balisage Schema.org spécial n’est requis : les données structurées restent surtout utiles dans le cadre du SEO classique lorsqu’elles correspondent au contenu visible.

Qu’est-ce que les données structurées ?

Les données structurées, en SEO, désignent un bloc d'information ajouté au code d'une page web pour décrire son contenu de manière explicite et normalisée. Là où le texte visible dit « Chaise en chêne massif : 249 € : 4,6/5 (128 avis) », les données structurées disent à la machine : @type: Product, name: Chaise en chêne massif, offers.price: 249, aggregateRating.ratingValue: 4.6, reviewCount: 128. Le contenu ne change pas pour l'internaute. Sa lisibilité machine, elle, change radicalement.

L'analogie la plus juste est celle de l'étiquette produit. Sans étiquette, un robot doit deviner à partir de la photo et du texte libre : il y arrive souvent, mais avec une marge d'erreur. Avec une étiquette normalisée : référence, prix, poids, composition : il ne devine plus, il lit. Les données structurées jouent exactement ce rôle : elles suppriment l'ambiguïté au moment du crawl et de l'indexation.

Google est clair sur ce point dans sa documentation Search Central : le balisage l'aide à comprendre la page et rend celle-ci éligible à des fonctionnalités de recherche spécifiques. C'est un contrat de lisibilité, pas un levier de position.

Données structurées, semi-structurées et non structurées : quelle différence ?

Le terme prête à confusion, parce qu'il existe deux acceptions. Dans le monde de la data et de la BI, « données structurées » désigne des données organisées selon un schéma prédéfini, typiquement une base relationnelle ou un fichier CSV. En SEO, on parle du balisage sémantique d'une page web. Les deux notions partagent la même idée fondatrice : un format prévisible que la machine peut interpréter sans interprétation.

• Données non structurées : du texte libre, une image, une vidéo, un enregistrement audio. Aucun schéma. Ces contenus n’imposent pas de schéma explicite et doivent être interprétés par les moteurs.
• Données semi-structurées : du contenu accompagné de métadonnées ou d'une hiérarchie, sans schéma rigide : un fichier XML, un JSON, un e-mail avec ses en-têtes. Le balisage Schema.org appartient techniquement à cette famille.
• Données structurées : un schéma strict, des champs typés, des valeurs attendues : une table SQL, un CSV, un flux produit.

En SEO, l’usage courant emploie « données structurées » pour désigner le balisage Schema.org. C’est ce sens qui est retenu ici.

Qu'est-ce que Schema.org et qui le gouverne ?

Schema.org est le vocabulaire partagé qui donne un sens commun au balisage. Lancé en 2011 par Google, Microsoft (Bing), Yahoo et Yandex, il définit une collection de types : Product, Article, Event, Organization, Person, Recipe… : et, pour chaque type, une liste de propriétés autorisées. Product accepte name, sku, brand, offers, aggregateRating. Event accepte startDate, location, performer. Le vocabulaire est ouvert, versionné, et enrichi plusieurs fois par an.

Il faut distinguer deux niveaux. Schema.org, c'est le dictionnaire : tous les mots existants. La documentation Google, c'est le sous-ensemble que Google exploite réellement pour afficher un résultat enrichi, avec ses propres exigences de propriétés obligatoires. Un balisage peut être parfaitement valide au regard de Schema.org et totalement inutile pour Google. C'est la première source de déception des équipes qui déploient un balisage sans lire les exigences par fonctionnalité.

Trois notions reviennent en permanence et méritent d'être posées maintenant. Le balisage est le code ajouté à la page pour porter cette description. JSON-LD (JavaScript Object Notation for Linked Data) est le format d'écriture recommandé : un objet JSON isolé dans une balise script, indépendant du HTML visible. Une entité est une chose identifiable de manière unique : votre entreprise, un produit, une personne, un lieu : que le balisage permet de nommer, de typer et de relier à d'autres sources via des propriétés comme sameAs ou @id.

Exemple concret : une page produit avec et sans balisage

Prenons une fiche produit e-commerce classique. Sans balisage, Google voit un titre <h1>, des paragraphes, un nombre suivi d'un symbole euro, des étoiles rendues en CSS. Il déduit correctement qu'il s'agit probablement d'un produit dans la majorité des cas, mais il ne sait ni si le prix affiché est TTC, ni si le produit est en stock, ni si la note 4,6 concerne ce produit ou la boutique.

Avec ce balisage, plus aucune ambiguïté :

{ "@context": "https://schema.org", "@type": "Product", "name": "Chaise Oslo en chêne massif", "sku": "CH-OSLO-001", "brand": { "@type": "Brand", "name": "Atelier Nord" }, "offers": { "@type": "Offer", "price": "249.00", "priceCurrency": "EUR", "availability": "https://schema.org/InStock", "url": "https://exemple.fr/chaise-oslo" }, "aggregateRating": { "@type": "AggregateRating", "ratingValue": "4.6", "reviewCount": "128" }}

Résultat possible dans la SERP : le prix, la disponibilité ou les avis peuvent apparaître lorsque la fonctionnalité est disponible et que la page est éligible. L’affichage reste décidé par Google et son impact sur le CTR varie selon la requête et la présentation réelle du résultat.

À quoi servent les données structurées en SEO ?

Beaucoup de contenus se contentent d'affirmer que « les données structurées améliorent le SEO ». C'est à la fois vrai et paresseux. Voici ce qu'elles font réellement, et ce qu'elles ne font pas.

Rendre une page éligible aux résultats enrichis

Le bénéfice le plus tangible est l’éligibilité à certaines fonctionnalités enrichies prises en charge par Google : informations produit, fil d’Ariane, événements, recettes, offres d’emploi ou vidéos selon les cas. Le balisage doit respecter les propriétés et règles propres à la fonctionnalité visée, mais sa présence ne garantit jamais l’affichage.

Certains formats vont plus loin que l'extrait : les carrousels de produits ou de recettes, les résultats d'événements groupés, les vignettes vidéo dans l'onglet Vidéos. Tous reposent sur un balisage valide et conforme aux exigences de la fonctionnalité visée.

Améliorer le taux de clic sans gagner de position

Un résultat enrichi peut modifier la présentation du résultat et encourager davantage d’interactions, mais son effet dépend du type de requête, du résultat affiché et du secteur. Google publie plusieurs études de cas montrant des gains sur certains sites, sans qu’ils puissent être généralisés à toutes les implémentations.

L’effet éventuel se mesure surtout dans Search Console, en comparant les pages et apparences de recherche concernées avant et après le déploiement. Il ne faut pas attribuer automatiquement une variation de trafic au balisage si d’autres changements ont eu lieu en parallèle.

Aider Google à comprendre votre entité (Knowledge Graph)

Le balisage Organization sur votre page d'accueil, associé à sameAs pointant vers vos profils officiels (LinkedIn, Wikidata, réseaux sociaux) et à un @id stable, aide Google à consolider une fiche d'entité cohérente dans son Knowledge Graph. Ce balisage fournit à Google des informations explicites sur l’organisation et peut contribuer à relier des représentations cohérentes d’une même entité.

Pour les fonctionnalités d’IA de Google Search, Google précise qu’aucun balisage Schema.org spécial n’est nécessaire. Les données structurées doivent surtout rester exactes et cohérentes avec le contenu visible de la page.

Les données structurées sont-elles un critère de classement ?

Non. Google l'a répété à de nombreuses reprises : les données structurées ne sont pas un facteur de classement direct. Ajouter un Article bien balisé ne fera pas passer une page de la position 14 à la position 4.

Leur rôle principal est de fournir des informations explicites sur le contenu et, lorsqu’un type est pris en charge, de rendre la page éligible à des fonctionnalités enrichies. Elles ne doivent pas être présentées comme un moyen d’améliorer directement le classement ou de déclencher une visibilité IA.

JSON-LD, Microdata ou RDFa : quel format choisir ?

Trois syntaxes permettent d'exprimer le vocabulaire Schema.org. La réponse tient en une ligne : utilisez JSON-LD. Voici pourquoi.

Microdata consiste à annoter directement le HTML visible avec des attributs itemscope, itemtype et itemprop. RDFa (Resource Description Framework in Attributes) fait de même avec vocab, typeof et property, dans une logique héritée du web sémantique. Les deux fonctionnent, mais couplent le balisage au balisage HTML : la moindre refonte de template casse la sémantique, silencieusement.

Le même produit, en Microdata :

<div itemscope itemtype="https://schema.org/Product"> <h1 itemprop="name">Chaise Oslo en chêne massif</h1> <div itemprop="offers" itemscope itemtype="https://schema.org/Offer"> <span itemprop="price" content="249.00">249 €</span> <meta itemprop="priceCurrency" content="EUR"> </div></div>

Verbeux, fragile, dépendant du DOM. JSON-LD sépare le balisage du HTML visible, ce qui simplifie généralement sa maintenance. Si un site utilise déjà correctement Microdata ou RDFa, une migration n’est pas obligatoire : Google prend en charge les trois formats.

Quels types de données structurées existent et lesquels prioriser ?

Schema.org propose un vocabulaire bien plus large que les fonctionnalités de données structurées prises en charge par Google Search. La question utile n’est donc pas « que peut-on baliser ? », mais « quels types correspondent réellement au contenu et à l’usage recherché ? ».

Les types qui génèrent un résultat enrichi dans Google

Ces types déclenchent, sous conditions, une fonctionnalité visible dans la SERP :

• Product / Offer / AggregateRating / Review : peuvent fournir des informations sur le prix, la disponibilité et les avis lorsque les exigences de Google sont respectées.
• BreadcrumbList : aide Google à représenter la position d’une page dans la hiérarchie du site.
• Article / NewsArticle / BlogPosting : aide Google à mieux comprendre le titre, les images, les dates et l’auteur. Aucun balisage Article n’est requis pour être éligible à Google Actualités ou À la une.
• Event : dates, lieux, billetterie, avec affichage groupé possible.
• Recipe : note, temps de préparation, calories, image : un des rich results les plus visuels.
• JobPosting : intégration dans l'expérience de recherche d'emploi de Google.
• VideoObject : vignette vidéo, moments clés, indexation dans l'onglet Vidéos.
• LocalBusiness : informations d'établissement, horaires, adresse, en appui du référencement local.
• SoftwareApplication : notes et prix pour les applications et outils SaaS.

Les types utiles même sans rich snippet (Organization, WebSite, Person, sameAs)

Certains balisages servent surtout à décrire explicitement une organisation, une personne ou un site, sans produire nécessairement un affichage spécifique dans la SERP.

• Organization : décrit l’identité de l’entreprise avec des propriétés telles que le nom, le logo, l’adresse, les contacts ou certains identifiants.
• WebSite : nom du site et, le cas échéant, action de recherche interne. Aide Google à distinguer le nom du site de son domaine.
• WebPage : typage de la page et rattachement à l'entité éditrice.
• Person : peut décrire un auteur, un dirigeant ou un expert lorsque la page représente réellement cette personne.
• sameAs et @id : sameAs peut relier une entité à d’autres URL qui la représentent, tandis que @id permet de réutiliser un identifiant stable dans plusieurs objets structurés.

Ces propriétés peuvent aider à décrire une organisation, une personne ou un site de manière cohérente. Elles ne garantissent toutefois aucune citation dans un moteur génératif.

Matrice de priorisation par type de site (SaaS, e-commerce, média, service local, site vitrine)

Voici, par typologie, les balisages à examiner en priorité. La matrice ne remplace pas la documentation Google : un type n’a de valeur que s’il correspond au contenu réellement visible sur la page et, pour un résultat enrichi, à une fonctionnalité encore prise en charge.

E-commerce

Commencez par Product et Offer sur les fiches produit, puis BreadcrumbList pour la navigation et Organization pour les informations sur l’entreprise. Selon le modèle commercial, les propriétés liées aux variantes, à la livraison, aux retours et aux programmes de fidélité peuvent compléter le dispositif. Les données structurées ne remplacent pas Merchant Center lorsque ce canal est pertinent.

SaaS B2B

Organization et BreadcrumbList constituent une base utile. SoftwareApplication n’est pertinent que si la page décrit réellement une application et respecte les exigences de la fonctionnalité. Les contenus éditoriaux peuvent utiliser Article ou BlogPosting lorsqu’ils correspondent au type de page. Pour les profils d’experts ou d’auteurs, ProfilePage peut être étudié lorsque la page répond à la définition attendue par Google.

Média ou blog

Article, NewsArticle ou BlogPosting permettent de fournir des informations explicites sur le titre, les images, les dates et l’auteur. BreadcrumbList aide à représenter la hiérarchie. Organization et, selon les pages, ProfilePage peuvent compléter l’identification de l’éditeur et des contributeurs. Il faut surtout maintenir des dates, auteurs et images cohérents avec ce que l’utilisateur voit.

Service local

LocalBusiness est prioritaire lorsque la page représente réellement un établissement ou une entreprise locale et que les propriétés applicables sont disponibles. Organization et BreadcrumbList complètent le balisage global. N’ajoutez pas un type uniquement parce qu’il semble proche de votre activité : vérifiez toujours qu’il est pris en charge par Google pour l’usage recherché.

Site vitrine ou agence

Organization, BreadcrumbList et Article sur les contenus éditoriaux couvrent généralement les besoins les plus courants. Ajoutez d’autres types seulement lorsque la page correspond réellement à leur définition et que les informations peuvent être maintenues dans le temps.

Le cas FAQPage et HowTo en 2026

La stratégie a changé. Google a cessé d’afficher les résultats enrichis HowTo en 2023. Les résultats enrichis FAQ ont ensuite été dépréciés dans Google Search à partir du 7 mai 2026. Il ne faut donc plus présenter FAQPage ou HowTo comme des leviers de visibilité SERP pour un site classique.

Vous pouvez conserver un balisage Schema.org si un autre système l’utilise et s’il décrit fidèlement le contenu, mais il ne faut pas lui attribuer un bénéfice Google qui n’existe plus. Pour une FAQ éditoriale, la priorité reste une structure lisible et des réponses utiles, sans dépendre d’un rich result.

Comment ajouter des données structurées à une page en 6 étapes ?

1. Choisir la fonctionnalité et le type réellement adaptés

Partez de la galerie des données structurées prises en charge par Google Search, puis ouvrez la documentation du type visé. Vérifiez que la fonctionnalité existe encore, qu’elle correspond au contenu de la page et que votre site remplit les éventuelles conditions spécifiques.

2. Lister les propriétés obligatoires et recommandées

Renseignez toutes les propriétés obligatoires pour l’éligibilité et ajoutez les propriétés recommandées qui existent réellement dans votre contenu. Ne créez jamais une note, un prix, une disponibilité, une date ou une identité uniquement pour compléter le balisage.

3. Générer un JSON-LD cohérent avec le contenu visible

JSON-LD est généralement le format le plus simple à maintenir, même si Google prend aussi en charge Microdata et RDFa. Les valeurs du balisage doivent correspondre aux informations visibles ou accessibles à l’utilisateur. Utilisez des identifiants stables lorsque vous reliez plusieurs objets, par exemple une Organization réutilisée avec le même @id.

4. Intégrer le balisage dans la page ou le template

Un bloc JSON-LD peut être placé dans le head ou le body. Google peut également lire du JSON-LD injecté dynamiquement par JavaScript si le contenu est correctement rendu et accessible. Sur un CMS, privilégiez une génération depuis les champs réels de la page plutôt qu’un copier-coller manuel impossible à maintenir.

5. Valider avant la mise en production

Le Rich Results Test vérifie l’éligibilité aux fonctionnalités Google prises en charge et signale les erreurs ou avertissements correspondants. Le Schema Markup Validator vérifie plus largement la conformité au vocabulaire Schema.org. Les deux outils répondent à des questions différentes et sont complémentaires.

6. Déployer sur un échantillon et contrôler le rendu Google

Commencez par quelques pages représentatives, puis utilisez l’inspection d’URL pour vérifier la version vue par Google. Une fois le déploiement validé, étendez le balisage aux templates concernés. L’envoi d’une demande d’indexation ou d’un sitemap peut faciliter la découverte, mais ne garantit ni l’indexation ni l’affichage d’un résultat enrichi.

Comment déployer les données structurées à grande échelle ?

À grande échelle, la qualité du modèle de données compte davantage que le nombre de blocs ajoutés. Le balisage doit être généré depuis une source fiable et suivre les mêmes règles que le contenu visible.

Générer le balisage depuis le CMS

Associez chaque propriété Schema.org à un champ réel : nom, prix, image, auteur, date, adresse ou disponibilité. Si une valeur est absente, définissez une règle explicite plutôt que d’injecter une donnée fictive. Les champs conditionnels évitent de publier des propriétés vides ou incohérentes.

Réutiliser des identifiants stables

Pour les entités récurrentes comme l’organisation ou un auteur, utilisez des @id stables et cohérents sur le site. L’objectif est de relier proprement les objets, pas de multiplier des versions contradictoires d’une même entité.

Tester par gabarit

Constituez un échantillon pour chaque template : produit en stock, produit indisponible, article avec auteur, article mis à jour, établissement avec horaires, page sans donnée optionnelle. Cette recette par cas limite les erreurs qui se propagent ensuite sur des centaines ou milliers d’URL.

Versionner les changements

Traitez le balisage comme du code. Documentez les champs sources, les règles conditionnelles et les modifications de template. Une mise à jour du front, du CMS ou du flux produit peut casser silencieusement le JSON-LD si personne ne contrôle les dépendances.

Quelles erreurs de données structurées faut-il éviter ?

• Déclarer une information absente ou différente du contenu visible.
• Ajouter de faux avis, notes, prix, disponibilités ou auteurs.
• Utiliser un type qui ne correspond pas au contenu principal de la page.
• Oublier des propriétés obligatoires pour la fonctionnalité Google visée.
• Générer plusieurs blocs contradictoires pour la même entité.
• Laisser des dates, devises, URL ou identifiants obsolètes après une mise à jour.
• Bloquer la page à Googlebot ou appliquer noindex tout en attendant un résultat enrichi.
• Déployer un template sur tout le site sans tester plusieurs cas réels.
• Confondre validation Schema.org et éligibilité à un résultat enrichi Google.
• Présenter un balisage déprécié comme un levier encore actif dans Google Search.

Comment tester et surveiller ses données structurées ?

Le contrôle doit intervenir avant et après le déploiement. Aucun outil unique ne couvre à la fois la syntaxe Schema.org, l’éligibilité Google, le rendu de la page et les éventuelles actions manuelles.

Rich Results Test

Utilisez-le pour les types et fonctionnalités pris en charge par Google Search. Il indique les éléments détectés, les erreurs critiques et les propriétés recommandées lorsque la fonctionnalité les expose.

Schema Markup Validator

Utilisez-le pour vérifier le vocabulaire et la structure Schema.org au-delà des seuls rich results Google. Un balisage peut être valide dans Schema.org sans être exploité par une fonctionnalité Google.

Inspection d’URL et Search Console

L’inspection d’URL permet de vérifier comment Google voit une page. Search Console peut ensuite signaler des problèmes sur certaines apparences ou améliorations prises en charge et affiche également les actions manuelles lorsqu’un problème de données structurées enfreint les consignes.

Les données structurées sont-elles utiles pour les moteurs IA ?

Pour Google AI Overviews et AI Mode, Google indique qu’aucun balisage Schema.org spécial n’est nécessaire et qu’il ne faut pas surinvestir dans les données structurées pour l’IA. Les fondamentaux restent les mêmes : contenu accessible, utile, original, correctement indexable et cohérent avec les informations structurées présentes sur la page.

Pour d’autres assistants ou moteurs, les mécanismes de récupération et de citation diffèrent et évoluent rapidement. Il est donc raisonnable de conserver des données structurées exactes et maintenables, mais pas de promettre qu’un schéma, sameAs ou @id déclenchera une citation dans ChatGPT, Perplexity ou un autre système.

Checklist avant de publier des données structurées

• Le type correspond au contenu principal et à une documentation actuelle.
• Les propriétés obligatoires de la fonctionnalité visée sont présentes.
• Les propriétés recommandées ajoutées correspondent à des informations réelles.
• Les données structurées correspondent au contenu visible de la page.
• Les URL, images, dates, prix et identifiants sont à jour.
• Le balisage est valide dans l’outil adapté à l’objectif.
• La page est accessible à Googlebot et n’est pas bloquée par noindex.
• Le template a été testé sur plusieurs cas représentatifs.
• Le déploiement peut être maintenu lorsque les données du CMS changent.
• Aucun résultat enrichi ou bénéfice IA n’est présenté comme garanti.

Conclusion

Les données structurées sont une couche de description, pas un raccourci vers de meilleures positions. En 2026, la bonne stratégie consiste à choisir les types réellement pris en charge et utiles au contenu, utiliser un balisage exact et maintenable, valider le rendu puis surveiller Search Console. Les fonctionnalités évoluent : la dépréciation des FAQ rich results rappelle qu’un déploiement doit être piloté par la documentation actuelle, pas par une checklist figée.

FAQ sur les données structurées

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

Non. Leur présence ne constitue pas un facteur de classement direct. Elles fournissent des informations explicites sur la page et peuvent rendre un contenu éligible à certaines fonctionnalités de recherche lorsqu’un type est pris en charge.

Quel format choisir entre JSON-LD, Microdata et RDFa ?

Google prend en charge les trois formats. JSON-LD est généralement le plus simple à implémenter et à maintenir, raison pour laquelle il est recommandé dans la plupart des configurations.

Où placer le JSON-LD ?

Un bloc JSON-LD peut être placé dans le head ou le body de la page. Google peut également lire des données JSON-LD injectées dynamiquement par JavaScript lorsque la page reste accessible et que le balisage est correctement rendu.

Pourquoi mon résultat enrichi ne s’affiche-t-il pas alors que le test est valide ?

Parce que la validation rend seulement la page éligible. Google ne garantit jamais l’affichage d’un résultat enrichi. La page doit aussi respecter les consignes générales, les règles de la fonctionnalité et rester accessible à Google.

FAQPage est-il encore utile pour obtenir un rich result ?

Non pour Google Search en 2026 : la fonctionnalité de résultat enrichi FAQ a été dépréciée à partir du 7 mai 2026. Un balisage FAQPage peut être conservé pour d’autres usages s’il décrit réellement le contenu, mais il ne faut plus l’implémenter dans le seul objectif d’obtenir un affichage FAQ dans Google.

Faut-il des données structurées spéciales pour AI Overviews ou AI Mode ?

Non. Google précise qu’aucun Schema.org spécial n’est requis pour ses fonctionnalités d’IA générative. Les données structurées classiques restent utiles lorsqu’elles décrivent fidèlement la page et servent les fonctionnalités de recherche prises en charge.