Données structurées : à quoi les moteurs de recherche s'en servent vraiment

Cela achète une éligibilité, et une éligibilité n'est pas une promesse

Le modèle mental qui cause le plus de déceptions est celui où le balisage serait un levier : ajoute du schema, obtiens un gain. Ce n'est pas cela. Les données structurées sont une couche de traduction. Ta page dit, en prose destinée à une personne, que cet article a été écrit par Camille Laurent le 18 août et mis à jour en septembre. Le balisage dit la même chose sous une forme qu'un analyseur peut lire sans deviner. Rien de nouveau n'entre dans la page ; la machine cesse simplement de devoir inférer.

Ce que cette traduction achète est une chose précise et bornée : l'éligibilité à un résultat enrichi. Les consignes de Google le mettent dans un encadré — il ne garantit pas que tes données structurées apparaîtront dans les résultats, même si ta page est correctement balisée. Que la fonctionnalité soit dessinée dépend de la requête, de l'appareil, de la mise en page de cette page de résultats précise et du fait que Google fasse assez confiance à ton site pour l'afficher. Un balisage correct te fait passer d'inéligible à éligible. Rien en lui ne te fait monter d'une position.

La confirmation la plus nette que balisage et classement sont deux systèmes distincts vient du côté des sanctions. Google décrit une action manuelle sur les données structurées comme quelque chose qui fait perdre à une page son éligibilité à l'affichage en résultat enrichi, et précise que cela n'affecte pas son classement en recherche web. Deux molettes indépendantes. Si le balisage pouvait pousser les classements vers le haut, en abuser les pousserait vers le bas — et la sanction documentée ne fait rien de tel.

JSON-LD a gagné, et la raison est la maintenance

Il existe trois syntaxes pour mettre schema.org dans une page. Microdata et RDFa reposent sur des attributs : on saupoudre itemscope, itemprop et typeof sur les éléments HTML qui contiennent déjà les valeurs, si bien que le balisage vit à l'intérieur du balisage. JSON-LD est un bloc autonome, une balise script de type application/ld+json contenant un objet JSON ordinaire, généralement placé dans le head ou en fin de body. Les trois sont analysés. Google recommande JSON-LD pour les données structurées si la configuration du site le permet, et le qualifie de solution la plus simple à implémenter et maintenir à grande échelle.

La raison n'est pas l'élégance, c'est le couplage. Le balisage par attributs est soudé au DOM : change le gabarit, déplace le prix dans un autre composant, laisse un designer remplacer un span par un div, et l'itemprop suit ou disparaît sans bruit. JSON-LD est totalement découplé de la présentation, ce qui veut dire qu'il survit aux refontes, peut être assemblé côté serveur à partir des mêmes données qui rendent la page, et se relit dans une pull request comme un seul objet lisible plutôt que comme quinze attributs éparpillés. Ce découplage est aussi son danger, et c'est précisément l'objet de la section d'après.

Quels types produisent encore quelque chose de visible

C'est là que la plupart des conseils publiés se sont gâtés : vérifie la date de tout ce que tu lis, y compris ceci. Google maintient une galerie des types de données structurées qu'il prend en charge, et cette galerie est la seule autorité digne de confiance sur la question. Aujourd'hui elle liste Article, Breadcrumb, Product, Event, Recipe, Video, Job posting, Local business, Organization, Review snippet, Q&A, Dataset, Software app, Vacation rental, Discussion forum, Profile page et quelques autres. Deux noms qui figuraient sur toutes les check-lists SEO n'y sont pas.

HowTo a disparu. Google a retiré les résultats enrichis HowTo au cours de 2023, du mobile d'abord puis du bureau, et a supprimé la documentation. FAQPage a duré plus longtemps mais a disparu aussi : à partir d'août 2023 il a été restreint aux sites gouvernementaux et de santé reconnus et faisant autorité, et le 7 mai 2026 il a cessé d'apparaître tout court. La documentation FAQPage a été supprimée le 15 juin 2026, et les rapports associés — le filtre d'apparence dans les résultats, le rapport de résultats enrichis, la prise en charge dans le test de résultats enrichis — ont suivi. Si une check-list te dit d'ajouter du schema FAQ pour gagner de la place dans le résultat, cette check-list a au moins un an de retard, probablement trois.

Cela ne rend pas le balisage inutile, et ne veut pas dire qu'il faut l'arracher. La position de Google sur les fonctionnalités retirées est qu'il n'est pas nécessaire de les supprimer, car d'autres moteurs et services peuvent encore les utiliser. Schema.org est un vocabulaire partagé, pas un produit Google : assistants, agrégateurs, autres moteurs et un nombre croissant de chaînes de récupération de modèles de langage analysent le même JSON. La formulation honnête est que FAQPage et HowTo sont passés d'un bénéfice visible et mesurable à un bénéfice spéculatif — ce qui change réellement le temps d'ingénierie qu'ils méritent.

