Faut-il vraiment retirer les avis agrégés de votre page d'accueil ?

Pourquoi Google interdit-il les avis sur les pages d'accueil ?

La position de Google repose sur un principe simple : un avis agrégé doit porter sur une entité précise — un produit, un service, une entreprise locale. La homepage d'un site n'est pas une entité en soi, c'est une porte d'entrée.

Les guidelines Schema.org stipulent qu'un aggregateRating doit être associé à un objet typé : Product, LocalBusiness, Recipe, etc. Plaquer des étoiles sur une page d'accueil revient à noter "le site" dans son ensemble, ce qui n'a pas de sens structurel. Google cherche à éviter que les webmasters ne manipulent les SERP avec des étoiles factices qui n'apportent aucune valeur informationnelle.

Que révèlent les chiffres sur l'usage réel ?

Le constat est brutal : 23,9% des pages mobiles et 23,7% des pages desktop affichent des aggregate ratings. Près d'un quart du web ignore ou contourne cette règle. Deux explications possibles : soit l'ignorance des guidelines, soit un calcul risque/bénéfice où le gain en CTR compense le risque théorique.

Cette donnée signale aussi que Google tolère encore massivement cette pratique — sinon, on verrait des vagues de manual actions. La question devient : jusqu'à quand cette tolérance durera-t-elle ? Les algorithmes évoluent, et ce qui passe aujourd'hui peut être pénalisé demain sans préavis.

Quelle différence entre homepage et page entreprise ?

Un piège classique : confondre la homepage générique et une page entité. Si votre site est celui d'un restaurant, d'un hôtel, d'une agence locale, la homepage *peut* légitimement porter un Schema LocalBusiness avec aggregateRating — parce qu'elle représente l'entité physique notée.

En revanche, sur un site e-commerce multi-produits ou un média, afficher des étoiles génériques en homepage n'a aucun ancrage sémantique. Le type de site change tout : une boulangerie peut noter sa homepage, Amazon non.

• Les aggregate ratings doivent porter sur une entité typée : produit, service, entreprise locale, recette, événement.
• 23,9% des sites violent cette règle, ce qui indique soit une méconnaissance, soit un arbitrage risque/gain assumé.
• La tolérance actuelle de Google ne garantit rien pour l'avenir — les algorithmes de détection des abus en rich snippets s'affinent en permanence.
• Une homepage représentant une LocalBusiness peut légitimement afficher des avis, contrairement à un portail générique ou un site catalogue.
• Le risque principal : perte des rich snippets, voire action manuelle si Google détecte une manipulation flagrante du balisage structured data.

Cette règle est-elle appliquée strictement par Google ?

Soyons honnêtes : si 23,9% des sites enfreignent la règle sans conséquence visible, c'est que l'application reste laxiste. Google communique une norme théorique, mais les filtres automatiques ne sanctionnent pas systématiquement. On observe même des sites majeurs avec des étoiles homepage qui conservent leurs rich snippets depuis des années.

Cela dit, cette tolérance n'est pas une permission. [A vérifier] : Google n'a jamais publié de données sur le taux de manual actions liées spécifiquement aux aggregate ratings homepage. Le risque reste difficile à quantifier — ce qui rend le pari inconfortable pour un site corporate ou un pure player e-commerce exposé.

Quelles nuances faut-il apporter selon le type de site ?

La règle n'a pas le même poids partout. Pour un site local mono-entité (restaurant, cabinet médical, artisan), la homepage *est* l'entité. Le Schema LocalBusiness avec aggregateRating y a toute sa place, Google le valide explicitement. Aucun problème de conformité.

Pour un site e-commerce, SaaS, ou média, la homepage n'est qu'un hub de navigation. Y coller des étoiles agrégées revient à inventer un objet non typé. Le gain en CTR peut être tentant, mais la fragilité juridique et algorithmique est réelle. Si Google durcit ses filtres demain, ces sites seront les premiers touchés.

Le vrai problème : la confusion entre Schema types

Beaucoup de webmasters utilisent un Schema Organization sur la homepage, puis y ajoutent un aggregateRating. Techniquement, ça passe la validation Schema.org — Organization accepte aggregateRating. Mais sémantiquement, ça n'a aucun sens si l'Organisation n'est pas l'objet noté (un média ne note pas "Le Monde", il note des articles).

La subtilité : un aggregateRating doit refléter des avis *sur* l'entité, pas *émis par* l'entité. Cette confusion alimente 90% des abus. Google détecte de mieux en mieux cette incohérence via le Knowledge Graph et les signaux de citation externes (Trustpilot, Google Reviews, etc.).

Que faire si vous avez des avis agrégés en homepage ?

Premier réflexe : identifiez le type d'entité que représente votre site. Si c'est un LocalBusiness, un Restaurant, un Hotel, gardez vos étoiles — elles sont légitimes. Assurez-vous simplement que le Schema est correctement typé et que les avis correspondent à des reviews réelles et vérifiables.

Si votre site est un portail, un e-commerce multi-produits, ou un média, retirez le aggregateRating de la homepage. Déplacez-le sur les pages produits, services, ou articles où il a un ancrage sémantique. Le gain en rich snippets sur ces pages ciblées compensera largement la perte hypothétique en homepage.

Comment vérifier la conformité de votre balisage ?

Passez votre homepage dans le Rich Results Test de Google. Si l'outil détecte un aggregateRating, regardez à quel type d'objet il est rattaché. Si c'est un Organization, Product, ou WebPage générique sans contexte d'avis, vous êtes hors guidelines.

Complétez avec Google Search Console : section Améliorations > Avis. Si des erreurs ou warnings apparaissent sur la homepage, c'est un signal que Google détecte une incohérence. Ne misez pas sur l'absence d'erreur visible — les filtres évoluent et ce qui passe aujourd'hui peut être flaggé demain.

Quelles erreurs éviter absolument ?

Ne tombez pas dans le piège du "Schema stuffing" : empiler Organization + Product + aggregateRating sur une homepage pour maximiser les rich snippets. Google pénalise de plus en plus cette sur-optimisation, surtout quand les données ne correspondent à aucune entité réelle crawlable ailleurs sur le web.

Évitez aussi de créer des avis fictifs ou de recycler des reviews produits pour les agréger en homepage. Google croise ses données avec des sources tierces (Trustpilot, Yelp, Google Business Profile) — toute incohérence flagrante expose à une action manuelle. La cohérence inter-sources devient un critère de validation de plus en plus scruté.

• Auditer le Schema de votre homepage avec Rich Results Test et valider le type d'entité
• Retirer tout aggregateRating si votre site n'est pas une entité unique notée (LocalBusiness, Restaurant, Hotel, etc.)
• Déplacer les avis agrégés sur les pages produits, services, ou locales où ils ont un ancrage sémantique précis
• Vérifier la cohérence entre vos avis structurés et les sources externes (Trustpilot, Google Reviews)
• Surveiller Google Search Console section Améliorations > Avis pour détecter tout warning émergent
• Documenter l'origine de chaque review agrégée pour justifier la légitimité du balisage en cas de contrôle