Faut-il vraiment bannir les avis externes de vos données structurées Schema.org ?

Qu'entend exactement Google par "avis non originaux" ?

Google distingue deux catégories d'avis : ceux que vous collectez directement auprès de vos clients via votre propre système (formulaire post-achat, plateforme propriétaire, questionnaire interne), et ceux que vous récupérez depuis une source tierce (Trustpilot, Avis Vérifiés, Google Reviews, Amazon, etc.).

La position de Mueller est limpide : si l'avis ne provient pas de votre propre mécanisme de collecte, il ne doit pas figurer dans votre balisage Schema.org de type Review ou AggregateRating. Peu importe que vous ayez une API officielle avec la plateforme tierce ou que vous affichiez ces avis sur votre site — si vous n'êtes pas à l'origine de la collecte, vous êtes hors-jeu.

Pourquoi Google impose-t-il cette restriction ?

La raison officielle tient à la qualité et à l'authenticité des données affichées dans les SERP. Google veut éviter que les sites manipulent les rich snippets en important massivement des avis positifs depuis des plateformes tierces sans contrôle réel sur leur origine.

En pratique, ça limite aussi les cas où un même avis apparaît en double : une fois sur la fiche Google Business Profile du commerce, une autre fois dans les résultats organiques via Schema.org. Google cherche à éviter la redondance et à maintenir une hiérarchie claire entre ses propres systèmes d'avis (GBP, Shopping) et le web ouvert.

Cette règle s'applique-t-elle à tous les types de Schema ?

Non. La directive concerne spécifiquement les balises Review et AggregateRating dans Schema.org. Si vous utilisez d'autres types de structured data (Product, Organization, LocalBusiness sans avis), vous n'êtes pas impacté.

Par contre, dès que vous ajoutez une propriété aggregateRating ou un objet review dans votre JSON-LD ou microdonnées, vous entrez dans le champ d'application de cette règle. Même un seul avis externe suffit à vous exposer à une action manuelle si Google détecte que la source n'est pas votre propre système de collecte.

• Seuls les avis collectés directement par vous (formulaire interne, plateforme propriétaire) sont autorisés dans Schema.org.
• Les avis importés depuis Trustpilot, Google Reviews, Avis Vérifiés, Amazon, etc. ne doivent PAS être balisés.
• La règle vise à éviter la manipulation des rich snippets et la redondance dans les SERP.
• Elle s'applique uniquement aux balises Review et AggregateRating, pas aux autres types Schema.
• Même avec une API officielle, si vous n'êtes pas à l'origine de la collecte, vous êtes hors directive.

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

Oui et non. Google a toujours eu une ligne dure sur les avis dans ses quality guidelines, mais l'application concrète est inégale. On voit encore des milliers de sites e-commerce utiliser des avis Trustpilot ou Avis Vérifiés dans leur Schema.org sans action manuelle visible.

Soyons honnêtes : Google n'a pas les ressources humaines pour traquer chaque site manuellement. La plupart des pénalités arrivent soit après un signalement concurrent, soit quand un site abuse trop ouvertement (faux avis, notes manipulées, spam massif). Si votre site affiche 4,9 étoiles agrégées depuis une source tierce mais que tout le reste est clean, vous pouvez passer sous le radar pendant des années. [A vérifier] : aucune donnée publique ne documente le taux réel d'actions manuelles pour cette infraction spécifique.

Quelles nuances faut-il apporter à cette règle ?

Mueller ne précise pas ce qui constitue "votre propre collecte". Si vous utilisez un widget tiers hébergé sur votre domaine (type Reviews.io, Yotpo, Judge.me), techniquement vous collectez via un intermédiaire — mais vous contrôlez l'interface, le formulaire, et vous êtes propriétaire des données.

