Guide : schéma AggregateRating

TL;DR — AggregateRating est un code ajouté à une page pour dire « la note moyenne de cet élément est de 4,6 étoiles, sur ce nombre d’évaluations ». C’est ce qui alimente l’extrait enrichi en étoiles visible sous certains résultats de recherche. La plupart du temps, vous l’imbriquez dans le balisage de ce qui est évalué (produit, recette, entreprise) ; Google accepte aussi une forme autonome qui nomme directement l’élément évalué, mais l’imbrication reste le modèle courant. Vous ne pouvez pas noter votre propre entreprise et attendre des étoiles : Google bloque ce cas.

Qu’est-ce que le schéma AggregateRating ?

Lorsqu’une page affiche quelque chose comme « 4,6 ★ (218 évaluations) », un humain le comprend d’un regard. Un moteur de recherche voit du texte simple et doit deviner ce que signifient les nombres. AggregateRating l’explicite dans le code avec le vocabulaire partagé de schema.org : il décrit la moyenne, le nombre d’évaluations qui la compose et l’échelle.

Le mot important est aggregate : c’est la moyenne de nombreuses évaluations. Cela diffère du schéma Review, qui décrit l’opinion écrite d’une personne. Les pages qui utilisent les deux les associent généralement : un AggregateRating pour la moyenne globale et quelques Reviews individuelles.

Le balisage est presque toujours écrit en JSON-LD — un petit bloc de code placé dans la page sans modifier son apparence.

Pourquoi le faire ?

Le bénéfice est l’extrait enrichi avec étoiles : des étoiles dorées et un nombre d’évaluations sous un résultat de recherche. Une fiche étoilée se distingue et peut obtenir davantage de clics. Google a besoin de quelques éléments :

• ratingValue — la note moyenne, par exemple 4.6.
• au moins un compteur — ratingCount (toutes les évaluations) ou reviewCount (les personnes ayant laissé un avis, avec ou sans note). Il en faut un.
• itemReviewed — l’élément évalué. Si AggregateRating est imbriqué dans le produit, la recette, etc., l’imbrication le couvre et vous pouvez l’omettre ; dans tous les cas, l’élément évalué doit avoir un nom. Evidence for this claim Google supports aggregate ratings in review snippets only for eligible item types and qualifying content. Scope: Google Search review snippet requirements; stars are not guaranteed. Confidence: high · Verified: 2026-07-14 Google: Review snippet structured data

Facultativement, bestRating et worstRating décrivent l’échelle (Google suppose 1–5 si vous les omettez).

L’erreur la plus fréquente

Vous ne pouvez pas ajouter AggregateRating à votre propre entreprise pour obtenir des étoiles. Si vous gérez une entreprise locale ou un site de société et marquez « nos clients nous donnent 4,9 étoiles », Google n’affichera pas ces étoiles. Il parle d’un cas auto-promotionnel — une entreprise qui s’évalue elle-même — et le bloque spécifiquement pour les balisages LocalBusiness et Organization.

Mais — et c’est ce qui piège tout le monde — ce n’est pas une règle générale qui interdirait de noter ses propres contenus. Une boutique en ligne peut légitimement afficher des étoiles sur ses pages de produits. Le blocage vise une entreprise qui s’évalue en tant qu’entreprise, pas un magasin qui montre les évaluations authentiques de ses produits.

Deux autres pièges pour débuter :

• Il faut toujours un compteur, pas seulement une moyenne. Un simple « 4,6 étoiles » sans nombre d’évaluations sous-jacent ne suffit pas.
• Les évaluations doivent être réelles. Fabriquer ou acheter des notes ne viole pas seulement les règles : cela peut provoquer une action manuelle qui retire les extraits enrichis.

Vous voulez les propriétés obligatoires exactes, la distinction ratingCount/reviewCount, le périmètre complet des avis auto-promotionnels et la correction des erreurs Search Console courantes ? Passez à l’onglet Avancé.

TL;DR — AggregateRating est généralement imbriqué dans la propriété aggregateRating d’un type parent (Product, LocalBusiness, Recipe, Book, Course, Event, Movie, SoftwareApplication et d’autres), ce qui explique que les exemples imbriqués omettent itemReviewed — mais la spécification de Google accepte aussi un AggregateRating non imbriqué qui nomme directement itemReviewed. Dans tous les cas, l’élément évalué doit avoir un nom. Pour l’extrait enrichi d’étoiles, Google exige ratingValue, au moins un de ratingCount/reviewCount et itemReviewed lorsqu’il n’est pas imbriqué ; bestRating/worstRating sont recommandés, notamment pour les échelles qui ne vont pas de 1 à 5. La règle d’éligibilité à retenir est précise : les évaluations auto-promotionnelles sont exclues de la fonction étoiles spécifiquement sur LocalBusiness/Organization — une entreprise qui s’évalue elle-même — tandis que Product, Recipe, Movie et la plupart des autres types pris en charge restent éligibles aux évaluations authentiques. ratingCount (toutes les notes, y compris celles sans avis) et reviewCount (les personnes ayant laissé un avis, avec ou sans note) sont différents. Un balisage valide donne une éligibilité aux étoiles, pas un meilleur classement ; des évaluations fabriquées peuvent déclencher une action manuelle de données structurées. Ce sujet est associé aux données structurées et au SEO e-commerce, car le balisage des notes revient souvent dans les audits.

