Comment tester les Rich Snippets (et corriger les erreurs de schéma)

TL;DR : Testez l’éligibilité aux rich results avec Rich Results Test de Google. Utilisez le mode URL pour la page publiée, corrigez chaque erreur et considérez les avertissements comme de simples améliorations optionnelles. Ensuite, suivez le rapport correspondant dans Google Search Console. Un test réussi signifie que la page est éligible à un rich result, pas qu’elle en recevra forcément un.

Le choix de l’outil compte. Dans sa documentation Search Central sur les données structurées, Google présente le Rich Results Test comme : « l’outil officiel de Google pour tester vos données structurées afin de voir quels rich results Google peuvent être générés par les données structurées présentes sur votre page ».

C’est là que je commence quand on me demande de tester l’éligibilité aux rich snippet. Pas via une extension de navigateur, le petit “tick” vert d’un plugin, ou l’ancien Structured Data Testing Tool, mentionné dans des tutoriels datés.

Petite correction de terminologie : Google appelle désormais ces éléments rich results. “Rich snippet” est l’expression plus ancienne que beaucoup continuent d’utiliser. Les deux termes décrivent des affichages enrichis dans la recherche : ils peuvent inclure des notes, des prix, des images, des fil d’Ariane, des dates d’événements, des détails de recettes et d’autres informations au-delà du titre et de la description standards.

Les données structurées ne sont pas le résultat de recherche lui-même. Ce sont une description lisible par machine de la page, généralement écrite en JSON-LD. Google peut aussi analyser le microdonnées (microdata) et RDFa, mais le JSON-LD est le plus souvent plus simple à générer, à inspecter et à maintenir sans “emmêler” le balisage dans du HTML visible.

Un balisage structuré valide crée une éligibilité. Google décide encore si un enrichissement s’affiche pour une page et une requête données. Cette distinction explique une grande partie des retours du type : “le test passe, mais je ne vois aucun rich snippet”.

Comment tester correctement un rich snippet

Le Rich Results Test propose des modes URL et Code. Ils se recoupent, mais ne prouvent pas la même chose.

1. Ouvrez le Rich Results Test de Google.
2. Sélectionnez URL pour une page publiée, ou Code pour du HTML ou du JSON-LD qui n’a pas encore été déployé.
3. Lancez le test et laissez Google récupérer, rendre (render) ou traiter l’entrée.
4. Ouvrez chaque type de rich result détecté au lieu de vous arrêter au résumé.
5. Inspectez pour chaque élément ses erreurs, avertissements et propriétés analysées.
6. Corrigez toutes les erreurs, puis relancez le test.
7. Déployez la modification, effacez les caches pertinents, puis testez à nouveau l’URL en production.
8. Après le nouveau crawl par Google des pages concernées, vérifiez le rapport Search Console correspondant et validez le correctif dans ce rapport.

Commencez par le mode URL pour les pages en production

Le mode URL répond à la question utile en production : Que peut Google récupérer depuis cette URL, à l’instant T ?

Votre JSON-LD peut être parfait dans un champ du CMS et absent de la page publiée. Une condition de template peut le désactiver, un cache peut servir l’ancienne version, une erreur JavaScript peut empêcher l’injection, ou le déploiement production peut omettre le composant au complet. L’éditeur est une preuve d’intention. L’URL en direct est une preuve du rendu.

Le mode URL rend aussi les pages : il peut donc détecter des données structurées injectées via JavaScript. Cela dit, je préfère un JSON-LD rendu côté serveur quand c’est possible, car cela supprime encore un point de défaillance (tous les projets n’ont pas besoin d’un composant mobile en plus).

Lors de notre migration de janvier 2026 de seojuice.io vers seojuice.com, des tests représentatifs d’URL vivantes faisaient partie de la checklist de release. Une migration peut conserver le template de schéma tout en modifiant les canonicals, les chemins de production, les caches et la sortie de page autour. Tester uniquement le snippet JSON-LD aurait ignoré la majorité du risque de migration.

Utilisez le mode Code avant publication

