Faut-il vraiment implémenter tous les nouveaux types de données structurées supportés par Google ?

Pourquoi Google ajoute-t-il ces types de données structurées maintenant ?

Google ne communique jamais sur le timing de ces ajouts, mais l'extension du test des résultats enrichis à Article, Review et EmployerAggregateRating n'est pas anodine. Ces trois types répondent à des besoins utilisateurs massifs : consommation de contenu éditorial, décisions d'achat basées sur des avis, recherche d'emploi.

L'ajout de ces formats dans l'outil de test signifie que Google peut désormais valider et afficher ces données enrichies dans les SERPs de manière plus systématique. Ce n'est pas une garantie d'affichage — ça ne l'a jamais été — mais c'est un signal fort que ces markups deviennent éligibles à des fonctionnalités de recherche avancées.

Quelle différence entre « supporté » et « affiché dans les résultats » ?

C'est le piège classique. Google peut comprendre un type de donnée structurée sans pour autant l'exploiter visuellement dans les résultats de recherche. Le support technique ne garantit pas l'affichage d'un rich snippet.

Dans le cas présent, Mueller annonce que ces types sont intégrés au test des résultats enrichis — ce qui veut dire que l'outil peut valider votre balisage et signaler les erreurs. Mais l'affichage effectif dépend d'autres critères : pertinence de la requête, qualité du contenu, concurrence sur la SERP, et probablement des seuils de confiance internes à Google.

Quels sites sont concernés par ces nouveaux types ?

Les médias en ligne, blogs et sites d'actualité tirent profit du markup Article pour signaler leur contenu éditorial. Les sites e-commerce, comparateurs et plateformes d'avis exploitent le markup Review pour afficher des étoiles et notes agrégées. Les sites carrière, jobboards et pages « Rejoignez-nous » peuvent utiliser EmployerAggregateRating pour valoriser leur marque employeur.

Si votre site publie du contenu structuré dans l'un de ces formats, vous avez tout intérêt à auditer et valider votre implémentation Schema.org dès maintenant. Google ne vous préviendra pas une seconde fois.

• Article : sites éditoriaux, blogs, magazines en ligne, portails d'actualité
• Review : e-commerce, comparateurs, plateformes d'avis clients, guides d'achat
• EmployerAggregateRating : sites corporate, pages carrière, jobboards, plateformes RH
• Le test des résultats enrichis permet de valider techniquement votre balisage, pas de garantir l'affichage
• L'ajout au test officiel de Google est un signal d'intention : ces formats deviennent prioritaires

Cette annonce est-elle cohérente avec les pratiques observées sur le terrain ?

Oui et non. Les markups Article et Review existent depuis des années dans la spec Schema.org et sont déjà largement déployés. Ce qui change, c'est leur intégration officielle dans l'outil de test de Google — un signal que le moteur veut standardiser leur validation.

En revanche, le markup EmployerAggregateRating est beaucoup moins mature côté affichage. On observe très peu de rich snippets liés aux notes employeur dans les SERPs classiques, même sur des requêtes type « avis entreprise » ou « travailler chez ». Google privilégie encore ses propres sources (Google for Jobs, Knowledge Graph). [A vérifier] si cet ajout préfigure un déploiement plus large ou s'il reste cantonné à des cas d'usage limités.

Quelles nuances faut-il apporter à cette déclaration ?

Mueller ne dit pas que ces markups sont nouveaux, il dit que le test des résultats enrichis les supporte désormais. Nuance. Vous pouviez déjà implémenter Article, Review ou EmployerAggregateRating avant cette annonce — c'est juste que l'outil officiel de validation ne les prenait pas en charge, ou les validait via des formats génériques.

Autre point : Google ne publie aucune donnée sur l'impact réel de ces markups sur les taux de clics ou le positionnement. On sait que les étoiles en SERP peuvent booster le CTR, mais l'effet sur le ranking reste flou. Ne compte pas sur ces données structurées pour compenser un contenu faible ou un profil de liens médiocre.

Dans quels cas cette évolution ne change-t-elle rien pour vous ?

Si vous n'êtes pas dans les secteurs concernés — pas de contenu éditorial structuré, pas d'avis clients, pas de page carrière — cette annonce ne vous apporte rien de concret. Inutile de forcer un markup Review sur des pages qui n'en contiennent pas.

Même dans les secteurs concernés, l'impact dépend de la maturité de votre implémentation. Si vous avez déjà un balisage propre validé via d'autres outils (schéma.org validator, extensions Chrome), vous n'êtes pas en retard. Ce qui compte, c'est la qualité de l'implémentation, pas l'outil de validation.

Que faut-il faire concrètement si vous publiez du contenu éditorial ou des avis ?

Première étape : auditer votre balisage existant. Si vous utilisez déjà Article ou Review, passez vos pages dans le test des résultats enrichis de Google pour vérifier qu'aucune erreur ne remonte. Les implémentations partielles ou mal formées ne servent à rien — pire, elles peuvent nuire.

Deuxième étape : compléter les propriétés recommandées. Google distingue les propriétés obligatoires (sans lesquelles le markup est invalide) et les propriétés recommandées (qui enrichissent l'affichage). Ajouter author, datePublished, image pour Article, ou reviewRating, reviewBody pour Review peut faire la différence entre un résultat enrichi générique et un snippet qui se démarque.

Quelles erreurs éviter lors de l'implémentation de ces markups ?

Erreur classique : dupliquer les markups en JSON-LD et Microdata sur la même page. Ça crée des conflits et Google peut ignorer les deux. Choisissez un format et tenez-vous-y — JSON-LD reste le plus recommandé par Google.

Autre piège : baliser du contenu généré automatiquement sans validation humaine. Si vous agrégez des avis tiers, assurez-vous que les données remontées dans le markup correspondent exactement à ce qui est affiché sur la page. Google détecte les incohérences et peut retirer votre éligibilité aux rich snippets.

Comment vérifier que votre site est conforme et optimisé pour ces nouveaux types ?

Utilisez le test des résultats enrichis de Google (Rich Results Test) en priorité, puisque c'est lui qui détermine si votre markup sera exploité. Complétez avec le validateur Schema.org pour une vérification technique plus stricte.

Surveillez aussi la Search Console, section Améliorations. Google y remonte les erreurs détectées sur vos markups (propriétés manquantes, valeurs invalides, conflits). Si vous voyez des avertissements sur Article, Review ou EmployerAggregateRating, corrigez-les avant que Google ne cesse d'afficher vos résultats enrichis.

• Auditer les pages clés avec le test des résultats enrichis de Google
• Compléter les propriétés recommandées (author, image, datePublished, reviewRating)
• Éviter les duplications de markup (JSON-LD + Microdata sur la même page)
• Vérifier la cohérence entre données structurées et contenu visible
• Surveiller la Search Console pour détecter les erreurs remontées par Google
• Tester l'affichage en conditions réelles via des requêtes ciblées