AggregateRating contre Review — la distinction décisive

La plupart des guides concurrents mélangent ces deux types dans une seule liste de conditions. Ils sont distincts :

• Review décrit l’opinion d’un évaluateur sur un élément — une personne, un reviewRating et un texte d’avis.
• AggregateRating décrit la moyenne statistique de nombreuses évaluations — ratingValue accompagné d’un compteur.

De nombreuses implémentations réelles utilisent les deux dans le même type parent : un aggregateRating pour la note globale et un tableau d’objets review pour les opinions individuelles. Les recommandations de Google vont dans un seul sens : si vous marquez déjà plusieurs avis individuels, ajoutez une note agrégée à côté. Cela ne signifie pas qu’un AggregateRating seul doit être accompagné d’objets Review inventés — une page qui ne comporte qu’un agrégat est une implémentation complète normale. Retenez ceci : Review = une opinion ; AggregateRating = la moyenne de nombreuses opinions. Pour le cas d’un seul évaluateur, consultez l’article voisin sur le schéma Review.

Imbriqué ou autonome — deux façons valides de l’attacher

AggregateRating n’a pas de sens indépendant sur une page, mais ce n’est pas strictement « imbriquez-le ou rien ». Google accepte deux formes :

• Imbriquée (modèle courant) — AggregateRating se trouve dans la propriété aggregateRating d’un autre type (Product, LocalBusiness, Recipe et le reste de la liste prise en charge). Comme le type parent identifie déjà l’élément, un AggregateRating imbriqué omet itemReviewed — mais l’élément parent doit toujours posséder un name.
• Non imbriquée — AggregateRating peut aussi se présenter seul, à condition de fournir itemReviewed pour nommer l’élément évalué. C’est moins courant, mais c’est une voie documentée et valide, pas un contournement.

Dans les deux formes, le nom de l’élément évalué doit apparaître quelque part — sur le parent lorsqu’il est imbriqué, dans itemReviewed lorsqu’il ne l’est pas. Les types hôtes pris en charge par Google pour l’extrait enrichi d’avis/étoiles forment une liste finie : Book, Course, Event, LocalBusiness, Movie, Product, Recipe, Software App, plus des types d’imbrication supplémentaires (CreativeWorkSeason, CreativeWorkSeries, Episode, Game, MediaObject, MusicPlaylist, MusicRecording et Organization).

La conséquence pratique est nette : placer aggregateRating sur un type non pris en charge n’affichera pas d’étoiles même si le balisage est validé proprement. Validation et éligibilité aux résultats enrichis sont deux barrières différentes.

Propriétés obligatoires et recommandées

Voici la spécification de Google, plus stricte que schema.org seul, pour l’extrait enrichi d’étoiles. La ligne itemReviewed dépend de la forme utilisée :

Deux règles de formatage issues des notes d’utilisation de schema.org provoquent des échecs de validation évitables : utilisez de vrais chiffres (0–9), pas des symboles Unicode ressemblants, et utilisez un point comme séparateur décimal, pas une virgule. "4,6" est une erreur courante dans les langues qui utilisent la virgule décimale.

ratingCount contre reviewCount — une vraie distinction

De nombreux guides les utilisent comme des synonymes ou réduisent reviewCount aux seuls « avis écrits ». Les définitions actuelles de Google sont plus précises :

• ratingCount — nombre total d’évaluations, y compris les notes seules sans texte d’avis.
• reviewCount — nombre de personnes ayant fourni un avis, avec ou sans note associée. Il ne signifie pas strictement « avis écrits » : il compte les personnes qui ont évalué, qu’elles aient ou non aussi laissé une note numérique.

En pratique, sur la plupart des plateformes, ces chiffres restent différents, car toute personne qui laisse une note n’écrit pas un avis et toute personne qui écrit un avis n’ajoute pas nécessairement une étoile. Un magasin peut afficher 4,6 étoiles provenant de ratingCount égal à 1 200, dont 340 personnes (reviewCount) ont effectivement laissé un texte. Appliquez ces définitions à la manière dont votre plateforme sépare « noté » et « évalué » plutôt que de supposer que l’exemple correspond exactement à son découpage. Google exige au moins une des deux propriétés ; fournissez celle qui correspond à ce que votre plateforme suit réellement et ne gonflez pas un chiffre que la page ne peut justifier.

bestRating / worstRating — incluez-les hors de l’échelle par défaut

Google suppose une échelle de 1 à 5 lorsque ces propriétés sont absentes. Si vous notez sur 1–10, sur 100 ou selon une autre plage, vous devez définir bestRating/worstRating, sinon Google peut mal interpréter l’échelle — un 9.2 sur une échelle de 10, laissé sans précision, sera lu comme 9,2 sur 5, ce qui n’a aucun sens.