Dans ce cas de figure, la zone grise persiste. Certains experts considèrent que tant que vous maîtrisez le cycle complet (déclenchement de l'email, affichage sur votre site, modération), vous respectez l'esprit de la directive. D'autres jouent la sécurité totale et n'utilisent que des systèmes 100 % internes. Mon avis ? Si vous passez par une plateforme tierce mais que vous en êtes contractuellement propriétaire des avis (pas juste une licence d'affichage), vous êtes probablement dans les clous — mais Google ne l'a jamais confirmé noir sur blanc.

Dans quels cas cette règle ne s'applique-t-elle pas ?

Si vous êtes un agrégateur d'avis (type Trustpilot, Yelp, TripAdvisor), vous pouvez évidemment baliser vos propres avis — puisque c'est vous qui les collectez. De même, si vous êtes une marketplace (Amazon, eBay, Airbnb) et que les avis sont déposés directement sur votre plateforme, pas de souci.

Autre cas limite : les médias et comparateurs. Si vous publiez un test produit avec une note éditoriale (type Les Numériques, 60 Millions de Consommateurs), c'est un avis original — vous pouvez le baliser. Par contre, si vous agrégez les notes de plusieurs rédactions externes, on retombe dans la zone grise. Google n'a jamais clarifié ce point, et les pratiques du marché varient énormément.

Que faut-il faire concrètement si vous utilisez des avis externes ?

Première étape : auditer votre balisage Schema actuel. Inspectez votre JSON-LD ou vos microdonnées et repérez toutes les occurrences de "@type": "Review" ou "aggregateRating". Pour chaque instance, identifiez la source des avis : proviennent-ils de votre propre système de collecte, ou d'une plateforme tierce ?

Si la réponse est "tierce", vous avez deux options. Soit vous retirez purement et simplement le balisage (solution la plus sûre), soit vous migrez vers un système de collecte propriétaire (Reviews.io, Yotpo, ou développement interne) et vous ne balisez QUE les nouveaux avis collectés via ce canal. Évitez la tentation de garder l'ancien balisage "en attendant" — c'est le meilleur moyen de déclencher une action manuelle le jour où Google scanne votre site.

Quelles erreurs éviter absolument ?

Ne tentez pas de maquiller la source en modifiant l'attribut author ou publisher dans le Schema pour faire croire que l'avis vient de chez vous. Google croise ces données avec le contenu visible de la page — si vous affichez un logo Trustpilot à côté de l'avis mais que votre JSON-LD prétend qu'il vient de votre propre système, c'est un red flag énorme.

Autre piège classique : baliser des avis Google Business Profile récupérés via l'API Places. Même si techniquement ce sont "vos" avis (liés à votre fiche), Google les considère comme externes pour le balisage Schema sur votre site web. Ils doivent rester cantonnés à votre GBP — point final. Et c'est là que ça coince : beaucoup de plugins WordPress ou Shopify importent automatiquement ces avis et les balisent sans vous prévenir.

Comment vérifier que votre site est conforme ?

Utilisez le Rich Results Test de Google (search.google.com/test/rich-results) pour valider votre balisage. L'outil ne détecte pas la source des avis, mais il repère les erreurs de structure. Ensuite, passez en Search Console dans l'onglet "Améliorations" → "Avis sur les produits" : si vous voyez des warnings ou des erreurs, creusez immédiatement.

Pour un contrôle humain, comparez votre JSON-LD avec les avis affichés visuellement sur la page. Si vous voyez un décalage (avis balisés ≠ avis visibles), ou si les sources ne matchent pas, c'est le moment de corriger. Faites ce check sur vos pages à fort trafic en priorité — produits bestsellers, homepage, catégories principales.

• Auditer tous les Schema Review et AggregateRating actuellement en place sur le site
• Identifier la source réelle de chaque avis balisé (interne vs externe)
• Retirer immédiatement le balisage des avis provenant de plateformes tierces (Trustpilot, Avis Vérifiés, Google Reviews, etc.)
• Mettre en place un système de collecte propriétaire si vous voulez conserver des rich snippets étoilés
• Vérifier que les plugins/modules tiers (WordPress, Shopify, PrestaShop) ne réinjectent pas automatiquement du balisage d'avis externes
• Tester avec le Rich Results Test et surveiller les rapports Search Console "Améliorations"