Le mode Code est utile quand vous construisez ou modifiez le balisage. Collez le HTML ou le JSON-LD concerné, lancez le test, puis réparez la structure avant de toucher à la production.

Collez un snippet brut comme celui-ci (balisage Article) et testez-le avant que la page ne sorte :

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "How to Test Rich Snippets",
  "author": { "@type": "Person", "name": "Vadim Kravcenko" },
  "datePublished": "2026-07-19"
}
</script>

Pour les problèmes tenaces, testez les deux. Le mode Code vous indique si le balisage proposé est acceptable. Le mode URL vous dit si cette version est bien arrivée sur la page. Ces résultats divergent souvent : ce n’est pas un “désagrément”, c’est un indice.

Si vous devez d’abord générer le JSON-LD, utilisez notre générateur de balisage Schema, puis passez sa sortie dans le test de Google. Un générateur réduit les erreurs de crochets, d’imbrication et de propriétés. Il ne peut pas vérifier que votre CMS a fourni les bonnes données, ni que la production a rendu le bloc final.

Les erreurs bloquent l’éligibilité ; les avertissements ne le font généralement pas

Voici la distinction à garder en tête quand vous lisez la sortie du test.

Un item correspond à un objet de données structurées particulier détecté sur la page. Une seule URL peut contenir plusieurs items et plusieurs types de schéma, chacun avec un statut différent.

J’ai vu des équipes effacer une dizaine d’avertissements tout en laissant une seule erreur de propriété requise non résolue. Ça inverse la priorité. Corrigez d’abord les blocages, relancez le test, puis mettez les avertissements réellement utiles dans un backlog d’optimisation.

Un avertissement peut quand même révéler des données source faibles. Par exemple, une image ou un identifiant optionnel peut aider Google à comprendre et à présenter un Product de manière plus complète. Mais “recommandé” ne veut pas dire “secrètement requis” (et ajouter des valeurs inventées pour faire disparaître l’avertissement est pire que de le laisser tranquille).

Comment corriger les erreurs de schéma récurrentes

Propriétés requises manquantes

Le Rich Results Test indique généralement quelle propriété manque. Commencez par là, plutôt que de changer de plugin ou de copier le JSON-LD d’un autre site.

Un item Product peut manquer son nom ou les informations nécessaires sur les offres, l’avis (review), ou l’aggregate-rating. Une Recipe peut manquer une image. Les exigences varient selon le type de rich result : ouvrez la documentation de Google pour la fonctionnalité détectée et comparez la structure attendue avec l’item analysé.

Puis remontez la piste de la propriété manquante. Si un template attend un champ prix, auteur, image ou date, mais que l’enregistrement du CMS est vide, corriger le symptôme en modifiant le JSON-LD généré ne suffit pas. Corrigez plutôt le modèle de contenu, la règle de validation ou la logique de fallback du template.

D’après ce qu’on observe sur SEOJuice, les pannes “gênantes” surviennent le plus souvent à la frontière entre une logique de schéma valide et des données de page incomplètes. Le générateur sait où une valeur doit aller ; il ne peut pas fabriquer un vrai prix ou un avis visible que la page ne contient pas. Et il ne doit pas.

Mauvais types et formats de valeurs

Toutes les propriétés de schéma n’acceptent pas du texte brut. Une propriété peut exiger un nombre, une URL, une Offer, un PostalAddress ou un autre objet imbriqué. Une valeur peut sembler correcte pour un lecteur, tout en ayant un type lisible par machine erroné.

Ouvrez l’item concerné dans le test, localisez la propriété précise, puis comparez sa valeur avec le type attendu. Si le template a généré la même erreur sur une URL, testez plusieurs autres pages utilisant ce template. Une seule erreur est souvent un échantillon d’un problème plus large, pas une page isolée.

Corriger le template une fois est le choix efficace. Corriger manuellement 80 pages générées, c’est 80 occasions de refaire la même erreur (ou 79, si la “chance” porte la première correction).

Dates invalides