La règle des avis auto-promotionnels — périmètre précis

C’est le point le plus déformé du sujet, alors formulons-le exactement.

Voici la formulation de Google : “If the entity that’s being reviewed controls the reviews about itself, their pages that use LocalBusiness or any other type of Organization structured data are ineligible for star review feature.” (traduction) « Si l’entité évaluée contrôle les avis qui la concernent, ses pages utilisant LocalBusiness ou tout autre type de données structurées Organization ne peuvent pas bénéficier de la fonction d’avis avec étoiles. » Lisez bien le périmètre : il nomme LocalBusiness et Organization (ainsi que leurs sous-types). Il s’agit d’une entreprise qui s’évalue elle-même en tant qu’entreprise. Evidence for this claim Google requires ratings represented in structured data to be visible to users and prohibits misleading or fabricated review markup. Scope: Google Search structured-data and review snippet policies; violations can remove feature eligibility. Confidence: high · Verified: 2026-07-14 Google: Review snippet structured data

La règle ne s’applique pas à Product. Une boutique en ligne peut légitimement afficher des étoiles sur ses propres pages de produits : il s’agit de la moyenne d’évaluations authentiques de clients sur un produit qu’elle vend, pas de l’entreprise qui s’évalue elle-même. Recipe, Movie, Book, SoftwareApplication et le reste de la liste prise en charge restent également éligibles, à condition que les évaluations soient authentiques.

Cette règle vient d’une modification de politique Google de septembre 2019 (« Making Review Rich Results more helpful »), qui a introduit le cadrage « auto-promotionnel », y compris pour les avis de votre propre entreprise intégrés directement ou récupérés par un widget tiers. (Je paraphrase le raisonnement de cette annonce plutôt que de la citer ; la formulation actuelle et citable est celle de la documentation des extraits d’avis citée plus haut.) En bref : un widget tiers sur votre page LocalBusiness/Organization reste auto-promotionnel et ne peut toujours pas obtenir les étoiles.

Organization explique pourquoi l’article voisin sur le schéma Organization est pertinent : c’est l’un des deux types hôtes où les notes hébergées par l’entreprise ne rapportent pas d’étoiles.

Des évaluations authentiques uniquement — spam et actions manuelles

Deux règles simples de la documentation Google :

• N’agrégez pas des avis provenant d’autres sites. Google dit : “Don’t aggregate reviews or ratings from other websites.” (traduction) « N’agrégez pas les avis ou les évaluations provenant d’autres sites. » Récupérer des notes ailleurs pour les injecter dans votre propre balisage est interdit.
• Les évaluations doivent venir de vrais utilisateurs. Les politiques de données structurées de Google présentent les évaluations authentiques comme une exigence, pas comme une intention ; son exemple consacré aux recettes note que “reviews or ratings not by actual users may result in manual action.” (traduction) « des avis ou évaluations qui ne viennent pas d’utilisateurs réels peuvent entraîner une action manuelle ». Le principe se généralise à la politique des avis pour les autres types.

Une action manuelle pour des notes trompeuses ou fabriquées retire l’éligibilité de la page aux résultats enrichis. C’est une mesure appliquée, pas une hypothèse. Le contenu de l’avis doit aussi être réellement présent sur la page : Google attend que les notes marquées soient facilement accessibles aux utilisateurs sur la même page, à propos d’un élément précis, pas d’une catégorie ou d’une liste.

La place d’AggregateRating dans le paysage

Comme toutes les données structurées, AggregateRating influe sur l’éligibilité aux résultats enrichis, pas sur le classement — les hubs Schema Markup et Structured Data développent ce point, je ne le reprends donc pas ici. aggregateRating est une propriété recommandée sur Product (le type hôte le plus fréquent) et sur ProductGroup pour les agrégats de notes au niveau des variantes — deux lectures naturelles ensuite. Utilisez JSON-LD : c’est le format recommandé par Google et celui de tous les exemples de cet article.

Bing et les autres moteurs : schema.org est un vocabulaire commun à Google, Microsoft, Yahoo et Yandex, et la documentation générale de Bing sur les données structurées confirme qu’il lit le balisage schema.org/JSON-LD. Ce qui n’est pas vérifiable actuellement dans la documentation Microsoft de première partie, c’est une parité spécifique à AggregateRating avec les exigences de Google : Bing ne publie ni tableau comparable des propriétés obligatoires/recommandées par type, ni politique documentée sur les avis auto-promotionnels comme Google, et sa surface de résultats enrichis pour les notes est plus restreinte et moins documentée. Ne supposez pas que les règles d’éligibilité de Bing reproduisent celles de Google ; traitez la question comme ouverte jusqu’à la publication de conseils spécifiques par Bing.

Résumé par IA

Une synthèse de la version Avancé :

