Données structurées SEO : le balisage qui produit encore un rich snippet, et celui que Google a supprimé
Deux fiches produit, même mot-clé, positions voisines. La première affiche un prix, un stock, quatre étoiles et le nombre d'avis. La seconde affiche un titre bleu et deux lignes de texte gris.
Le prix et les étoiles ne viennent pas d'un meilleur classement. Ils viennent d'un bloc de code que personne ne voit, posé dans le HTML de la page.
C'est tout le sujet des données structurées. Et c'est aussi là que la moitié des conseils qui circulent en français sont périmés depuis trois ans.
Comprendre les données structurées : ce que les moteurs de recherche y lisent, et ce qu'ils n'y lisent pas
Une page web raconte des choses qu'un humain comprend au premier coup d'œil. Un prix, une date, une note sur cinq. Un moteur de recherche, lui, ne voit qu'une suite de balises et de texte.
Les données structurées comblent cet écart. Elles ajoutent au code un étiquetage explicite : ceci est un prix, ceci est un auteur, ceci est une durée de cuisson. Les moteurs de recherche n'ont plus à deviner, et Google s'en sert pour comprendre le contenu de la page.
Ces étiquettes enrichissent ensuite l'affichage. Ce vocabulaire s'appelle schema.org. Il a été fondé par Google, Microsoft, Yahoo et Yandex, et il est aujourd'hui gouverné par un groupe communautaire du W3C.
Attention au piège de gouvernance, il coûte cher en pratique. Schema.org définit des centaines de types. Google n'en exploite qu'une fraction. Sa propre documentation le dit sans détour : c'est le site Google Developers qui fait foi sur le comportement de Google, pas le vocabulaire schema.org.
Reste la question que tout le monde pose en premier. Est-ce que ça fait monter la page ?
Non. Et Google le formule d'une façon qui ne laisse aucune place au doute : une sanction manuelle liée au balisage fait perdre à la page son éligibilité aux résultats enrichis, sans affecter son classement dans la recherche web. Si le pire scénario n'entame pas les positions, le bon scénario ne les crée pas non plus.
Le balisage ne change pas votre rang. Il change ce que votre ligne occupe dans les résultats de recherche Google une fois qu'elle est affichée. C'est un levier de taux de clic, pas de classement, et la documentation de Google sur le fonctionnement des données structurées ne prétend rien d'autre.
JSON-LD, Microdata, RDFa : trois formats de balisage schema.org, un seul à retenir
Le même contenu peut être décrit de trois façons. Le format des données change, l'information reste identique.
JSON-LD vit dans un bloc <script type="application/ld+json">, séparé du texte visible. Microdata et RDFa vivent dans les attributs des balises HTML elles-mêmes, mêlés au contenu que l'utilisateur lit.
Cette différence d'emplacement décide de tout le reste. Un balisage collé aux balises visibles est solidaire du template. Le jour où un développeur change un <div> en <section>, les microdonnées partent avec.
| Format | Emplacement | Mêlé au HTML visible | Lu quand injecté en JavaScript | Adoption mesurée (Web Almanac 2024) |
|---|---|---|---|---|
| JSON-LD | <script> dans <head> ou <body> |
non | oui, documenté par Google | 41 % des pages |
| Microdata | attributs HTML, surtout dans <body> |
oui | non documenté | 26 % des pages |
| RDFa | attributs HTML, <head> et <body> |
oui | non documenté | 66 % des pages, dont 64 % d'Open Graph |
La ligne qui tranche est la quatrième. Google documente qu'il lit le JSON-LD injecté dynamiquement par du JavaScript. Il ne dit ça d'aucun autre format.
Sur une application React, Vue ou headless, le débat s'arrête là.
Une nuance quand même, parce qu'elle est recopiée de travers partout. Google n'écrit pas que JSON-LD est son « format préféré ».
Il écrit qu'il le recommande parce que c'est le plus simple à maintenir à grande échelle, et le moins exposé aux erreurs humaines. Les trois formats sont traités à égalité s'ils sont valides.
Un dernier mort-vivant traîne dans les vieux thèmes WordPress : le balisage data-vocabulary.org. Il n'est plus éligible à quoi que ce soit depuis des années.
Les rich snippets que Google n'affiche plus, et que la moitié du web balise encore
Voilà la partie que les guides français ne mettent pas à jour.
Le balisage FAQ ne produit plus aucun affichage dans Google. Le balisage HowTo non plus. Ce sont pourtant les deux schémas les plus recommandés par les articles qui sortent en première page sur ce sujet.
HowTo est parti en septembre 2023, sur ordinateur comme sur mobile. Google a retiré sa documentation à ce moment-là.
FAQ a tenu plus longtemps, en régime restreint, puis a disparu. La fonctionnalité a cessé d'apparaître le 7 mai 2026. L'avis de dépréciation est daté du 8 mai, et la documentation a été retirée en juin.
Cinq autres types ont perdu leur page le 9 septembre 2025 : course info, estimated salary, learning video, special announcement, vehicle listing. Practice problem a été annoncé en novembre 2025, et sa documentation retirée en janvier 2026.
| Type de balisage | Statut | Date | Que faire |
|---|---|---|---|
| HowTo | résultat enrichi supprimé | septembre 2023 | ne plus poser |
| FAQPage | résultat enrichi supprimé | 7 mai 2026 | laisser en place, ne plus investir |
| Course info | documentation retirée | septembre 2025 | ne plus poser |
| Estimated salary | documentation retirée | septembre 2025 | ne plus poser |
| Learning video | documentation retirée | septembre 2025 | ne plus poser |
| Special announcement | documentation retirée | septembre 2025 | ne plus poser |
| Vehicle listing | documentation retirée | septembre 2025 | ne plus poser |
| Practice problem | déprécié, support retiré en janvier 2026 | novembre 2025 | ne plus poser |
| Dataset | utilisé par Dataset Search, pas par Google Search | novembre 2025 | poser seulement si c'est votre cible |
Un balisage FAQ déjà en place ne pénalise rien. Il ne sert simplement plus à Google, et il continuera d'être lu par d'autres systèmes.
Le point utile n'est pas cette liste, qui aura vieilli elle aussi dans dix-huit mois. C'est la méthode.
Le journal des changements de Google Search Central date chaque retrait, ligne par ligne, avec la raison. Cinq minutes de lecture par trimestre suffisent à ne jamais implémenter un schéma mort.
Savoir où se trouve cette page sépare déjà un expert SEO technique d'un rédacteur qui recopie un tutoriel de 2021.
Utilisation des données structurées : quels types poser selon ce que vend votre site web
L'inventaire du web dit quelque chose de gênant sur l'utilisation des données structurées.
D'après le Web Almanac 2024 de HTTP Archive, le type le plus déployé est WebSite, sur 12,73 % des pages mobiles. Organization suit, à 7,16 %. Ce sont exactement ceux que les extensions SEO posent toutes seules à l'installation.
Product plafonne à 0,77 % des pages. Article à 0,18 %. Ce sont pourtant les deux seuls qui enrichissent vraiment la ligne affichée.
Le web balise beaucoup. Il balise surtout ce qui ne produit rien.
Le tri entre types de données structurées est simple. Un type ne vaut que s'il décrit ce que la page contient réellement, et s'il figure encore dans la galerie officielle des fonctionnalités supportées.
Pour une fiche produit de boutique en ligne, c'est Product. Les données structurées e-commerce se résument le plus souvent à ce seul type.
Les propriétés qui comptent sont le nom, l'image, le prix, la devise et la disponibilité. Les avis viennent après, et seulement s'ils sont réels.
Pour un article de blog, c'est Article. Titre, image, auteur, date de publication.
Pour une entreprise locale, c'est LocalBusiness. Adresse, horaires, téléphone, zone desservie.
Une dernière consigne de Google va à l'encontre de ce que font les plugins. Mieux vaut peu de propriétés recommandées, complètes et exactes, que toutes les propriétés remplies à moitié. Une extension qui balise tout par défaut produit souvent l'inverse.
Ajouter des données structurées : ce qui change selon votre stack
Trois situations, trois réponses. Le balisage des données structurées ne se pose pas de la même façon sur un WordPress et sur une application maison.
Sur un CMS avec extension SEO. Le balisage arrive tout seul. Le travail consiste à retirer ce qui ne sert plus, et à corriger ce que le thème pose en double. Un site qui déclare deux fois Organization avec des valeurs différentes envoie un signal contradictoire.
Sur un site sur mesure. Un bloc JSON-LD écrit dans le template, versionné avec le reste du code, coûte moins cher à maintenir qu'une extension de plus. Il se relit en revue de code, il se teste, il se déploie avec le reste.
Sur une application rendue côté client. L'injection dynamique fonctionne, Google le documente. Encore faut-il vérifier que le script survit au rendu et qu'il n'attend pas une interaction pour s'exécuter.
Deux règles font tomber la moitié des implémentations, quelle que soit la stack.
La première : ne jamais baliser une information absente de la page visible. Si le JSON-LD annonce quatre étoiles, quatre étoiles doivent être lisibles par l'utilisateur. Google traite l'écart comme une tentative de tromperie, et c'est ce qui déclenche les sanctions manuelles.
La seconde : ne jamais créer de page vide pour héberger du balisage.
Un détail contre-intuitif pour finir. Sur des pages dupliquées, Google recommande de poser le même balisage partout, et pas seulement sur la version canonique.
Tester le balisage avant de déployer, mesurer l'affichage après
Deux outils portent des noms proches et ne répondent pas à la même question. La confusion coûte des heures.
Le Rich Results Test de Google, ou test des résultats enrichis, mesure l'éligibilité aux fonctionnalités de la recherche de Google. Le validateur de schema.org teste la conformité au vocabulaire.
Un balisage parfaitement vert chez schema.org peut être inéligible chez Google. C'est même le cas normal dès qu'on utilise un type que Google n'exploite pas.
Le premier répond à « est-ce que ça va s'afficher ». Le second à « est-ce que c'est du schema.org valide ». Vous voulez le premier.
Après le déploiement, le terrain change. Les rapports d'amélioration de la Search Console remontent les erreurs de gabarit, celles qui n'apparaissent jamais quand on teste une URL à la main. Un champ vide sur trois mille produits ne se voit que là.
C'est le genre de défaut qu'on remonte dans un audit technique : invisible page par page, évident dans un rapport agrégé.
Pour savoir si l'effort a payé, Google décrit un protocole simple et honnête. Prendre des pages stables, qui ont plusieurs mois d'historique.
Ajouter le balisage. Vérifier qu'il est bien vu via l'inspection d'URL. Puis comparer les performances sur plusieurs mois, filtre par filtre.
C'est plus lent qu'un dashboard. C'est la seule méthode qui donne une réponse sur votre site plutôt que sur celui d'un autre.
Ce que les données structurées en SEO rapportent vraiment, et ce qu'elles ne rapportent pas
Google publie quelques ordres de grandeur dans sa propre documentation.
Rotten Tomatoes a mesuré un taux de clic supérieur de 25 % sur 100 000 pages balisées, comparées à ses pages sans balisage. Nestlé annonce 82 % de clics en plus sur les pages qui s'affichent en résultat enrichi. Food Network parle de 35 % de visites supplémentaires après avoir converti 80 % de son catalogue.
Ces chiffres sont déclarés par les sites eux-mêmes et repris par Google. Ce sont des ordres de grandeur d'éditeurs, pas une promesse de résultat. Ils indiquent qu'enrichir un affichage se voit dans les clics, pas de combien ça se verra chez vous.
Vient maintenant la moitié que les articles commerciaux n'écrivent pas.
Le balisage ne fait pas monter une page. Il change ce qu'elle occupe une fois qu'elle est là.
Google ne garantit pas l'affichage, même sur un balisage valide. Sa formulation est nette : poser des données structurées rend une fonctionnalité possible, ça ne la déclenche pas. L'algorithme décide selon l'historique de recherche, la localisation et le type d'appareil.
Et le point qui devrait clore le débat GEO. Depuis mai 2026, Google publie un guide dédié à l'optimisation pour ses fonctionnalités IA génératives.
Elle dit qu'aucune donnée structurée schema.org particulière n'est nécessaire pour apparaître dans AI Overviews ou AI Mode. Le même guide précise que les fichiers llms.txt n'ont aucun effet, ni positif ni négatif, sur la visibilité : Google Search ne les utilise pas.
Le discours qui vend le balisage comme un levier d'intelligence artificielle n'a pas de source chez l'éditeur concerné. Grâce aux données structurées, votre fiche produit gagne des étoiles et un prix dans la recherche. C'est déjà beaucoup, et c'est ce qui se mesure.
Faire auditer son balisage par quelqu'un qui lit la documentation à la source
Un audit de balisage n'a rien de mystérieux. Inventaire des types réellement posés sur chaque gabarit, confrontation à la galerie officielle.
Puis un passage au Rich Results Test, et la lecture des rapports Search Console sur trois mois.
Ce qui prend du temps, ce n'est pas de connaître schema.org. C'est de savoir écrire du JSON-LD dans un template sans casser le rendu.
Et de lire un changelog pour trier ce qui produit encore un affichage de ce qui n'en produit plus.
Huit ans de développement avant le SEO aident surtout sur le premier point. La lecture du changelog, elle, ne demande qu'une habitude.
Audit de balisage livré sous cinq jours ouvrés : inventaire par gabarit, liste des types morts à retirer, JSON-LD corrigé prêt à intégrer. Sans engagement de suite.
Questions fréquentes
Les données structurées améliorent-elles le classement Google ?
Non. Google le formule sans ambiguïté : une sanction manuelle sur le balisage retire l'éligibilité aux résultats enrichis. Le classement de la page dans la recherche web, lui, ne bouge pas.
L'effet se joue sur le taux de clic, pas sur la position. Une page en cinquième position qui affiche un prix et des étoiles récupère des clics qui seraient allés plus haut. Elle ne monte pas pour autant.
Combien de temps avant d'apparaître dans les résultats enrichis ?
Le temps que Google recrawle la page, puis le temps qu'il décide de l'afficher. Le premier délai va de quelques jours à quelques semaines selon la fréquence de passage sur votre site.
Le second n'a pas de durée. Google ne garantit pas l'affichage, même sur un balisage valide. L'inspection d'URL de la Search Console confirme au moins qu'il a bien vu le balisage, ce qui sépare le problème technique du problème d'arbitrage.
Peut-on poser plusieurs schémas sur une même page ?
Oui, c'est même la situation normale. Une fiche produit porte couramment Product, BreadcrumbList et Organization en même temps.
La règle est que chaque type décrive quelque chose de réellement présent sur la page. Le vrai risque n'est pas le cumul, c'est la contradiction : deux blocs qui déclarent des valeurs différentes pour la même chose.
Faut-il retirer le balisage FAQ déjà en place ?
Rien ne l'impose. Le balisage FAQ ne déclenche plus d'affichage dans Google depuis mai 2026, mais il reste du schema.org valide et d'autres systèmes continuent de le lire.
Ce qu'il faut arrêter, c'est d'en poser de nouveaux en espérant un résultat enrichi. Le temps passé se place mieux sur un type encore supporté.