Données structurées et rich snippets : le guide pour booster votre SEO

Un client m'a envoyé un mail l'autre jour : « Sur Search Console, j'ai 1 400 pages indexées et 12 résultats enrichis. C'est grave ? » Douze. Sur quatorze cents. Il pensait avoir un problème de balisage. En réalité, il avait un problème de contenu que le balisage ne pouvait pas sauver.

C'est souvent là que tout se joue avec les données structurées : on croit qu'il suffit d'ajouter du code pour que Google décore nos liens d'étoiles et de prix. Sauf que les rich snippets ne sont pas une récompense technique. Ce sont une conséquence. Et comprendre cet ordre des choses change complètement la façon dont on aborde le sujet.

Données structurées et rich snippets : de quoi parle-t-on vraiment ?

Prenons une fiche produit. Le texte affiché dit « Chaise en chêne massif, 189 €, en stock ». C'est ce que lit l'humain. Le balisage, lui, dit à la machine : ceci est un Product, voici son price, voici son availability, voici la note moyenne des Review associés.

Voilà la définition des données structurées : une couche de vocabulaire normalisé, principalement schema.org, ajoutée au HTML pour décrire le sens du contenu. Le format s'écrit en JSON-LD la plupart du temps, parfois en microdata ou en RDFa pour les implémentations plus anciennes.

Données structurées et non structurées : la différence qui compte

Les données non structurées, c'est votre texte brut, vos paragraphes, vos images. Google les lit, les comprend plus ou moins bien, mais doit deviner. Les données structurées suppriment la devinette. Elles déclarent explicitement : « cette page parle d'une recette de cuisine, voici le temps de cuisson, voici les ingrédients, voici la note ».

Critère	Données non structurées	Données structurées
Nature	Texte libre, HTML classique	Vocabulaire normalisé (schema.org)
Lecture par Google	Interprétation, extraction heuristique	Lecture directe des propriétés déclarées
Effet visible	Aucun par défaut	Éligibilité à un résultat enrichi
Effort de mise en place	Nul	Modéré à élevé selon le type
Garantie de résultat	—	Aucune

Le tableau ci-dessus résume l'essentiel, mais il masque une réalité plus désagréable : le balisage coûte du temps de développement et ne rapporte rien de visible dans la grande majorité des cas. J'ai vu des équipes passer deux sprints sur du JSON-LD pour six fiches produits éligibles.

Un exemple de données structurées, concrètement

Pour une recette, le balisage ressemble à ceci (version simplifiée) :

• @type : Recipe
• name : le titre du plat
• recipeIngredient : la liste des ingrédients
• totalTime : la durée en format ISO 8601
• aggregateRating : la note et le nombre d'avis

Ce que Google peut en tirer : une vignette avec photo, note en étoiles et temps de préparation. Ce qu'il en tire réellement : à lui de décider. C'est la nuance que beaucoup d'articles oublient de préciser.

Ce que Google affiche vraiment : les types de rich snippets

Le catalogue officiel des types éligibles change régulièrement. Certains enrichissements ont été retirés, d'autres ajoutés, et les conditions d'éligibilité se resserrent au fil des mises à jour. Voici ce qui reste réellement utile en 2026, d'après ce que je vois sur les sites que je suis.

Les enrichissements visuels les plus fréquents

• Avis et notes en étoiles — sur les produits, les recettes, les œuvres. Le plus visible, le plus convoité.
• Prix et disponibilité — fiches e-commerce, avec la mention « en stock » ou « épuisé ».
• Fil d'Ariane — remplace l'URL brute par une arborescence lisible. Sous-estimé, franchement.
• FAQ — questions dépliables directement dans le résultat. Attention, l'éligibilité s'est beaucoup restreinte.
• Données d'entreprise — horaires, adresse, téléphone pour les commerces locaux.
• Durée de vidéo — affichée avec la vignette sur les résultats vidéo.

Et là, un point important. J'ai longtemps cru que le balisage FAQ était la martingale SEO absolue. J'en ai mis partout sur un site de services B2B, une soixantaine de pages. Résultat des courses : zéro FAQ enrichie affichée. Google avait visiblement décidé que ce site n'y avait pas droit. Le code était pourtant irréprochable au test. J'avais juste mal lu les règles d'éligibilité.

Featured snippet ou rich snippet : ne confondez plus

La confusion revient sans arrêt, alors je la traite frontalement. Le featured snippet occupe la position zéro, en haut de page, et répond directement à une question en reprenant un extrait de votre contenu. Aucun balisage n'est nécessaire pour l'obtenir : c'est un algorithme qui décide que votre page répond le mieux.

Le rich snippet, lui, est un résultat normal, à sa position normale, mais visuellement enrichi grâce au balisage. Il ne se place pas au-dessus des autres. Il se distingue dans la liste.

Un article de blog sans aucun code peut donc décrocher un featured snippet. Une fiche produit parfaitement balisée peut n'obtenir aucun enrichissement. Deux mécanismes, deux logiques.

Comment tester ses données structurées (et corriger les erreurs)

Un balisage qui ne passe pas la validation ne sert à rien. Et un balisage qui la passe ne sert pas forcément à grand-chose non plus, mais au moins il est éligible. Deux outils font le travail : le test des résultats enrichis de Google, et le rapport sur les résultats enrichis dans Search Console.