• Ce que c’est : le balisage schema.org/AggregateRating (généralement JSON-LD) qui décrit la moyenne de nombreuses notes/évaluations d’un élément, contrairement à Review, qui décrit l’opinion d’une personne. De nombreuses pages utilisent les deux ; Google demande un agrégat quand plusieurs avis individuels sont déjà balisés, pas l’inverse.
• Imbriqué ou autonome : AggregateRating est généralement imbriqué dans la propriété aggregateRating d’un type parent (Product, LocalBusiness, Recipe, Book, Course, Event, Movie, SoftwareApplication et d’autres), ce qui permet aux exemples imbriqués d’omettre itemReviewed ; Google accepte aussi un AggregateRating autonome qui nomme directement itemReviewed. Dans les deux cas, l’élément évalué doit avoir un nom.
• Obligatoire pour l’extrait étoilé : ratingValue, au moins un de ratingCount/reviewCount et itemReviewed lorsqu’il n’est pas imbriqué. Recommandé : bestRating/worstRating, essentiels hors de l’échelle par défaut 1–5.
• ratingCount contre reviewCount : ratingCount = toutes les notes, y compris les notes seules ; reviewCount = personnes ayant laissé un avis, avec ou sans note. Ce sont des nombres différents ; il en faut un.
• Règle auto-promotionnelle, avec son périmètre précis : les notes auto-promotionnelles sont exclues de la fonction étoiles uniquement sur LocalBusiness/Organization — une entreprise qui s’évalue elle-même — depuis septembre 2019. Product, Recipe, Movie, etc. restent éligibles aux évaluations authentiques. Un widget tiers affichant les avis de votre entreprise reste auto-promotionnel.
• Les types hôtes pris en charge sont limités : Book, Course, Event, LocalBusiness, Movie, Product, Recipe, Software App et plusieurs types d’imbrication supplémentaires. Sur un type non pris en charge, les étoiles ne s’afficheront pas même si le balisage est validé.
• Évaluations authentiques uniquement : “Don’t aggregate reviews or ratings from other websites.” (traduction) « N’agrégez pas les avis ou évaluations provenant d’autres sites » ; des notes fabriquées ou incitées peuvent provoquer une action manuelle de données structurées qui retire l’éligibilité aux résultats enrichis.
• Formatage : vrais chiffres (0–9), point comme séparateur décimal et non virgule.
• Éligibilité ≠ classement : un balisage valide rend seulement la page éligible aux étoiles ; ce n’est pas un facteur de classement. Bing utilise le même vocabulaire, mais ne publie pas de documentation comparable sur l’éligibilité.

Documentation officielle

Documentation de première source pour AggregateRating.

schema.org (le vocabulaire)

• Type AggregateRating — définition de référence, liste des propriétés (itemReviewed, ratingCount, reviewCount, ratingValue/bestRating/worstRating hérités) et notes d’usage sur les chiffres et le séparateur décimal.

Google — éligibilité et exigences

• Extrait d’avis (données structurées Review et AggregateRating) — spécification de référence : propriétés obligatoires, liste des types hôtes pris en charge, périmètre des avis auto-promotionnels (LocalBusiness/Organization) et règle « ne pas agréger depuis d’autres sites ».
• Consignes générales sur les données structurées — politiques anti-spam, formulation sur les actions manuelles et exigence d’évaluations authentiques.
• Rendre les résultats enrichis d’avis plus utiles (septembre 2019) — origine de la politique sur les avis auto-promotionnels, citée pour le contexte de la date et de la raison du changement.
• Test des résultats enrichis — valider le balisage et vérifier l’éligibilité aux étoiles.

Bing / Microsoft

• Balisage des sites avec les données structurées — prise en charge générale de schema.org et JSON-LD par Bing.

Citations de la source

Déclarations publiques de schema.org et de Google. Lorsqu’une page source expose le texte, le lien profond mène directement au passage cité.

schema.org — définition du type

• “The average rating based on multiple ratings or reviews.” (traduction) « La note moyenne fondée sur plusieurs évaluations ou avis. » Accéder à la citation

Documentation Google — marquer un agrégat

• “Make sure to mark up an aggregate evaluation of an item by many people with schema.org/AggregateRating.” (traduction) « Veillez à baliser avec schema.org/AggregateRating l’évaluation agrégée d’un élément par de nombreuses personnes. » Accéder à la citation

Documentation Google — règle des avis auto-promotionnels (LocalBusiness/Organization)

• “If the entity that’s being reviewed controls the reviews about itself, their pages that use LocalBusiness or any other type of Organization structured data are ineligible for star review feature.” (traduction) « Si l’entité évaluée contrôle les avis qui la concernent, ses pages utilisant LocalBusiness ou tout autre type de données structurées Organization ne peuvent pas bénéficier de la fonction d’avis avec étoiles. » Accéder à la citation

Documentation Google — ne pas agréger depuis d’autres sites

• “Don’t aggregate reviews or ratings from other websites.” (traduction) « N’agrégez pas les avis ou évaluations provenant d’autres sites. » Accéder à la citation

Politiques Google sur les données structurées (tromperie et action manuelle)