Les propriétés comme datePublished, dateModified et startDate doivent être des valeurs ISO 8601 lisibles par machine. Un CMS peut afficher “July 19, 2026” correctement aux lecteurs tout en injectant dans le schéma une chaîne localisée ou ambiguë.

Corrigez le formateur de date au niveau du template. Vérifiez aussi les fuseaux horaires pour les événements et les offres : même un timestamp syntaxiquement valide peut communiquer une heure de début ou d’expiration incorrecte.

Le schéma est présent dans l’éditeur, mais absent de la page

Testez l’URL en production dans le Rich Results Test. Si le type attendu n’est pas détecté, inspectez la sortie réelle plutôt que de modifier sans arrêt l’objet de schéma.

• Vérifiez que le JSON-LD apparaît dans la page livrée ou rendue.
• Contrôlez les conditions du CMS et du thème qui pilotent son insertion.
• Revisitez les paramètres et exclusions des plugins.
• Videz les caches de page, CDN et application si c’est pertinent.
• Vérifiez si l’exécution de JavaScript échoue avant l’injection du schéma.
• Confirmez que la logique de consentement ou de personnalisation ne le cache pas aux crawlers.

SEOJuice génère automatiquement le schéma sur les pages qu’il gère, mais Lida et moi testons quand même des sorties représentatives. Nous sommes une équipe de deux personnes : l’automatisation est donc essentielle. Considérer l’automatisation comme infaillible ne ferait qu’automatiser notre angle mort.

Balisage dupliqué ou en conflit

Une page peut recevoir du schéma depuis le thème, un plugin SEO, un plugin e-commerce, un plugin de schéma spécialisé et du JSON-LD personnalisé, le tout en même temps. Le Rich Results Test sépare les items détectés, ce qui rend plus facile de repérer des copies incomplètes ou inattendues.

Ne vous réjouissez pas d’un seul item Product valide tout en ignorant un deuxième bloc Product cassé. Identifiez quel système émet chaque objet, puis désignez un seul “owner” pour ce type de schéma. Désactiver la sortie redondante est généralement plus sûr que d’essayer de synchroniser plusieurs générateurs.

Attention toutefois avant de supprimer un balisage apparemment dupliqué Organization ou WebSite. Des objets à l’apparence similaire peuvent décrire des entités différentes ou servir des objectifs différents au niveau de la page. Comparez d’abord leurs identifiants, types et relations (c’est un cas où “supprimer les doublons” est beaucoup trop grossier).

Votre balisage doit correspondre au contenu visible de la page

Sur le plan technique, un balisage peut être valide tout en violant les politiques de Google sur les données structurées. Un validateur vérifie si les données peuvent être analysées ; il ne certifie pas que les affirmations sont vraies.

« Ne balisez pas du contenu qui n’est pas visible pour les lecteurs de la page. »

Les recommandations générales de Google sur les données structurées ajoutent : « Vos données structurées doivent refléter fidèlement le contenu de la page. » La conséquence est aussi explicite : « Une action manuelle sur les données structurées signifie qu’une page perd son éligibilité à apparaître en tant que rich result. »

Ne rajoutez pas des étoiles d’avis agrégées si les utilisateurs ne peuvent pas retrouver ces avis sur la page. Ne balisez pas une date d’événement que la page n’affiche jamais. Ne transformez pas un article banal en objet Recipe juste parce que le résultat Recipe paraît plus “visible”.

Cela s’applique aussi aux valeurs obsolètes. Si le prix visible du produit change, mais que le JSON-LD mis en cache conserve l’ancien prix, le balisage ne représente plus la page. Il peut avoir une syntaxe parfaite et pourtant rester faux.

L’ancien Structured Data Testing Tool a disparu

Google a déprécié son ancien Structured Data Testing Tool en 2020. La validation générique schema.org se poursuit désormais via le Schema Markup Validator, tandis que Google oriente le test d’éligibilité des rich results vers le Rich Results Test.

• Rich Results Test : vérifie si Google peut générer l’une de ses fonctionnalités de recherche prises en charge à partir de la page ou du code.
• Schema Markup Validator : vérifie le balisage par rapport au vocabulaire plus large de schema.org, y compris les types que Google ne rend pas sous forme de rich results.