Obligatoire contre recommandé, pour les trois qui rapportent encore

Article est le cas surprenant : il n'a aucune propriété obligatoire. Google recommande d'ajouter les propriétés qui s'appliquent à ton contenu, et cite author, datePublished, dateModified, headline et image comme recommandées. Ce n'est pas une autorisation de les sauter. Une propriété recommandée est une propriété dont l'absence n'invalide pas l'objet mais réduit ce qu'un consommateur peut en faire — un Article sans author est un Article qui ne peut alimenter aucune signature en aval. Fournis celles que tu peux fournir exactement, et le conseil de Google est de préférer moins de propriétés recommandées, complètes et exactes, à toutes les propriétés possibles mal renseignées.

BreadcrumbList est le plus strict des trois et le moins cher à réussir. Il exige itemListElement, un tableau ordonné d'objets ListItem, et chaque ListItem exige position et name. La propriété item — l'URL vers laquelle pointe le fil — est obligatoire sur chaque entrée sauf la dernière, où Google se rabat sur l'URL de la page courante. La liste doit contenir au moins deux ListItem pour être affichée ; un fil d'Ariane à un élément n'est pas un fil. C'est le type au meilleur rapport entre effet visible et effort d'implémentation, parce qu'il remplace une URL laide par un chemin lisible, et parce que sur un site à structure d'URL disciplinée le fil se génère depuis le chemin lui-même.

Product se situe au milieu. Pour un extrait produit, les propriétés obligatoires sont name plus au moins l'un de review, aggregateRating ou offers — un seul des trois suffit. En pratique c'est offers qui gagne sa place, parce qu'un prix et un état de disponibilité dans le résultat répondent aux deux questions qu'un acheteur se pose avant de cliquer. Note l'avertissement que le test de résultats enrichis peut lever si tu fournis offers sans aucune note : c'est un avertissement, pas une erreur, et inventer une note pour le faire taire est exactement le comportement dont parle la section suivante.

La règle qui décide de tout : baliser ce qui est visible

Les consignes de Google sur les données structurées contiennent une instruction qui cause plus d'actions manuelles que toutes les erreurs techniques réunies : ne balise pas de contenu qui n'est pas visible par les lecteurs de la page. Cela paraît évident jusqu'à ce qu'on remarque à quel point JSON-LD facilite l'infraction. Le bloc vit à l'écart du HTML, il est généré par un gabarit, il n'est jamais rendu — donc personne dans l'équipe ne le regarde jamais côte à côte avec la page. C'est précisément pour cela qu'il dérive.

Les modes de défaillance sont banals, pas malveillants. Un gabarit produit émet aggregateRating depuis un champ de catalogue alors que la page n'affiche aucun avis parce qu'aucun n'a encore été écrit. Une page tarifaire rend un prix côté serveur après une conversion de devise, mais le JSON-LD a été construit depuis le prix de base et contredit désormais ce que lit le visiteur. Un bloc article porte un dateModified que le CMS incrémente à chaque republication alors que la page affiche la date d'origine. Chacun de ces cas est un balisage décrivant quelque chose que le lecteur ne peut pas vérifier, et chacun est la même infraction que falsifier délibérément cinq étoiles.

Le correctif d'ingénierie tient en un principe : ne construis jamais le JSON-LD depuis une seconde source de vérité. Assemble-le à partir exactement des mêmes objets qui rendent la page visible, dans la même requête, pour qu'une valeur ne puisse pas apparaître dans l'un sans l'autre. Si le prix affiché vient d'une chaîne formatée, dérive le prix du balisage du nombre derrière cette chaîne, pas d'une requête séparée. Ajoute ensuite un test par gabarit qui vérifie que chaque valeur balisée apparaît quelque part dans le HTML rendu. Ce test attrape la dérive de gabarit le jour où elle se produit, plutôt que dans un message de la Search Console trois mois plus tard.

Tester : trois outils, trois questions différentes

Le validateur schema.org répond à la question du vocabulaire : est-ce du schema.org valide, les types existent-ils, les propriétés sont-elles bien orthographiées, les objets imbriqués correspondent-ils aux plages attendues. Il ne sait rien de Google. Le test de résultats enrichis répond à la question d'éligibilité pour Google spécifiquement : avec ce balisage, la page est-elle éligible à une fonctionnalité que Google prend actuellement en charge, et sinon quelle propriété obligatoire manque. Les rapports de résultats enrichis de la Search Console répondent à la troisième question, la plus importante : que se passe-t-il sur le site en production, à l'échelle, sur toutes les URL, une fois le gabarit livré.