• “Don’t use structured data to deceive or mislead users. Don’t impersonate any person or organization.” (traduction) « N’utilisez pas les données structurées pour tromper ou induire les utilisateurs en erreur. N’usurpez l’identité d’aucune personne ou organisation. » Accéder à la citation
• Pour les évaluations authentiques (exemple propre aux recettes, généralisable à la politique des avis) : “reviews or ratings not by actual users may result in manual action.” (traduction) « des avis ou évaluations qui ne viennent pas d’utilisateurs réels peuvent entraîner une action manuelle ». Consignes générales sur les données structurées

AggregateRating contre Review — lequel choisir ?

Parcourez les questions dans l’ordre :

1. Balisez-vous l’opinion d’une personne ou la moyenne de plusieurs personnes ?

• Une opinion individuelle (une note et un texte d’avis) → choisissez le schéma Review, pas AggregateRating.
• La moyenne de nombreuses évaluations → AggregateRating. Continuez.
• Les deux (une note globale et des opinions individuelles) → utilisez les deux, imbriqués dans le même type parent : un aggregateRating et un tableau d’objets review.

2. L’imbriquez-vous ou le laissez-vous autonome ?

• Imbrication dans Product (ou ProductGroup), Recipe, Movie, Book, Course, Event ou SoftwareApplication → type hôte pris en charge ; les notes authentiques sont normalement éligibles aux étoiles et vous pouvez omettre itemReviewed, car le parent nomme déjà l’élément. Continuez.
• Une note d’elle-même sur LocalBusiness ou Organization → arrêtez-vous. Ces notes auto-promotionnelles sont incompatibles avec la fonction étoiles. N’attendez pas d’étoiles même si le balisage est validé.
• Aucune imbrication → c’est également valable, à condition que AggregateRating fournisse itemReviewed et nomme directement l’élément évalué.
• Un autre type parent absent de la liste Google → le balisage peut être validé, mais les étoiles ne s’afficheront pas : le type hôte n’est pas pris en charge.

3. Les propriétés obligatoires sont-elles présentes ?

• Confirmez ratingValue et au moins un de ratingCount/reviewCount. Sans imbrication, définissez aussi itemReviewed ; dans tous les cas, l’élément évalué doit avoir un nom. L’absence de compteur est l’échec numéro 1.
• Hors échelle 1–5 ? Ajoutez bestRating/worstRating, sinon Google peut mal lire l’échelle.

4. Les évaluations sont-elles authentiques et visibles sur la page ?

• Réelles, fournies par des utilisateurs, à propos de cet élément précis et visibles sur la même page → bon.
• Agrégées depuis d’autres sites, fabriquées ou incitées → non : vous risquez une action manuelle de données structurées, pas seulement un extrait absent.

Règle simple : Review est une opinion ; AggregateRating est la moyenne de nombreuses opinions. Product et les types proches peuvent afficher des étoiles authentiques ; une entreprise ne peut pas s’évaluer elle-même pour en obtenir.

Mythes et erreurs AggregateRating à éviter

Mythe : « Je peux ajouter AggregateRating à mon schéma Organization/LocalBusiness et obtenir des étoiles comme un produit. » Non. Google exclut explicitement les notes auto-promotionnelles sur LocalBusiness/Organization de la fonction d’avis étoilés lorsque l’entité contrôle les avis qui la concernent. C’est ainsi depuis la modification de politique de septembre 2019. Une entreprise qui s’évalue elle-même n’obtient pas d’étoiles ; un magasin qui évalue ses produits le peut encore.

Mythe : « AggregateRating et Review sont la même chose. » Review décrit une opinion ; AggregateRating décrit la moyenne de nombreuses opinions. Les types et les propriétés obligatoires diffèrent. Beaucoup de pages utilisent les deux ensemble, mais ils ne sont pas interchangeables et un agrégat ne vous oblige pas à inventer des objets Review.

Mythe : « J’ai seulement besoin de ratingValue — le compteur n’a pas d’importance. » Google exige au moins un de ratingCount ou reviewCount en plus de ratingValue. Une moyenne seule, sans taille d’échantillon, n’est pas éligible.

Mythe : « ratingCount et reviewCount sont le même nombre. » Ils diffèrent. ratingCount inclut les notes sans avis ; reviewCount compte les personnes qui ont laissé un avis, avec ou sans note. Une page peut avoir 1 200 évaluations mais seulement 340 personnes ayant laissé un avis. Fournissez le compteur réellement suivi par votre plateforme et ne gonflez aucun chiffre.

Mythe : « Un widget d’avis tiers sur ma page d’entreprise suffit automatiquement pour les étoiles. » Si le widget affiche les avis de votre propre entreprise ou organisation — même depuis une plateforme tierce — le cas reste auto-promotionnel et inadmissible pour les étoiles LocalBusiness/Organization.

Mythe : « Des notes cinq étoiles fabriquées ou incitées risquent seulement de ne pas afficher l’extrait. » Google applique l’exigence d’évaluations authentiques : des notes fabriquées peuvent déclencher une action manuelle de données structurées qui retire l’éligibilité aux résultats enrichis, pas seulement masquer l’extrait.