Un type schema.org peut donc être valide sans générer d’enrichissement Google. Pas de contradiction : schema.org décrit énormément plus d’entités et de relations que ce que Google supporte dans sa “gallery” de recherche.

Utilisez le validateur pour répondre à : « Ce balisage schema.org est-il valide ? ». Utilisez l’outil de Google pour répondre à : « Est-il éligible à un rich result Google ? ». Et si vous avez besoin de la distinction plus profonde, notre guide Schema.org 2026 détaille ce que Google lit et utilise actuellement.

Ne cherchez pas à obtenir des rich results FAQ ou HowTo

Beaucoup de tutoriels schema.org, pourtant compétents à la base, sont aujourd’hui dépassés.

La structured-data search gallery en direct de Google reste la source à consulter avant d’implémenter un type pour gagner en visibilité sur la recherche. Les fonctionnalités supportées incluent notamment Article, Breadcrumb, Dataset, Discussion forum, Event, Job posting, Local business, Organization, Product, Profile page, Q&A, Recipe, Review snippet, Software app, Vacation rental et Video.

FAQ et HowTo sont absents.

Google a supprimé HowTo en tant que fonctionnalité de recherche en 2023. Son changelog de documentation indique : « Suppression de la documentation sur les données structurées “How-to”, car ce rich result n’est plus affiché dans les résultats de recherche, sur desktop et mobile. »

FAQ a survécu plus longtemps, sous une forme restreinte, mais cela s’est aussi terminé. Barry Schwartz a rapporté dans Search Engine Land que Google a cessé les rich results FAQ à partir du 7 mai 2026. L’avis de Google dans la documentation disait :

« Les rich results FAQ n’apparaissent plus dans Google Search. Nous allons abandonner l’affichage FAQ dans la recherche, le rapport de rich result et le support dans le test Rich results en juin 2026. »

FAQPage reste une partie du vocabulaire schema.org, et d’autres systèmes peuvent le traiter. Il ne générera pas un rich result FAQ Google. Le balisage HowTo peut encore décrire du contenu pédagogique au sens sémantique, mais il ne donne plus droit à un enrichissement HowTo dans Google Search.

Gardez des FAQs utiles et des instructions pas à pas pour vos lecteurs. Simplement, ne prévoyez pas de budget d’implémentation en partant du principe que ces deux types de schéma créeront des rich snippets Google. Cette stratégie est expirée.

Passer du test d’une page à une surveillance à l’échelle du site

Le Rich Results Test est un diagnostic au niveau page. Les rapports de Search Console indiquent ce que Google a rencontré sur les pages explorées.

Ouvrez le rapport pertinent : Breadcrumbs, Product snippets ou Merchant listings, par exemple. Analysez les URLs affectées, trouvez le template ou la source de données partagée, déployez la correction, puis sélectionnez Valider la correction quand l’option est disponible. Google doit recrawler et retraiter les URLs avant que le rapport se mette à jour.

Search Console est plus lent que le test “coller/coder” car il reflète le cycle de crawl de Google, pas votre dernière modification locale. Le délai peut être agaçant (j’ai rafraîchi ces rapports en sachant pertinemment que ça ne changerait rien), mais c’est aussi ce qui rend les données intéressantes : elles représentent les pages de production à grande échelle.

Notre audit SEO gratuit peut aider à repérer des problèmes plus larges sur le site avant de réduire l’enquête à des URLs individuelles. Confirmez ensuite l’éligibilité aux rich results avec le test officiel de Google ; un audit tiers ne devrait pas être l’autorité finale sur une fonctionnalité Google.

Pourquoi un test réussi peut ne pas produire de rich result

Un résultat valide signifie une éligibilité, pas une présence garantie à l’affichage.

Google décide d’afficher ou non un enrichissement pour chaque requête et chaque résultat. L’apparition dans la recherche peut aussi être impactée par la qualité de la page, du balisage trompeur ou non aligné, des types de fonctionnalités non supportés, et des actions manuelles liées aux données structurées.