La procédure que j'applique systématiquement

1. Coller l'URL de la page dans le test des résultats enrichis.
2. Vérifier les types détectés et les propriétés obligatoires manquantes.
3. Corriger les erreurs signalées, puis repasser le test.
4. Laisser Google recrawler (parfois une à deux semaines), puis consulter Search Console.

Sur Search Console, le rapport classe les problèmes en trois niveaux : erreurs, avertissements, pages valides. Ne négligez pas les avertissements. Ils signifient souvent que la page est éligible au type mais qu'une propriété recommandée manque — et cette propriété peut faire la différence à l'affichage.

Les erreurs que je vois le plus souvent

Elles reviennent avec une régularité déconcertante :

• Un balisage qui décrit un contenu absent de la page (avis inventés, note gonflée). Google sanctionne. Et c'est légitime.
• Des propriétés obligatoires oubliées, comme price ou reviewRating selon le type.
• Un JSON-LD placé dans le body plutôt que dans le head ou en fin de page, avec des conflits entre plusieurs blocs.
• Un balisage dupliqué entre page parent et pages enfants, qui se neutralisent.

La plus vicieuse reste la première. J'ai un jour gonflé une note moyenne de 4,1 à 4,8 en arrondissant « légèrement » un agrégat. Le snippet est apparu trois semaines, puis a disparu sans explication. Leçon retenue.

L'impact réel sur le SEO et le taux de clic

Voilà où je vais être direct. Le gain d'un rich snippet sur le taux de clic existe, mais il est très inégal selon le secteur et le type d'extrait. Sur un comparateur de prix, la présence du prix et de la disponibilité dans le résultat peut faire basculer un clic. Sur un blog éditorial, l'effet est beaucoup moins net.

Ce que j'ai mesuré sur mes propres projets

Sur un site e-commerce de matériel outdoor, l'ajout du balisage Product avec prix et note a fait passer le CTR moyen des pages catégories d'environ 2,6 % à 3,4 % en trois mois — soit une hausse de l'ordre de 30 %. Le trafic, lui, n'a pas bougé d'un centimètre, parce que les positions moyennes étaient déjà stables. Le gain venait purement du clic.

À l'inverse, sur un site de contenu juridique, j'ai implémenté du balisage Article complet. Effet mesuré sur le CTR : proche de zéro. Google n'affichait presque rien de visible. Le balisage était correct, mais le type ne produit pas d'enrichissement spectaculaire.

Autrement dit : tous les balisages ne se valent pas. Et il faut le savoir avant de mobiliser une équipe.

La règle non négociable : la cohérence

Google exige que le balisage reflète fidèlement le contenu visible. Un avis présent dans le JSON-LD mais absent de la page est un cas de balisage trompeur. Un prix balisé différent du prix affiché, idem. Ce n'est pas une recommandation, c'est une condition d'éligibilité.

Je vérifie systématiquement cette cohérence avant de livrer, page par page. C'est fastidieux. C'est indispensable.

La bonne stratégie : baliser ce qui mérite de l'être

Le piège du débutant, c'est de vouloir tout baliser. Le réflexe du praticien expérimenté, c'est l'inverse : ne rien baliser qui ne soit éligible à un enrichissement utile.

Ma méthode de priorisation

• Lister les types déjà présents dans votre secteur d'activité, ceux qui s'affichent réellement chez les concurrents.
• Vérifier l'éligibilité de chaque type sur les pages concernées, pas en théorie mais dans Search Console.
• Ne baliser que ce que vous êtes capable de tenir dans le temps (une note évolue, un stock aussi).
• Ignorer les types qui n'ont pas d'effet visuel mesurable sur votre verticale.
• Revoir le tout deux fois par an. Le catalogue bouge.

Franchement, c'est cette étape de sélection qui fait la différence entre un projet de balisage rentable et un chantier interminable. J'ai déjà vu une équipe passer des semaines sur des types qui n'apparaissaient jamais, faute d'éligibilité.

Ce que le balisage ne fera jamais pour vous

Il ne rendra pas bon un contenu médiocre. Il ne fera pas remonter une page qui ne mérite pas sa position. Il ne garantit aucun affichage. Il n'améliore pas la compréhension du contenu par Google si le contenu lui-même est vague.

Ce qu'il fait : il déclare. Il lève l'ambiguïté. Il donne à Google les moyens de valoriser votre page si elle le mérite déjà. C'est un amplificateur, pas un moteur.

Et c'est peut-être la meilleure façon de trancher un arbitrage interne : si votre page n'est pas déjà compétitive sur son sujet, investir dans les données structurées revient à repeindre une façade sans consolider les murs. Ça se voit. Ça ne tient pas.

Une dernière chose, et c'est celle sur laquelle je termine toujours en formation : la valeur réelle de vos données structurées se mesure dans les rapports de performance de Search Console, sur des périodes de trois mois minimum, comparées à des pages équivalentes non balisées. Si vous n'avez pas ce point de comparaison, vous ne saurez jamais si votre balisage a servi à quoi que ce soit. Et à mon avis, c'est la question à se poser avant d'écrire la première ligne de JSON.