Mythe : « Le schéma AggregateRating améliore le classement. » Comme tous les balisages, il influe sur l’éligibilité aux résultats enrichis, pas sur le classement — il ouvre l’éligibilité aux étoiles, pas une meilleure position. Le hub Structured Data développe ce point.

Erreur : agréger des évaluations venant d’autres sites. Google dit clairement de ne pas le faire. Utilisez seulement les évaluations réellement recueillies par votre page.

Erreur : ratingValue mal formé. Utilisez de vrais chiffres et un point décimal (4.6, pas 4,6 ni un chiffre Unicode ressemblant). Les décimales à virgule sont une cause courante d’échec de validation.

Erreur : aggregateRating sur un type hôte non pris en charge. Une forme autonome avec itemReviewed est valide et l’imbrication dans un type pris en charge est le modèle courant ; dans les deux cas, le type de l’élément doit figurer dans la liste Google. Sur un type non pris en charge, le balisage peut être validé sans afficher d’étoiles.

AggregateRating JSON-LD propre ou défectueux

Un agrégat propre et imbriqué

AggregateRating est correctement imbriqué dans un Product, avec une moyenne, un compteur et une échelle valides — plus un seul review à côté, le modèle courant :

{
  "@context": "https://schema.org/",
  "@type": "Product",
  "name": "Trailhead 30L Hiking Backpack",
  "image": "https://example.com/img/backpack.jpg",
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.6",
    "bestRating": "5",
    "worstRating": "1",
    "ratingCount": "1200",
    "reviewCount": "340"
  },
  "review": [
    {
      "@type": "Review",
      "author": { "@type": "Person", "name": "James Smith" },
      "reviewRating": {
        "@type": "Rating",
        "ratingValue": "5",
        "bestRating": "5"
      },
      "reviewBody": "Comfortable on long days, great ventilation."
    }
  ]
}

Notez que ratingCount (1 200 évaluations au total) et reviewCount (340 personnes ayant laissé un avis) sont différents — comme c’est généralement le cas.

La forme non imbriquée

L’imbrication est le modèle courant, mais AggregateRating ne doit pas forcément se trouver dans un Product (ou un autre hôte). Il peut être autonome, à condition de fournir itemReviewed et de nommer l’élément évalué — forme documentée et valide, pas un contournement :

{
  "@context": "https://schema.org/",
  "@type": "AggregateRating",
  "itemReviewed": {
    "@type": "Product",
    "name": "Trailhead 30L Hiking Backpack"
  },
  "ratingValue": "4.6",
  "bestRating": "5",
  "worstRating": "1",
  "ratingCount": "1200",
  "reviewCount": "340"
}

Même propriétés, mêmes règles d’éligibilité : seule la place de itemReviewed change. Imbriqué, il est implicite via le parent et généralement omis ; autonome, il doit être écrit.

Le même agrégat, défectueux

Chaque ligne signalée ci-dessous correspond à un échec de validation réel et courant :

{
  "@context": "https://schema.org/",
  "@type": "Product",
  "name": "Trailhead 30L Hiking Backpack",
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4,6"
  }
}

Ce qui ne va pas :

• Absence de ratingCount ou reviewCount — produit l’erreur classique « Either ‘ratingCount’ or ‘reviewCount’ should be specified ». Un agrégat a besoin d’une taille d’échantillon.
• ratingValue: "4,6" — séparateur décimal virgule. Utilisez un point : "4.6".
• Absence de bestRating/worstRating — tolérable sur 1–5, mais leur absence hors échelle par défaut conduit Google à mal interpréter l’échelle.

Et l’erreur qui se valide mais n’affiche toujours pas d’étoiles : placer cet aggregateRating exact sur un LocalBusiness ou une Organization qui s’évalue elle-même — le cas est auto-promotionnel et non éligible quelle que soit la propreté du balisage.

Erreurs Search Console / Test des résultats enrichis courantes → corrections

Outils pour construire et vérifier le balisage AggregateRating

Mon Validateur de balisage Schema est le point de départ après l’écriture du JSON-LD. Collez le bloc (ou une page complète) : il exécute des contrôles par niveau de gravité contre le vocabulaire AggregateRating de schema.org et les exigences de Google pour les résultats enrichis. Il détecte l’absence de compteur, l’erreur de décimale à virgule et les problèmes d’échelle bestRating/worstRating, puis renvoie un bloc JSON-LD corrigé et prêt à copier-coller.

Mon vérificateur d’éligibilité aux résultats enrichis répond à une autre question : non pas « ce JSON-LD est-il valide ? », mais « cette page précise peut-elle obtenir l’extrait étoilé de Google ? ». Collez du JSON-LD, une page HTML ou une URL en direct ; l’outil affiche, par type, les champs obligatoires (itemReviewed, ratingValue, ratingCount/reviewCount) présents ou absents et les champs recommandés (bestRating, worstRating) omis hors de l’échelle par défaut.

