Vous avez ajouté des données structurées, mais comment savoir si elles marchent ? Ce guide donne la méthode pour les tester, avec les deux seuls outils gratuits dont vous avez besoin, la façon de lire le résultat, et quoi faire quand un test passe mais que le résultat enrichi ne s'affiche pas.
Si vous débutez sur le sujet, commencez par notre guide données structurées qui explique ce qu'elles sont et à quoi elles servent. Ici, on se concentre sur le test.
Comment tester ses données structurées ?
Deux outils gratuits suffisent, et ils sont complémentaires : le Test des résultats enrichis de Google vérifie l'éligibilité aux fonctionnalités Google, et le validateur Schema.org vérifie la conformité au vocabulaire. Pour un suivi sur l'ensemble d'un site, la Search Console prend le relais.
La règle : validez toujours dans les deux outils. Les exigences de Google et celles de Schema.org diffèrent, un balisage peut passer l'un et échouer l'autre.
Les 3 outils pour tester (et lequel utiliser quand)
| Outil | Ce qu'il vérifie | Quand l'utiliser |
|---|---|---|
| Test des résultats enrichis (Google) | L'éligibilité aux résultats enrichis Google | Avant et après mise en ligne, page par page |
| Validateur Schema.org | La conformité au vocabulaire Schema.org (tous moteurs) | Pour traquer une erreur de structure ou de syntaxe |
| Search Console (rapport État) | L'état des données structurées sur les pages réelles indexées | Pour suivre tout le site dans le temps |
Le premier outil vit à l'adresse search.google.com/test/rich-results, le second à validator.schema.org. Le troisième est un rapport de votre Search Console, une fois le site vérifié.
Beaucoup d'articles vous vendront une liste d'outils payants. Dans les faits, ces trois sources officielles et gratuites couvrent tout le besoin : éligibilité Google, conformité au vocabulaire, et suivi à l'échelle du site. Un outil payant se justifie surtout pour auditer des centaines de pages en une passe, pas pour un test ponctuel.
Tester une page avec le Test des résultats enrichis
C'est l'outil à dégainer en premier. Il dit, pour une page donnée, quels résultats enrichis Google peut générer.
- Ouvrir l'outil sur search.google.com/test/rich-results.
- Coller l'URL de la page en ligne, ou coller directement le code pour tester avant publication.
- Lancer le test et attendre l'analyse (Google charge et rend la page).
- Lire le verdict : les types détectés et, pour chacun, s'ils sont valides, avec avertissements, ou en erreur.
- Prévisualiser le rendu potentiel du résultat enrichi quand l'outil le propose.
Point important en 2026 : cet outil n'affiche que les types que Google transforme encore en résultat enrichi. Un balisage FAQ ou HowTo ne montrera pas de résultat, car ces affichages ont été retirés. Ce n'est pas une erreur de votre part, c'est la fin de ces fonctionnalités.
Tester avant la mise en ligne
Le meilleur moment pour tester, c'est avant de publier. Le Test des résultats enrichis accepte deux entrées : l'URL d'une page en ligne, ou un extrait de code collé directement.
Collez votre bloc JSON-LD dans l'onglet Code de l'outil pour valider le balisage d'une page pas encore publiée, ou d'un template en cours de développement. Vous corrigez les erreurs avant qu'elles n'atteignent le site, plutôt que de les découvrir en production. Sur un projet bien mené, cette vérification fait partie de la recette avant chaque livraison.
Vérifier la conformité avec le validateur Schema.org
Le validateur Schema.org contrôle une chose que l'outil de Google ne fait pas : la conformité complète au vocabulaire, pour tous les moteurs et systèmes qui lisent le balisage, pas seulement Google.
Issu du projet Schema.org (fondé par Google, Microsoft, Yahoo et Yandex), il signale surtout les propriétés mal orthographiées et les types inexistants. Utilisez-le quand le Test des résultats enrichis reste muet ou incohérent : souvent, le problème est une erreur de syntaxe que seul le validateur pointe.
Suivre ses données structurées dans la Search Console
Les deux premiers outils testent une page à la fois. La Search Console suit l'ensemble du site, sur les pages réellement indexées, et dans la durée.
Dans la section État (ou Améliorations), Google liste les types de données structurées détectés sur votre site, avec le nombre d'éléments valides, en avertissement, ou en erreur. C'est là que vous repérez une erreur qui touche des centaines de pages d'un coup, et que vous confirmez la correction une fois déployée.
Le rapport propose aussi un bouton pour demander une nouvelle validation après correction : Google recrawle alors les pages concernées et met à jour le décompte. C'est le seul des trois outils qui reflète l'état réel de votre site indexé, et pas une simulation sur une page isolée.
Lire le résultat : erreurs et avertissements
Les outils classent les problèmes en deux niveaux. Les confondre fait perdre du temps.
| Niveau | Ce que ça veut dire | Action |
|---|---|---|
| Erreur | Une propriété obligatoire manque ou est invalide. Le résultat enrichi ne s'affichera pas. | À corriger en priorité. |
| Avertissement | Une propriété recommandée manque. Le résultat reste éligible, mais moins complet. | À corriger si possible, non bloquant. |
| Valide | Le balisage est correct et éligible. | Rien, sinon surveiller dans le temps. |
Traduisez toujours une erreur en action concrète : ajouter la propriété manquante, corriger un type, aligner le balisage sur le contenu visible.
Un exemple concret. Vous testez une page produit et le Test des résultats enrichis affiche une erreur du type manque le champ offers, ou price sans priceCurrency. Le message vous dit exactement quelle propriété obligatoire ajouter : ici, une offre avec un prix et sa devise. Vous corrigez le balisage, vous relancez le test, l'erreur disparaît. C'est toujours ce va-et-vient : lire le message, corriger la propriété nommée, retester.
Les erreurs de balisage les plus fréquentes
- Propriété obligatoire manquante : un Product sans offre ni prix, un Article sans auteur. C'est la cause numéro un d'un résultat qui ne s'affiche pas.
- Erreur de syntaxe JSON : une virgule oubliée, une accolade non fermée, un guillemet non échappé. Le bloc entier devient illisible. C'est le validateur Schema.org qui la pointe le plus clairement.
- Balisage qui ne correspond pas au contenu visible : décrire un avis ou un prix absent de la page. Google peut le pénaliser.
- Mauvais type ou type trop générique : utiliser Article pour une recette au lieu de Recipe, ou un type inexistant mal orthographié.
- Deux formats en conflit : du JSON-LD et des microdonnées qui décrivent la même chose différemment sur une même page. Gardez un seul format, le JSON-LD.
- Type retiré : viser un résultat enrichi FAQ ou HowTo qui n'existe plus. Le test ne montrera rien.
- Valeurs mal formées : une date qui ne respecte pas le format ISO 8601, un prix sans devise.
La checklist avant mise en ligne
Avant de publier une page balisée, passez ces six points en revue. Ils évitent la quasi-totalité des erreurs.
- Le type correspond au sujet réel de la page (Product pour un produit, Recipe pour une recette).
- Le balisage est bien présent dans le HTML final, pas seulement dans l'éditeur.
- Le Test des résultats enrichis ne renvoie aucune erreur bloquante.
- Le validateur Schema.org ne signale ni type inexistant ni propriété inconnue.
- Chaque valeur balisée est réellement visible sur la page.
- Aucun doublon : un seul format, une seule description par entité.
Le test passe mais le résultat enrichi ne s'affiche pas : pourquoi ?
C'est la frustration classique, et elle a des causes précises. Un test valide rend une page éligible, il ne garantit pas l'affichage. Google le dit clairement : il n'affiche jamais un résultat enrichi de façon garantie, même avec un balisage correct.
Les raisons les plus courantes :
- Le type a été retiré (FAQ, HowTo) : plus aucun affichage possible, quel que soit le balisage.
- La page n'est pas encore indexée : sans indexation, pas de résultat enrichi. Vérifiez l'indexation dans la Search Console.
- Google juge la page pas assez fiable ou pertinente pour la requête : l'affichage reste à sa discrétion.
- Le délai : après correction, il faut le temps que Google recrawle et réévalue la page.
Autrement dit, un test au vert est une condition nécessaire, pas suffisante. La suite se joue sur la qualité et l'indexation de la page, pas sur le balisage seul.
Intégrez le test à votre routine
Testez à chaque mise en ligne et à chaque refonte, puis surveillez la Search Console une fois par mois. Un balisage juste hier peut casser après une modification de template ou de contenu.
Sur un site sur mesure, ce contrôle fait partie du travail : le balisage est généré à partir des contenus et vérifié avant livraison. C'est aussi un point que couvre un bon audit SEO.
Envie d'un site dont les données structurées sont propres et testées dès le départ, pour le SEO et la visibilité IA ? Réservez un appel avec le fondateur.