Si le test passe mais qu’aucun enrichissement ne s’affiche :

1. Confirmez que vous avez testé l’URL canonique finale.
2. Vérifiez que l’information balisée est visible et à jour.
3. Consultez le rapport Search Console correspondant.
4. Vérifiez dans Search Console s’il y a des actions manuelles.
5. Assurez-vous que le type de schéma apparaît toujours dans la search gallery de Google.
6. Surveillez plusieurs requêtes pertinentes plutôt que de considérer une recherche manuelle unique comme concluante.

Je suis confiant dans cette séquence de diagnostic. Prédire exactement quand Google va “décorer” un résultat éligible est moins certain, car Google ne donne aucune garantie d’affichage. Réécrire le JSON-LD déjà valide à chaque fois qu’un rich result disparaît peut introduire de nouvelles erreurs sans changer la décision sous-jacente.

L’éligibilité et la présentation sont séparées au-delà du schéma. Notre guide sur les SERP snippets et la visibilité IA explique pourquoi l’indexation et le contrôle des snippets restent importants, même quand les plateformes de recherche choisissent la présentation finale.

Questions fréquentes

Comment tester si ma page peut prétendre à des rich results ?

Collez l’URL publiée dans le Rich Results Test de Google. Utilisez le mode Code pour du HTML ou du JSON-LD qui n’a pas été publié. L’outil identifie les types de rich results pris en charge et liste les erreurs, avertissements et propriétés analysées. Utilisez Search Console pour obtenir une vue agrégée sur ce que Google a détecté sur les pages explorées.

Que s’est-il passé avec le Structured Data Testing Tool ?

Google a mis fin à l’ancien Structured Data Testing Tool. Utilisez le Rich Results Test pour tester l’éligibilité des rich results Google, et le Schema Markup Validator sur validator.schema.org pour la validation plus large du vocabulaire schema.org.

Quelle différence entre le Rich Results Test et Schema Markup Validator ?

Le Rich Results Test vérifie si le balisage peut produire un rich result pris en charge par Google. Le Schema Markup Validator vérifie la validité générale de schema.org, y compris le vocabulaire que Google n’utilise pas pour les enrichissements dans la recherche. Réussir le second ne prouve pas l’éligibilité côté Google.

Quelle différence entre une erreur de schéma et un avertissement ?

Une erreur signifie qu’une propriété requise manque ou est invalide, ce qui rend l’item concerné inéligible. Un avertissement signifie généralement qu’une propriété recommandée manque, mais que l’item reste éligible. Corrigez d’abord toutes les erreurs, puis évaluez les avertissements selon leur utilité et selon les données réellement affichées sur la page.

Le schéma FAQ génère-t-il encore des rich results en 2026 ?

Non. Google a supprimé intégralement les rich results FAQ le 7 mai 2026, puis a abandonné le support de test et de reporting associé. FAQPage reste un vocabulaire schema.org valide, mais il ne génère plus un rich result FAQ Google.

Pourquoi aucun schéma n’est détecté sur mon URL en direct ?

Le balisage n’a peut-être pas atteint la production, il peut être masqué par une condition de template, rester derrière une mise en cache obsolète, ou dépendre de JavaScript qui a échoué pendant le rendu. Comparez le mode Code avec le mode URL, puis inspectez la sortie production rendue et chaque système capable d’injecter du schéma.

Pourquoi mon rich result ne s’affiche pas alors que le test passe ?

“Passer” signifie que la page est éligible, pas qu’un affichage enrichi sera garanti. Confirmez que le balisage correspond au contenu visible, vérifiez le rapport Search Console pertinent, assurez-vous que la fonctionnalité reste supportée et vérifiez que le site n’a pas d’action manuelle liée aux données structurées.

Si vous générez ou réparez du JSON-LD, commencez par une page représentative, testez-la en mode Code, déployez-la, puis testez l’URL en direct. Une fois cette page propre, appliquez le correctif au niveau du template sur l’ensemble du site, puis laissez Search Console confirmer le résultat à grande échelle.