Si vous partez d’une page vide plutôt que de corriger un balisage existant, mon Générateur de balisage Schema propose un formulaire ciblé pour construire aggregateRating dans Product (ou un autre type hôte pris en charge) sans écrire le JSON-LD à la main. Il indique pour chaque propriété si elle est obligatoire pour Google, recommandée par Google ou seulement définie par schema.org.

Une fois ces deux contrôles réussis, passez la page dans le Test des résultats enrichis de Google — c’est l’outil réellement utilisé par Google pour décider l’éligibilité, donc le dernier mot avant publication.

Problèmes AggregateRating courants et corrections

Le balisage est valide, mais aucune étoile n’apparaît dans les résultats

La cause la plus probable est la règle des avis auto-promotionnels : aggregateRating est imbriqué dans LocalBusiness ou Organization, et l’entreprise s’évalue elle-même. Google exclut entièrement ce couple de la fonction étoiles, quelle que soit la propreté du JSON-LD. Vérifiez d’abord le type parent — s’il s’agit de LocalBusiness ou Organization, déplacez la discussion vers de véritables avis au niveau des produits, car une entreprise ne peut pas gagner des étoiles en se notant elle-même alors qu’un magasin peut noter ses produits. La deuxième cause probable est un type hôte non pris en charge — aggregateRating imbriqué dans un type absent de la liste Google (Book, Course, Event, LocalBusiness, Movie, Product, Recipe, SoftwareApplication et la courte liste complémentaire) sera validé mais n’affichera jamais d’étoiles.

Le Test des résultats enrichis ou Search Console signale « Either ‘ratingCount’ or ‘reviewCount’ should be specified »

L’objet aggregateRating ne contient pas de propriété de taille d’échantillon. ratingValue seul ne suffit pas : Google demande au moins un de ratingCount ou reviewCount. Ajoutez celui qui correspond à ce que votre plateforme suit réellement (toutes les notes, y compris les notes seules, ou les personnes ayant laissé un avis), puis testez à nouveau.

ratingValue échoue alors que le nombre semble correct

Cherchez un séparateur décimal virgule ("4,6" au lieu de "4.6") ou un chiffre Unicode ressemblant à un vrai chiffre 0–9. Ce sont des causes courantes dans les langues qui formatent les décimales avec une virgule et des erreurs difficiles à voir jusqu’à ce qu’un validateur les signale.

Erreur : “The best rating value must be greater than the worst rating value” (traduction) « La valeur maximale de la note doit être supérieure à la valeur minimale »

bestRating et worstRating sont inversés, ou worstRating manque alors que l’échelle réelle ne correspond pas au défaut Google 1–5 (une note sur 1–10 ou sur 100 laissée sans précision est lue contre l’échelle 1–5). Définissez explicitement les deux, par exemple worstRating: 1, bestRating: 5, dès que votre échelle n’est pas la valeur par défaut.

Search Console indique des éléments valides, mais les étoiles n’apparaissent pas dans la SERP

Une validation réussie et un statut « valide » dans Search Console signifient seulement que la page peut obtenir l’extrait enrichi d’étoiles ; Google ne garantit pas son affichage. C’est attendu, pas un bug à corriger : l’éligibilité concerne le résultat enrichi, pas une promesse d’affichage ou de classement. Si le balisage est réellement valide et éligible, il n’y a rien d’autre à corriger côté markup.

Les résultats enrichis disparaissent après avoir été affichés

Une action manuelle pour des évaluations fabriquées ou agrégées depuis ailleurs retire l’éligibilité aux résultats enrichis. Vérifiez d’abord le rapport Actions manuelles de Search Console. En l’absence d’action manuelle, revalidez le balisage actuel : une modification de template ou de CMS peut casser silencieusement une propriété (compteur absent, échelle réécrite) qui était correcte.

Prouver que votre modification AggregateRating fonctionne

Test 1 : syntaxe JSON-LD et propriétés obligatoires

Test à exécuter : collez le JSON-LD mis à jour dans mon Validateur de balisage Schema ou passez la page en direct dans le Test des résultats enrichis de Google. Résultat attendu : aucune erreur sur le bloc AggregateRating — ratingValue présent avec un chiffre réel et un point décimal, et au moins l’un de ratingCount ou reviewCount présent. Interprétation d’un échec : une propriété manquante signifie réellement qu’elle n’est pas dans le JSON-LD publié, pas qu’il s’agit d’un problème de cache ou de rendu ; revérifiez la source JSON-LD. Fenêtre de surveillance : immédiate — les deux outils lisent directement le balisage, sans délai d’exploration. Déclencheur de retour arrière : la validation échoue encore après une correction directe — annulez la modification du template et comparez avec le dernier JSON-LD connu comme bon.

Test 2 : éligibilité du type hôte précis

Test à exécuter : mon vérificateur d’éligibilité aux résultats enrichis sur l’URL en direct. Résultat attendu : le type parent de la page (par exemple Product) apparaît éligible à l’extrait enrichi d’avis/étoiles, avec itemReviewed correctement résolu. Interprétation d’un échec : si le parent est LocalBusiness ou Organization, « non éligible » est le comportement attendu (règle auto-promotionnelle), pas un bug ; confirmez le type hôte avant de traiter cela comme un échec. Fenêtre de surveillance : immédiate. Déclencheur de retour arrière : une page d’un type éligible (Product, Recipe, etc.) signale encore des champs obligatoires absents après la correction — le déploiement n’a pas actualisé le balisage vu par Google ; vérifiez cache et étape de build.

