Les données structurées permettent de décrire le contenu d’une page avec des informations explicites pour les robots d’exploration : “ceci est un produit”, “ceci est une organisation”, “ceci est un fil d’Ariane”, “voici le prix”, “voici l’auteur”, etc.
Concrètement, on ajoute à la page un balisage (souvent basé sur la librairie schema.org) qui guide les crawlers des moteurs de recherche dans l’interprétation des pages.
Comprendre le fonctionnement des données structurées
Une donnée structurée associe :
- un type (par exemple Product, Article, Organization, BreadcrumbList)
- des propriétés (name, price, author, datePublished, availability…)
- des relations vers d’autres objets (objets imbriqués) via certaines propriétés
Avec l’intégration de données structurées, le contenu de la page ne change pas pour l’internaute. On ajoute juste une couche qui dit au moteur : “voilà comment interpréter cet élément spécifique de ma page”.
Type / propriété : mieux comprendre
Le type sert à dire ce que représente l’élément que l’on cherche à décrire. La propriété sert à préciser les informations que l’on veut décrire sur cet élément.
Les données structurées fonctionnent par blocs reliés.
Exemple : une page produit peut décrire un objet Product (le produit) relié à un objet Offer (l’offre) via la propriété offers (prix, devise, disponibilité).
À quoi servent les données structurées en SEO ?
Il y a deux usages principaux.
1 – Réduire l’ambiguïté
Le web est rempli de pages où tout est “clairement présenté” pour l’internaute… mais pas clairement identifiable pour une machine, par exemple :
- une date de publication vs une date de mise à jour
- un auteur vs une marque
- un prix “à partir de” vs un prix fixe
- un établissement local vs une entité nationale
Les données structurées servent surtout à stabiliser l’interprétation : elles donnent des repères précis, répétables, exploitables.
2 – Rendre une page éligible à des résultats enrichis
Selon le type de page et le balisage, Google peut afficher des éléments enrichis dans les résultats (fil d’Ariane, informations produit, etc.). C’est la partie visible, celle qui motive beaucoup de monde.
Un affichage loin d’être systématique dans les SERP
Éligible ne veut pas dire affiché. Le balisage donne les informations, mais l’affichage dépend du contexte et des choix du moteur. Même avec un balisage propre, les données structurées peuvent être ignorées si jugées non pertinentes dans le contexte de la recherche.
Comprendre le rôle et les limites des données structurées
Quand tout s’aligne (page, balisage, politiques, contexte), les données structurées peuvent contribuer à afficher un résultat plus riche : informations complémentaires, structure plus lisible, détails sur les produits…
Mais attention, les données structurées :
- ne remplacent pas un contenu pauvre
- ne transforment pas à elles seules une page confuse en page claire
- ne forcent pas un enrichissement dans la SERP
Le point important à retenir, c’est que le balisage ne “déclenche” rien tout seul : il vise à rendre la page plus explicite, et le moteur de recherche décide ensuite de ce qu’il exploite.
Le vrai bénéfice, au quotidien, est souvent plus discret : moins d’ambiguïtés, moins de “mauvais signaux”, et une base propre pour travailler son SEO.
Schema.org : le vocabulaire mis à disposition
schema.org met librement à disposition son vocabulaire, qui est à ce jour le plus utilisé pour écrire des données structurées : il s’agit d’une bibliothèque de types et de propriétés.
L’idée est simple : pour éviter que chaque site invente sa façon de décrire un produit ou un article, on s’appuie sur des termes communs. Cela permet aux moteurs (et aux outils) de reconnaître les mêmes concepts d’un site à l’autre.
Formats utilisés : JSON-LD, Microdata, RDFa
On rencontre trois formats principaux :
- JSON-LD : un bloc de données séparé du HTML
- Microdata : des attributs ajoutés dans les balises HTML
- RDFa : proche des microdata, plus orienté sémantique
En SEO, le JSON-LD est le plus courant parce qu’il est le plus simple à faire évoluer : il permet de centraliser le balisage, plutôt que de le disperser dans le markup.
Microdata : petite histoire d’un abus de langage
Le terme « microdata » reste aujourd’hui encore couramment utilisé dans la communauté SEO, par habitude. Au lancement de schema.org (juin 2011), Google mettait initialement en avant ce format, la structure JSON-LD n’étant alors pas encore prise en charge. Avec le temps, le mot a fini par être employé à tort comme synonyme de « données structurées », alors qu’il désigne en réalité un format précis.
Les données structurées que l’on rencontre le plus souvent en SEO
Il existe plusieurs familles de données structurées, et la documentation de Google évolue régulièrement pour en inclure des nouvelles. En pratique, on voit souvent revenir les mêmes “familles”, parce qu’elles correspondent à des templates classiques (page produit, article, fiche établissement…) et qu’elles décrivent des informations utiles dans de nombreuses situations.
BreadcrumbList (fil d’Ariane)
Le balisage BreadcrumbList décrit la position d’une page dans l’arborescence : accueil → catégorie → sous-catégorie → page.
Ce schéma est souvent utilisé parce qu’il parle de structure (la place de la page dans le site). Il devient particulièrement utile quand :
- l’URL est peu lisible (paramètres, tracking, filtres)
- la navigation est profonde
- la page peut être atteinte par plusieurs chemins (catégories, collections, univers…)
Ce qu’on retrouve généralement dedans : une liste d’éléments ordonnés (les “étapes”), avec un nom et une URL pour chacun.
Organization (et LocalBusiness)
Ces schémas décrivent l’entité derrière le site.
- Organization sert à poser l’identité du site : nom, logo, site officiel, profils, éventuellement des informations de contact.
- LocalBusiness sert quand la page représente un établissement (un lieu) : nom, adresse, téléphone, horaires, zone desservie, etc.
L’intérêt, c’est de cadrer l’entité : éviter qu’une marque soit interprétée comme autre chose, et donner une description cohérente de l’organisation sur l’ensemble du site.
Un même site peut utiliser les deux : l’organisation globale, et des pages dédiées à chaque établissement.
Article / BlogPosting
Pour les contenus éditoriaux, Article / BlogPosting sert surtout à structurer des infos simples mais sensibles aux confusions : titre, auteur, image principale, date de publication, date de modification, rubrique, etc.
Ça aide à “stabiliser” ce que la page raconte, surtout quand :
- l’auteur est une personne et la marque est très présente
- la page affiche plusieurs dates (publication, mise à jour)
- il y a des blocs qui ressemblent à des contenus secondaires (encarts, modules, recommandations)
Le point qui fait souvent la différence en SEO, c’est la clarté sur les dates : ce qui relève de la publication (datePublished) et ce qui relève d’une mise à jour (dateModified).
Product + Offer (e-commerce)
C’est le duo le plus courant en e-commerce, parce qu’il relie deux choses qui n’ont pas le même rôle :
- Product décrit ce que c’est (nom, marque, images, identifiants…).
- Offer décrit comment c’est vendu (prix, devise, disponibilité, URL, éventuellement conditions).
Ce duo est aussi celui qui demande le plus de rigueur, parce que les infos “offre” sont celles qui bougent le plus souvent : promo, rupture de stock, “à partir de”, variantes, packs…
« objets reliés » : mieux comprendre
Les données structurées s’organisent en objets connectés. Le prix est une propriété de l’objet Offer, lui-même rattaché à l’objet Product.
Review / AggregateRating (avis)
Le balisage d’avis (Review, AggregateRating) est très populaire parce qu’il peut, dans certains cas, ajouter des informations visibles dans les résultats (note, nombre d’avis). C’est aussi un balisage qui devient vite problématique dès qu’il y a un décalage entre ce que la page montre et ce que le schéma déclare.
Ce schéma devient pertinent quand la page :
- affiche réellement des avis (et pas juste une note décorative)
- affiche une note et/ou un nombre d’avis cohérents
- rattache ces avis à l’objet décrit (produit, établissement, contenu)
Là où ça se complique, c’est quand la note est calculée ailleurs, que les avis ne sont pas visibles sur la page, ou que les chiffres changent sans que le balisage suive. Dans ces cas, le schéma crée surtout un écart entre la page et ce qu’elle déclare, et Google a tendance à ne pas l’exploiter.
Mise en place : comment ça se passe vraiment
1 – Partir d’un template de page
Le balisage vise à être appliqué au niveau du gabarit, pour qu’il se retrouve automatiquement sur toutes les pages du même type.
Le bon premier réflexe est de lister les différents types de pages que l’on retrouve sur un site:
- page produit
- page catégorie
- page article
- page établissement
- page FAQ / support
- page recette / événement
- …
2 – Mapper le visible vers le balisage
Ensuite, sur chaque page, l’objectif devient de planifier la mise en place d’un balisage qui décrit ce que l’utilisateur voit :
- le prix affiché correspond au prix balisé
- la disponibilité affichée correspond à la disponibilité balisée
- la date affichée correspond à la date balisée
- l’image principale correspond à l’image balisée
Quand une page affiche “à partir de”, ou une fourchette, ou une promo conditionnelle, le balisage doit rester cohérent avec cette réalité-là (et ne pas proposer une version “simplifiée”).
3 – Écrire des JSON-LD lisibles et stables
L’objectif n’est pas d’empiler des propriétés, mais de rédiger des blocs minimalistes et cohérents sur toutes les pages du template pour communiquer toutes les informations essentielles.
Un schéma court mais cohérent se maintient mieux dans le temps qu’un schéma très détaillé qui devient faux dès que la logique de prix, de stock ou de variantes change. Un accompagnement SEO sur la durée devient vite indispensable, notamment sur un site e-commerce.
Contrôle et maintenance
Les données structurées ont un défaut : elles peuvent se dégrader sans bruit. Le site bouge (prix, promos, variantes, refonte), et si le balisage ne suit pas, cela peut créer un décalage.
Ce qui marche bien, c’est de contrôler à deux niveaux : sur une page (pour valider le template) et à l’échelle (pour repérer les cas qui échappent au template).
Contrôler une page (rapidement, comme Google)
Outil : Test des résultats enrichis (Google)
C’est l’outil le plus direct pour voir ce que Google comprend d’une URL et si elle est éligible à des résultats enrichis. Il permet de vérifier que les valeurs lues par Google correspondent à ce que la page affiche.
Suivre les erreurs dans Google Search Console
Dans Search Console, il y a deux endroits utiles :
Les rapports “Améliorations”
Quand Google prend en charge un type de résultat enrichi, Search Console affiche un rapport dédié.
Ces rapports permettent de voir au global :
- les erreurs bloquantes (champs manquants, format incorrect)
- les avertissements (champs recommandés)
- les URLs concernées (et donc le template qui casse)
C’est l’onglet qui sert le plus pour détecter les régressions après mise en prod.
Inspection d’URL
Quand une page pose question (une fiche produit qui “devrait” être OK mais ne remonte pas), l’inspection d’URL permet de :
- vérifier la dernière version explorée
- voir si la page est bien indexée
- repérer un décalage entre ce que vous pensez envoyer et ce que Google reçoit
Contrôler à l’échelle (pour éviter la loterie)
Tester 3 pages ne suffit pas si un template a des variantes ou des cas limites. Le contrôle global sert à repérer :
- les pages qui n’ont plus de balisage
- les champs vides (image manquante, prix vide, dates absentes)
- les incohérences récurrentes
Concrètement, pour avoir davantage d’informations qu’avec la Search Console, il faut passer par un crawl (avec un outil de crawl type ScreamingFrog ou Conductor) en récupérant les données structurées. Cette méthode d’analyse demande une expertise SEO plus poussée.
Pourquoi investir dans les données structurées en 2026 ?
Un enjeu EEAT plus que jamais central
L’E-E-A-T, c’est l’acronyme que Google utilise pour parler de la “qualité / fiabilité” d’un contenu.
Une partie de ces signaux de fiabilité dépend de points simples : identifier l’entité derrière le site, attribuer correctement un contenu à un auteur, distinguer date de publication et de mise à jour, éviter les confusions entre marque, auteur, établissement, groupe.
Les données structurées servent à éviter des lectures incorrectes et des signaux incohérents d’une page à l’autre. Elles stabilisent et explicitent les informations essentielles pour juger de l’expertise et de l’autorité d’une page.
Des éléments pour guider les IA sur votre site
Un moteur de recherche génératif comme celui utilisé par ChatGPT lance des recherches ciblées, recoupe, puis assemble une réponse. Pour cela, il a besoin d’identifier des informations faciles à reprendre.
En pratique, ces robots d’exploration d’un nouveau genre lisent en diagonale :
- ils scannent l’URL, les données structurées, les balises importantes, le haut de page, puis descendent seulement si ils estiment que ça vaut le coup
- ils préfèrent les contenus segmentés et faciles à extraire
- ils peuvent passer à côté de l’information essentielle quand elle est noyée dans la page
Dans ce contexte, les données structurées apportent une aide bienvenue : une version déclarative, sans ambiguïté, des objets clés.
Retrouvez les meilleures définitions dans le glossaire SEO de La Mandrette !
L’auteur : Titulaire d’un master en communication, Fantin Deliège a occupé plusieurs postes (rédacteur, chargé de projet) avant de devenir consultant à La Mandrette. Il met en œuvre les actions SEO sur les projets clients.