Ce n’est pas parce que votre balisage passe les tests de Google qu’un moteur d’IA pourra exploiter vos données structurées. Les parcours d’analyse ne sont pas les mêmes. Rich Results Test vérifie uniquement l’éligibilité à quelques types de résultats enrichis pris en charge par Google. Schema.org Validator contrôle seulement la conformité de la syntaxe avec le vocabulaire Schema.org. Aucun des deux ne vous indique ce que les robots de ChatGPT, de Perplexity ou de Google AI Overviews lisent réellement sur votre page. De nombreuses pages obtiennent tous les voyants au vert lors de la validation, mais restent totalement invisibles dans les réponses des IA. C’est précisément là que se situe le problème.
Pourquoi « validation réussie » ne signifie pas « lisible par les IA »
Les outils de validation contrôlent la conformité, pas la lisibilité. Schema.org Validator compare votre JSON-LD au vocabulaire Schema.org pour vérifier l’orthographe des types et des propriétés ainsi que la validité de leur imbrication. Rich Results Test simule le rendu de la page par Googlebot afin de déterminer si elle peut déclencher un résultat enrichi donné. À l’issue de ces deux contrôles, vous savez uniquement si la syntaxe est correcte et si Google est susceptible d’afficher un résultat enrichi. La plupart des robots d’IA, en revanche, récupèrent directement le HTML source renvoyé par le serveur, sans exécuter JavaScript, et ne s’intéressent pas à l’éligibilité aux résultats enrichis. La véritable question est donc de savoir si le JSON-LD figure dans le HTML source et si les entités sont correctement reliées entre elles.
Deux outils indispensables, avec des angles morts différents
Pour comprendre ce qui peut échapper à chaque outil, il faut d’abord bien distinguer leur rôle.
- Rich Results Test (search.google.com/test/rich-results) : l’outil utilise Googlebot pour effectuer le rendu réel de la page, exécuter JavaScript et dresser la liste des types de résultats enrichis détectés, avec leurs erreurs et avertissements. Son angle mort : il ne couvre qu’une trentaine de types pris en charge par Google. Si vous balisez des types comme Organization ou Person, qui ne déclenchent pas de résultat enrichi, il peut afficher « Élément non détecté » sans que votre balisage soit pour autant invalide.
- Schema.org Validator (validator.schema.org) : que Google prenne ou non le type en charge, l’outil affiche l’arborescence complète de toutes les entités. Il est donc particulièrement adapté au contrôle de la syntaxe et du vocabulaire. Son angle mort : par défaut, il n’exécute pas JavaScript pour vous. Lorsque vous lui fournissez le code source ou une URL, il analyse souvent une version non rendue. Il ne se prononce pas non plus sur l’éligibilité aux résultats enrichis et se montre excessivement tolérant face à certaines erreurs sémantiques.
La conclusion est simple : utilisez les deux outils, en sachant précisément ce que vous contrôlez à chaque étape. Schema.org Validator sert à vérifier la syntaxe et la structure des entités ; Rich Results Test, l’éligibilité aux résultats enrichis de Google et le résultat du rendu. Aucun ne répond à la question « Un robot qui n’exécute pas JavaScript peut-il voir ces données ? ». Pour le savoir, il faut passer à l’étape suivante : l’examen du code source.
Un processus reproductible de validation du balisage Schema
Adoptez une séquence de contrôle fixe et appliquez la même liste à chaque page et à chaque révision. Vous éviterez ainsi de valider au jugé et de laisser passer des failles différentes à chaque fois.
- Collez le HTML « rendu » dans Schema.org Validator. Vérifiez la syntaxe et le vocabulaire, déployez l’arborescence complète des entités, puis contrôlez chaque type et chaque propriété requise.
- Saisissez l’URL officielle dans Rich Results Test. Vérifiez que Google récupère la version rendue, que le type de résultat enrichi visé est reconnu et qu’aucune erreur rouge n’apparaît.
- Récupérez avec curl ou view-source le HTML source, « sans exécuter JavaScript ». Recherchez application/ld+json et assurez-vous que le JSON-LD figure bien dans le contenu renvoyé par le serveur. Cette étape reproduit le comportement de la plupart des robots d’IA.
- Contrôlez les références croisées entre @id et @type pour Organization, WebSite, Article et Person. Vérifiez qu’un @id cohérent relie l’ensemble des entités afin que le moteur puisse déterminer à quelle organisation appartient l’auteur et à quel site web se rattache l’article.
- Comparez une à une les valeurs du balisage avec le contenu visible de la page. Le prix, le titre, la note et la date doivent correspondre. En cas d’écart, Google les ignorera et les IA leur accorderont moins de confiance.
- Enregistrez un instantané de référence, puis reprenez toute la liste après chaque modification et analysez les écarts comme des régressions.
Les erreurs qui rendent réellement les données illisibles pour les IA
Même avec une syntaxe valide, toute une catégorie d’erreurs peut produire le même constat : « L’outil ne signale rien, mais l’IA ne lit pas les données. » Voici les problèmes que nous rencontrons le plus souvent lors des audits réalisés pour nos clients :
- Le JSON-LD est injecté côté navigateur par le framework front-end ou le gestionnaire de balises. Il n’en reste pas une seule ligne dans le HTML source renvoyé par le serveur : les robots qui n’exécutent pas JavaScript ne peuvent donc pas le voir.
- Les @id sont absents ou incohérents. Les entités ne peuvent pas être reliées et le moteur ne parvient pas à rattacher les auteurs, les organisations et les articles au même nœud du graphe de connaissances.
- Le type est correct, mais les valeurs sont placées dans les mauvaises propriétés : la devise est renseignée dans price, la description complète dans name, ou priceCurrency manque dans offers.
- La syntaxe est valide, mais le sens reste incomplet : Product ne contient aucun offers, Article n’a ni author ni publisher, ou la réponse de FAQPage est une chaîne vide.
- Plusieurs blocs JSON-LD contradictoires figurent sur la même page, par exemple un Organization provenant du modèle de la page d’accueil et un autre ajouté dans la page elle-même. Le moteur ne sait plus lequel retenir.
- La date n’est pas au format ISO 8601 ou l’image utilise un chemin relatif plutôt qu’une URL absolue. Un validateur tolérant peut accepter ces valeurs, mais elles risquent fort d’être écartées lors de l’extraction.
Ne vous limitez pas aux outils : examinez l’écart entre le « DOM rendu » et le « code source »
Pour valider correctement une page, il faut examiner ses deux versions en parallèle. Le panneau Elements de DevTools affiche le DOM rendu par le navigateur, qui correspond approximativement à ce que voit Googlebot. view-source ou curl montrent le HTML source initialement renvoyé par le serveur, c’est-à-dire ce que voient la plupart des robots d’IA. Si vos données structurées n’existent que dans la première version, l’écart avec la seconde correspond exactement à ce que l’IA ne peut pas lire. Les outils de validation vous aident à examiner la première version ; la seconde exige un contrôle de votre part.
La validation du balisage Schema n’est pas une formalité à accomplir une fois au moment de la mise en production. C’est un contrôle à reprendre après chaque modification : une mise à niveau du CMS ou un ajustement du modèle peut désorganiser silencieusement toute l’arborescence des entités.— Tenten GEO Technical Audit Notes
Faire de la validation un passage obligé avant la mise en production
La méthode la plus efficace consiste à intégrer cette liste au processus de mise en production, plutôt que de compter sur sa mémoire pour effectuer des contrôles ponctuels. Vous pouvez ajouter à la CI un script qui récupère le HTML source de l’URL officielle, en extrait le JSON-LD, contrôle les propriétés requises et les références @id, puis bloque le déploiement si un élément manque. Sans CI, inscrivez au minimum ces six étapes dans une liste de contrôle avant mise en production et validez chaque point après toute modification. La valeur des données structurées tient à la fiabilité avec laquelle les machines peuvent les extraire. Or cette fiabilité vient du processus, pas de la réussite ponctuelle d’un contrôle manuel. Pour savoir à quoi ressemble votre page aux yeux d’un robot qui n’exécute pas JavaScript et quels éléments du balisage Schema restent totalement illisibles pour les IA, rendez-vous sur /contact afin de prendre rendez-vous pour un diagnostic GEO de 30 minutes. Nous appliquerons ce processus à votre page réelle.