Test 3 : rapport d’amélioration Search Console

Test à exécuter : Search Console → rapport d’amélioration concerné (extraits produit / fiches marchands, selon le type hôte) pour les URL touchées. Résultat attendu : la page passe de « invalide » ou « non éligible » à « valide » et le nombre d’erreurs de cette URL tombe à zéro. Interprétation d’un échec : un signalement qui persiste après la nouvelle exploration signifie que la correction n’est pas en ligne ou qu’une autre propriété obligatoire manque ; relancez le test 1 sur l’URL en direct, pas sur une copie de staging. Fenêtre de surveillance : de quelques jours à environ une semaine pour que Google explore à nouveau la page et actualise le rapport — les données Search Console ont un retard. Déclencheur de retour arrière : le nombre d’éléments invalides augmente après une mise à jour du template au lieu de baisser — la modification a pu casser le balisage d’autres pages ; interrompez le déploiement.

Test 4 : l’extrait étoilé apparaît réellement dans la SERP

Test à exécuter : recherche manuelle d’une requête où la page se classe, en vérifiant si les étoiles apparaissent sous le résultat (une fenêtre privée/incognito évite le biais de personnalisation). Résultat attendu : étoiles et nombre d’évaluations sous le résultat. Interprétation d’un échec : l’absence avec un statut Search Console « valide » n’est pas un problème à corriger — l’affichage relève du choix de Google et n’est pas garanti par l’éligibilité. Une absence combinée à « non éligible » ou à une action manuelle renvoie au test 1 ou 3. Fenêtre de surveillance : Google ne donne aucun délai fixe ; vérifiez au fil des semaines plutôt que d’attendre un affichage immédiat après la validation. Déclencheur de retour arrière : aucun côté balisage — il n’y a rien à annuler pour une décision d’affichage contrôlée par Google. Revenez en arrière seulement si les Actions manuelles signalent la page.

KPI continus pour le balisage AggregateRating

Métrique : nombre d’éléments valides (rapport d’amélioration Search Console) Ce que cela indique : le nombre de pages éligibles qui possèdent actuellement un balisage AggregateRating sans erreur — la couverture du KPI. Comment l’obtenir : Search Console → Améliorations → rapport concerné (extraits produit / fiches marchands) pour votre site. Référence réaliste : aucune cible universelle — établissez votre base à partir du nombre de pages qui devraient porter le balisage (total de pages aux types éligibles) et suivez les éléments valides vers ce nombre. Cadence : mensuelle, ou immédiatement après une modification de template/CMS touchant le balisage des avis.

Métrique : nombre d’éléments invalides/en erreur (même rapport) Ce que cela indique : le nombre de pages dont les propriétés obligatoires sont cassées — qualité du KPI, séparée de la couverture. Comment l’obtenir : même rapport d’amélioration, compartiment des erreurs/éléments invalides. Référence réaliste : la seule cible honnête est zéro ; tout nombre non nul correspond à une page réellement cassée, pas à du bruit statistique. Cadence : mensuelle et après tout déploiement qui touche le template de balisage.

Métrique : évolution du CTR sur les pages devenues éligibles aux étoiles Ce que cela indique : si l’extrait étoilé produit réellement plus de clics sur les pages qui l’affichent, par rapport à la seule éligibilité. Comment l’obtenir : rapport Performances de Search Console, filtré sur les pages touchées, en comparant le CTR des semaines avant et après la mise en ligne du balisage (Search Console n’isole pas proprement les clics provenant spécifiquement d’un extrait étoilé ; c’est donc un proxy avant/après, pas une attribution exacte). Référence réaliste : aucun gain fixe défendable — établissez le CTR de référence des mêmes pages et suivez l’écart, car il dépend fortement de la requête, de la position et des résultats enrichis des concurrents. Cadence : mensuelle pendant le premier trimestre après le déploiement, puis trimestrielle.

Métrique : croissance de ratingCount/reviewCount dans le temps Ce que cela indique : si la taille de l’échantillon derrière la moyenne augmente réellement — un compteur stable ou en baisse sur une page qui revendique une base d’avis active mérite une enquête avant de recevoir le balisage. Comment l’obtenir : votre plateforme d’avis, CMS ou base de données, c’est-à-dire le système de vérité dont le balisage reprend les données. Référence réaliste : suivez la croissance brute par rapport à votre historique ; il n’existe pas de référence externe sur le nombre d’évaluations qu’une page devrait posséder. Cadence : mensuelle.

Testez vos connaissances : schéma AggregateRating

Cinq questions rapides sur schema.org/AggregateRating, ses propriétés obligatoires et la règle des avis auto-promotionnels. Choisissez une réponse à chaque fois, puis vérifiez.

Journal des modifications