Pourquoi Google remplace-t-il le Structured Data Testing Tool par le Rich Results Test ?

Quelle est la différence entre les deux outils ?

Le Structured Data Testing Tool validait tous les types de balisage schema.org présents sur une page, qu'ils soient exploités ou non par Google pour enrichir les résultats de recherche. Un schema.org de type Article, Person, Organization, Event — tout passait à la moulinette, et l'outil renvoyait un rapport de conformité technique.

Le Rich Results Test, lui, adopte une approche radicalement différente : il ne teste que les schemas susceptibles de déclencher un affichage enrichi dans les SERP. Si votre balisage ne génère pas de rich snippet, d'étoiles de notation, de fil d'Ariane ou de carte enrichie, l'outil ne le prendra même pas en compte. C'est un filtre pragmatique centré sur l'impact utilisateur visible.

Pourquoi ce changement de cap maintenant ?

Parce que beaucoup de sites balançaient du schema.org à tout-va sans se poser la question de son utilité réelle. On voyait des balises Author, Publisher, SameAs sur des pages qui n'avaient aucune chance de décrocher un affichage enrichi. Le Structured Data Testing Tool donnait une fausse impression de conformité.

Google recentre l'attention sur ce qui compte vraiment : les données structurées qui améliorent concrètement l'affichage dans les résultats. Si un schema n'a aucun effet visible, pourquoi perdre du temps à le valider ? C'est un signal clair que Google veut éviter les efforts inutiles côté webmasters — et peut-être aussi réduire le bruit dans ses propres systèmes d'analyse.

Qu'est-ce que ça change pour un praticien SEO ?

Ça force à prioriser les schemas selon leur ROI SEO. Fini le temps où on validait mécaniquement tous les types de balisage pour cocher une case. Désormais, il faut se demander : ce schema va-t-il déclencher un rich snippet ? Un carrousel ? Des étoiles ? Si la réponse est non, Google lui-même te dit de ne pas t'embêter.

Ça simplifie aussi le diagnostic : si le Rich Results Test ne remonte rien sur une page pourtant balisée, soit le schema n'est pas éligible aux résultats enrichis, soit il y a une erreur qui empêche son exploitation. Dans les deux cas, le signal est plus clair qu'avec l'ancien outil.

• Le Rich Results Test ne valide que les schemas ayant un impact visible dans les SERP
• Les schemas non éligibles aux résultats enrichis ne sont plus testés ni signalés par l'outil
• Cela oblige à concentrer les efforts sur les balises qui apportent un bénéfice SEO mesurable
• Google envoie un message clair : la conformité technique seule ne suffit pas, il faut un effet utilisateur

Cette distinction a-t-elle toujours existé dans les faits ?

Soyons honnêtes : Google n'a jamais utilisé tous les types de schema.org. Depuis le début, seule une poignée de balises déclenchaient des affichages enrichis — Product, Recipe, Event, Article, FAQ, HowTo, Review. Le reste ? Stocké, peut-être analysé pour le Knowledge Graph, mais sans effet direct dans les SERP.

Ce que Mueller formalise ici, c'est une pratique déjà en vigueur. Le changement, c'est que Google l'assume désormais publiquement et adapte ses outils en conséquence. Avant, on pouvait se bercer d'illusions en voyant tous ses schemas validés. Maintenant, l'outil te met face à la réalité : si ça ne génère pas de résultat enrichi, ça n'existe pas pour Google.

Tous les schemas valides déclenchent-ils vraiment un affichage enrichi ?

[A vérifier] — et c'est là que ça coince. Même avec un balisage parfaitement conforme testé positif dans le Rich Results Test, rien ne garantit un affichage enrichi en production. Google se réserve le droit de ne pas afficher un rich snippet même si le schema est techniquement correct.

Les facteurs jouent : qualité perçue du site, pertinence de la requête, concurrence sur la SERP, expérimentations A/B côté Google. On voit régulièrement des pages avec un balisage impeccable qui ne décrochent aucun résultat enrichi, et d'autres avec des erreurs mineures qui s'affichent quand même. Le Rich Results Test dit « éligible », pas « garanti ». Nuance capitale.

Faut-il supprimer tous les schemas non testés par le Rich Results Test ?

Pas forcément. Certains schemas comme Organization, Person, SameAs ne déclenchent pas de résultats enrichis mais alimentent probablement le Knowledge Graph. Si tu vises une entité dans le panneau de connaissances, ces balises gardent un intérêt — même si l'outil ne les valide plus.

Le problème, c'est qu'on navigue à vue. Google ne documente pas clairement quels schemas non éligibles aux rich snippets ont encore une utilité. Ma position : garde ceux qui structurent ton entité principale (Organization, Person sur une page auteur), mais évite le balisage décoratif qui ne sert à rien. Si tu dois choisir où investir du temps de dev, concentre-toi sur ce que le Rich Results Test valide.

Quels schemas privilégier en priorité absolue ?

Concentre tes efforts sur les schemas éligibles aux résultats enrichis documentés par Google : Product (avec Review/AggregateRating), Recipe, Article, Event, FAQ, HowTo, BreadcrumbList, VideoObject, JobPosting. Ce sont ceux que le Rich Results Test valide et qui peuvent déclencher un affichage amélioré.

Pour un site e-commerce, Product + Review est la base absolue. Pour un média, Article avec image structurée. Pour un site de service local, LocalBusiness. Chaque type de site a son combo gagnant — identifie-le et implémente-le proprement avant de t'éparpiller sur des schemas secondaires.

Comment auditer rapidement un site avec cette nouvelle approche ?

Passe toutes tes pages stratégiques dans le Rich Results Test via l'API ou manuellement. Si une page censée avoir des résultats enrichis ne remonte rien, soit le balisage est absent, soit il contient des erreurs, soit il n'est pas éligible. Dans tous les cas, c'est un signal d'action.

Utilise aussi la Search Console, section Enhancements, qui remonte les erreurs et avertissements sur les schemas éligibles aux résultats enrichis. Corrige en priorité les erreurs qui empêchent l'affichage, puis les avertissements qui dégradent la qualité. Laisse tomber les schemas non documentés par Google — ils ne te rapporteront rien en SERP.

Quelles erreurs éviter avec cette migration d'outil ?

Première erreur : continuer à valider avec l'ancien outil par habitude et croire que tout va bien parce que le balisage est techniquement correct. Si le Rich Results Test ne détecte rien, ton schema ne sert à rien pour les SERP, point.

Deuxième erreur : supprimer brutalement tous les schemas non testés sans réfléchir. Certains peuvent alimenter le Knowledge Graph ou être utilisés par des outils tiers. Analyse l'usage réel avant de tout virer. Troisième erreur : penser qu'un balisage validé par le Rich Results Test garantit un affichage enrichi en production — c'est une condition nécessaire, pas suffisante.

• Auditer toutes les pages stratégiques avec le Rich Results Test, pas l'ancien outil
• Prioriser l'implémentation des schemas Product, Article, FAQ, Recipe, Event selon ton secteur
• Surveiller la section Enhancements de la Search Console pour détecter les erreurs en production
• Corriger en priorité les erreurs bloquantes, puis les avertissements
• Ne pas supprimer les schemas Organization/Person s'ils structurent ton entité principale
• Tester l'affichage réel dans les SERP après chaque modification de balisage