La semaine dernière, un client m'envoie un mail paniqué : « Google affiche 2,8 étoiles sur ma fiche produit alors qu'on a que des 5/5 sur le site. » Je vais voir. Le balisage Review était posé à la main dans le template, avec une date figée en 2023 et un ratingValue à 4,8 pour un produit noté 3,9. Google n'avait pas volé les étoiles : il avait lu ce qu'on lui donnait, puis il avait arrêté d'y croire.
C'est le paradoxe des données structurées d'avis et d'évaluations : elles sont parmi les plus faciles à implémenter et parmi les plus faciles à rater. Un balisage correct vous donne des étoiles dans les résultats de recherche. Un balisage approximatif vous donne une pénalité silencieuse — pas de message dans la Search Console, juste des étoiles qui disparaissent sans explication. Et quand elles disparaissent, personne ne s'en aperçoit pendant des mois.
Points clés à retenir
- Review = un avis unique signé. AggregateRating = une note moyenne calculée sur N avis. Les deux se balisent en JSON-LD, pas en microdata.
- Google refuse les avis « self-serving » : une entreprise ne peut pas baliser ses propres notes sur sa propre page d'accueil.
- Les propriétés itemReviewed, ratingValue, reviewCount (ou ratingCount), author et datePublished sont non négociables.
- Un ratingValue hors échelle fait rejeter tout le bloc. Une échelle mal déclarée aussi.
- Le test Rich Results reste le seul contrôle fiable avant mise en production — et il ne détecte pas les incohérences de contenu.
Comment les données structurées d'avis influencent réellement le SEO
Un extrait enrichi avec étoiles ne fait pas monter un site dans le classement. Je le dis clairement parce que c'est ce que beaucoup de prestataires vendent. Le balisage n'est pas un facteur de positionnement direct, et Google le répète depuis des années. Ce qu'il fait, en revanche, c'est modifier le taux de clic — et là, l'effet est massif.
Sur un site de matériel de randonnée que je suivais, l'ajout d'étoiles sur 40 fiches produits a fait passer le CTR moyen de 2,1 % à 3,4 % en six semaines, à position quasi identique. Le trafic organique a grimpé de près de 30 % sans qu'une seule page ne bouge dans les résultats. Voilà le vrai levier : vous ne montez pas, vous êtes plus cliqué.
Qu'est-ce que les données structurées et comment sont-elles utilisées en SEO ?
Les données structurées sont un vocabulaire ajouté au code HTML pour décrire le contenu de façon lisible par une machine. Le standard de fait s'appelle schema.org, et le format recommandé par Google est JSON-LD — un bloc de code placé dans le <head> ou avant la fermeture du <body>, séparé du contenu visible.
En SEO, elles servent à obtenir des résultats enrichis : étoiles, prix, disponibilité, fourchette de dates, temps de cuisson. Elles ne remplacent jamais un bon contenu. Elles rendent un bon contenu plus visible.
Review ou AggregateRating : laquelle choisir ?
La confusion entre les deux est la première cause de balisage invalide que je rencontre. Voici la distinction en pratique :
- Review décrit un avis individuel : un auteur, une note, un texte, une date. Utile pour une page qui met en avant un témoignage unique et substantiel.
- AggregateRating décrit une moyenne : une note globale, un nombre d'avis, éventuellement une répartition. C'est ce qui produit les étoiles sur une fiche produit.
- Les deux peuvent coexister sur la même page, mais un AggregateRating seul sans avis réel derrière est un signal que Google sanctionne.
- Point souvent oublié : si vous balisez une Review, elle doit être visible sur la page. Pas de note cachée en footer.
Quel est un exemple de données structurées d'avis ?
Voici un bloc JSON-LD fonctionnel pour un avis unique sur un produit :
{
"@context": "https://schema.org/",
"@type": "Review",
"itemReviewed": {
"@type": "Product",
"name": "Sac de randonnée 45L"
},
"reviewRating": {
"@type": "Rating",
"ratingValue": "4",
"bestRating": "5",
"worstRating": "1"
},
"author": {
"@type": "Person",
"name": "Camille Roux"
},
"datePublished": "2026-03-12",
"reviewBody": "Léger, solide, la sangle ventrale tient mal sur les longues distances."
}Et pour une note agrégée :
{
"@context": "https://schema.org/",
"@type": "Product",
"name": "Sac de randonnée 45L",
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.3",
"reviewCount": "127"
}
}Deux pièges sautent aux yeux quand on compare avec ce que je vois en production. Le premier : reviewCount qui ne correspond pas au nombre réel d'avis affichés sur la page. Le second : bestRating absent, ce qui fait que Google suppose une échelle sur 5 par défaut — pratique quand vos notes sont sur 10. Si votre site affiche des notes sur 10, vous DEVEZ déclarer bestRating: "10" et vos ratingValue doivent correspondre.
Les règles d'éligibilité que Google applique sans prévenir
Un balisage parfaitement valide au sens du validateur peut quand même être ignoré par Google. C'est la partie que personne ne documente clairement, et c'est celle qui m'a coûté le plus de temps à comprendre.
La règle centrale : pas d'avis sur vous-même. Si vous êtes une agence et que vous balisez des avis clients sur votre page d'accueil, Google ne les affichera pas. Point final. Les seules exceptions concernent les sites tiers qui recensent plusieurs entreprises (type comparateur, annuaire) — et là, c'est l'entreprise évaluée qui ne doit pas être l'éditeur du site.
Le piège des avis « self-serving »
Concrètement, un site marchand qui vend ses propres produits peut baliser les avis clients sur ces produits. Une entreprise de services qui balise ses avis clients sur sa page d'accueil, non. La frontière est parfois floue : un site de e-commerce qui vend des produits de marques tierces n'est pas dans la même situation qu'un artisan qui vend ses prestations. Dans le doute, considérez que la restriction s'applique.
Contenu éditorial ou commercial : ce n'est pas la même chose
Un site qui publie un comparatif de logiciels avec des avis balisés n'est pas un marchand. Les règles diffèrent selon la nature du contenu. Et il existe un cas particulier : les avis dits « éditoriaux », où un média donne sa propre note à un produit. Ces notes sont balisables, mais elles doivent être clairement attribuées à l'auteur du média, pas présentées comme des avis d'utilisateurs.
Tableau : Review vs AggregateRating en un coup d'œil
| Critère | Review | AggregateRating |
|---|---|---|
| Objet | Un avis unique, signé | Une note moyenne sur N avis |
| Propriétés obligatoires | itemReviewed, reviewRating, author, datePublished | ratingValue, au moins ratingCount ou reviewCount |
| Résultat visuel | Étoiles + extrait de citation | Étoiles + nombre d'avis |
| Cas d'usage typique | Page « témoignages », fiche produit avec 1 avis long | Fiche produit, page de résultats de recherche interne |
| Piège principal | Auteur absent ou anonyme | reviewCount incohérent avec le contenu affiché |
Quel est un bon outil pour tester les données structurées ?
Il n'y en a pas un, il y en a deux, et ils ne servent pas à la même chose. Le Rich Results Test de Google indique si votre balisage est éligible à un résultat enrichi — c'est le test « est-ce que ça s'affiche ». Le validateur du Schema Markup Validator (schema.org) vérifie la conformité syntaxique et sémantique au vocabulaire — c'est le test « est-ce que c'est bien écrit ».
Un bloc peut passer l'un et échouer l'autre. J'ai eu le cas sur une fiche produit où AggregateRating était syntaxiquement valide mais où reviewCount était en string « 127 » au lieu d'un entier. Le validateur schema.org a validé. Le Rich Results Test a signalé une erreur de type. Après correction, les étoiles sont apparues en 72 heures.
Comment peut-on traiter des données structurées à grande échelle ?
Sur un site de 500 fiches produits, on ne balise pas à la main. Deux approches tiennent la route :
- Génération par le CMS : la plupart des CMS modernes et des plugins SEO (Yoast, Rank Math) injectent du JSON-LD automatiquement. Le problème, c'est qu'ils le font parfois mal — notamment sur les avis, où le plugin se base sur les avis natifs du CMS et peut produire des reviewCount qui ne correspondent pas à ce qui est affiché.
- Génération dans le template : on injecte un bloc JSON-LD construit côté serveur à partir des données réelles de la base. Plus de contrôle, plus de maintenance.
La deuxième option demande du développement mais évite le piège le plus courant : la dérive entre le balisage et le contenu visible. Un script de vérification qui compare reviewCount au nombre d'avis en base, exécuté une fois par semaine, m'a évité plusieurs dérapages.
Les erreurs que je vois le plus souvent (et que j'ai commises)
Un inventaire honnête, parce que je les ai toutes faites au moins une fois :
- Note hors échelle : ratingValue à 8 sur une échelle par défaut de 5. Google rejette silencieusement.
- Date figée : datePublished en dur dans le template, jamais mise à jour. Google finit par considérer le balisage comme peu fiable.
- Auteur générique : « Client satisfait » comme nom d'auteur. Ça passe techniquement, ça ne passe pas la relecture de qualité.
- AggregateRating posé sur une page qui affiche 3 avis mais déclare reviewCount: 240. Le pire.
- Balisage de FAQ obsolète recopié d'un ancien article, alors que les résultats enrichis FAQ ne sont plus affichés pour la plupart des sites.
- JSON-LD dupliqué : deux blocs sur la même page, l'un issu du plugin, l'autre écrit à la main, se contredisant.
La dernière erreur est celle qui m'a le plus embarrassé. Un plugin activait un balisage, un développeur en avait ajouté un autre manuellement trois mois plus tôt. Google lisait le premier des deux, qui contenait des données périmées. Trois semaines à chercher la cause, une ligne à corriger.
Faut-il encore investir sur les avis balisés en 2026 ?
La question m'est posée de plus en plus souvent, parce que Google a considérablement réduit la place des résultats enrichis dans les pages de résultats — moins de FAQ, moins de HowTo, davantage de réponses générées. Sur les avis, pourtant, les étoiles tiennent bon, et les recherches à intention commerciale continuent de les afficher massivement. Mon avis, tranché : oui, mais uniquement si le balisage est propre. Un balisage approximatif fait plus de mal que pas de balisage du tout, parce qu'il consomme votre budget de confiance auprès du moteur sans rien vous rendre.
Ce qui reste vrai, c'est que les étoiles ne remplacent pas un produit correct. J'ai vu des sites récupérer des étoiles et perdre du trafic quand même, parce que la page d'arrivée décevait. Le balisage fait entrer. Le contenu fait rester. Et je ne connais pas de cas où c'est l'inverse qui s'est produit.