Utilise-les dans cet ordre et arrête-toi au troisième. Le conseil de Google est de tester pendant le développement puis de surveiller la validité après déploiement, parce que les problèmes apparaissent après la mise en ligne, par des soucis de gabarit et de service qu'aucune vérification préalable ne peut voir. Une page qui a passé le test de résultats enrichis sur le portable d'un développeur peut échouer en production parce qu'une couche de cache retire la balise script, parce qu'une bannière de consentement retarde le rendu au-delà du point où le robot a abandonné, ou parce qu'une catégorie sur quarante contient un null dans le champ qui alimente name.

Questions fréquentes

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

Non. Le balisage rend une page éligible aux résultats enrichis ; il ne la fait ni monter ni descendre dans les résultats web ordinaires. La preuve la plus nette est la sanction : Google décrit une action manuelle sur les données structurées comme coûtant à la page son éligibilité à l'affichage enrichi, en précisant que cela n'affecte pas son classement en recherche web. Deux systèmes distincts. Tout bénéfice indirect vient d'un résultat plus informatif qui attire plus de clics, pas d'un balisage qui serait noté.

Faut-il supprimer le schema FAQ et HowTo maintenant qu'ils ne produisent plus rien ?

Non, et Google le dit explicitement pour les fonctionnalités retirées : il n'est pas nécessaire de les supprimer, car d'autres moteurs et services peuvent encore les utiliser. Schema.org est un vocabulaire partagé que Google ne possède pas. Ce qui doit changer, c'est ton budget, pas ton HTML — cesse de construire du nouveau balisage FAQ en attendant un gain visible dans Google, et cesse de rapporter sur une fonctionnalité dont le rapport Search Console n'existe plus. Si le balisage est déjà généré par un gabarit dont la maintenance ne coûte rien, le laisser est la décision la moins chère.

Mon balisage est valide et le test de résultats enrichis passe, mais aucun résultat enrichi n'apparaît. Pourquoi ?

Parce que réussir le test prouve l'éligibilité, et l'éligibilité n'est pas l'affichage. Google indique qu'il ne garantit pas l'apparition des données structurées même sur une page correctement balisée. La décision dépend de la requête, de l'appareil, de la mise en page de cette page de résultats précise et de la confiance de Google envers le site. Il n'y a pas de levier à actionner. La réponse productive est de vérifier que la page est bien indexée, que le rapport Search Console montre l'élément comme valide en production et pas seulement dans l'outil de test, puis d'attendre — l'affichage commence souvent des semaines après le premier passage du robot.

Puis-je mettre le JSON-LD dans le head, ou doit-il être dans le body ?

Les deux fonctionnent. Google analyse la balise script où qu'elle apparaisse dans le document, et il n'y a aucune différence de classement ou d'éligibilité entre les deux positions. Ce qui compte bien davantage, c'est que la balise parvienne au robot. Si le bloc est injecté par du JavaScript côté client, il dépend de l'achèvement du rendu, ce qui introduit un mode de défaillance que le balisage rendu côté serveur n'a pas. Émets-le côté serveur si ta pile le permet, et s'il doit être côté client, vérifie avec l'outil d'inspection d'URL que le HTML rendu vu par Google le contient bien.

Qu'est-ce qui vaut exactement à un site une action manuelle sur les données structurées ?

Un balisage qui décrit quelque chose que le lecteur ne peut pas voir. Les consignes de Google disent clairement de ne pas baliser de contenu non visible par les lecteurs de la page, et le contenu balisé masqué est cité comme raison de non-affichage. En pratique, les fautes sont : des notes pour des produits sans avis sur la page, des prix qui ne correspondent pas au prix affiché, des types qui ne correspondent pas à la vocation réelle de la page, et des dates inventées par le CMS. La conséquence est la perte d'éligibilité aux résultats enrichis, pas une chute de classement — mais l'éligibilité est toute la raison d'avoir ajouté le balisage.

Un générateur de balisage schema produit-il quelque chose que je peux livrer tel quel ?

Il produit un squelette correct, ce qui est vraiment la moitié fastidieuse du travail — le bon type, les propriétés obligatoires présentes, l'imbrication valide, le JSON bien formé. Ce qu'il ne peut pas faire, c'est connaître ta page. Deux choses restent vôtres : vérifier que chaque valeur que tu colles est une valeur visible sur la page rendue, et brancher le bloc sur tes données pour qu'il reste vrai après le prochain changement de contenu. Un générateur est l'outil adapté pour une page ponctuelle ou un premier gabarit ; c'est le mauvais outil pour un catalogue de quarante mille produits, qui exige une génération depuis les mêmes objets que ceux qui rendent la page.