Les étoiles affichées dans les résultats de recherche Google attirent immédiatement le regard. Elles peuvent améliorer la visibilité d’un résultat, renforcer sa crédibilité et, dans certains cas, favoriser son taux de clics. Leur présence repose souvent sur des données structurées de type Review ou AggregateRating, généralement intégrées au format JSON-LD. Une confusion demeure toutefois fréquente chez les éditeurs de sites et même chez certains professionnels du référencement naturel : un balisage valide selon Schema.org ne garantit pas nécessairement l’apparition des étoiles dans Google. Il faut en réalité distinguer trois niveaux différents : la validité sémantique du code, son éligibilité aux résultats enrichis de Google et la décision finale du moteur d’afficher ou non ces éléments dans les pages de résultats. Cette distinction est particulièrement intéressante dans le cas des types SoftwareApplication, MobileApplication et WebApplication. Une application web peut parfaitement comporter une note globale dans son balisage et obtenir des étoiles dans Google, mais seulement lorsque plusieurs conditions techniques et éditoriales sont réunies.

Un balisage Schema.org valide ne garantit pas un résultat enrichi

Schema.org propose un vocabulaire commun permettant de décrire de manière structurée les contenus d’une page web. Une entreprise peut ainsi signaler qu’une page concerne un produit, une recette, un événement, un logiciel ou encore une application web. Dans le cas d’une application accessible depuis un navigateur, le type WebApplication peut être utilisé. Ce type est lui-même un sous-type de SoftwareApplication. Il hérite donc des propriétés prévues pour les applications logicielles, notamment applicationCategory, operatingSystem, offers, review et aggregateRating. Le code suivant peut donc être parfaitement valide du point de vue de Schema.org :

{
  "@context": "https://schema.org",
  "@type": "WebApplication",
  "name": "Nom de l'application",
  "applicationCategory": "SportsApplication",
  "operatingSystem": "Web",
  "offers": {
    "@type": "Offer",
    "price": "0",
    "priceCurrency": "EUR"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "5",
    "bestRating": "5",
    "worstRating": "1",
    "ratingCount": "136"
  }
}

Dans cet exemple, l’application est présentée comme un service web gratuit appartenant à la catégorie des applications sportives. Elle possède, selon le balisage, une note moyenne de 5 sur 5 calculée à partir de 136 évaluations. La structure est cohérente et les propriétés sont correctement imbriquées. Cela signifie que le code peut être compris par les outils prenant en charge le vocabulaire Schema.org. Cette validité ne permet cependant pas de conclure automatiquement que Google affichera les étoiles. Schema.org définit un vocabulaire, tandis que Google choisit les données structurées qu’il utilise dans ses propres résultats. Un type ou une propriété peut donc exister dans Schema.org sans nécessairement déclencher une fonctionnalité particulière dans Google Search.

Google prend-il encore en charge WebApplication et AggregateRating ?

Contrairement à une idée répandue, les applications logicielles restent officiellement prises en charge par Google pour les résultats enrichis. La documentation de Google Search Central cite encore le type SoftwareApplication parmi les éléments pouvant bénéficier d’un extrait d’avis. Google précise également que les sous-types MobileApplication et WebApplication sont pris en charge. Une application web n’est donc pas exclue par principe de l’affichage des étoiles. Pour être éligible au résultat enrichi consacré aux applications logicielles, le balisage doit notamment comporter :

• le nom de l’application avec la propriété name ;
• une offre et son prix avec offers.price, y compris lorsque l’application est gratuite ;
• une note globale avec aggregateRating ou un avis individuel avec review.

Google recommande aussi de préciser la catégorie de l’application et son système d’exploitation. Pour une application entièrement utilisable dans un navigateur, une valeur comme Web peut être employée pour operatingSystem. La liste des catégories prises en charge comprend notamment :

• BusinessApplication ;
• EducationalApplication ;
• FinanceApplication ;
• GameApplication ;
• HealthApplication ;
• ShoppingApplication ;
• SportsApplication ;
• TravelApplication ;
• UtilitiesApplication.

L’utilisation de WebApplication avec une propriété aggregateRating peut donc être à la fois valide selon Schema.org et compatible avec les fonctionnalités officiellement documentées par Google. La nuance essentielle est ailleurs : être compatible ou éligible ne signifie toujours pas que le résultat enrichi sera affiché.

Pourquoi Google ne garantit jamais l’affichage des étoiles

Google indique clairement qu’un balisage correctement implémenté ne garantit pas l’apparition d’un résultat enrichi. Même lorsqu’une page réussit le test des résultats enrichis sans erreur critique, le moteur conserve la décision finale. Plusieurs niveaux peuvent ainsi être distingués :

1. Le balisage est syntaxiquement valide : le JSON-LD ne contient pas d’erreur de structure.
2. Le vocabulaire est sémantiquement cohérent : les types et les propriétés sont autorisés par Schema.org.
3. Le contenu est éligible selon la documentation Google : le type utilisé fait partie des fonctionnalités prises en charge et toutes les propriétés obligatoires sont présentes.
4. Google décide d’afficher le résultat enrichi : cette dernière étape dépend de ses systèmes algorithmiques, de la requête et de la confiance accordée au contenu.

Une page peut donc franchir les trois premières étapes sans obtenir d’étoiles dans les SERP. À l’inverse, un résultat enrichi peut apparaître pendant plusieurs mois puis disparaître sans modification apparente du code. Google peut notamment tenir compte de la qualité générale de la page, de la cohérence entre les données structurées et le contenu visible, de la nature de la requête, de l’appareil utilisé, de la langue, de la localisation de l’internaute ou encore de ses propres expérimentations d’affichage. Le test des résultats enrichis permet de vérifier la compréhension technique du balisage et son éligibilité potentielle. Il ne constitue pas une promesse d’affichage.

Les avis et la note globale doivent être visibles sur la page

L’un des principes les plus importants concerne la correspondance entre le balisage et le contenu réellement présenté aux internautes. Une donnée déclarée dans le JSON-LD ne doit pas être invisible ou déconnectée du contenu de la page. Lorsqu’une application déclare une note moyenne de 5 sur 5 fondée sur 136 évaluations, l’utilisateur doit pouvoir retrouver clairement cette information sur la page. Il ne suffit pas de placer le nombre dans un script invisible destiné aux moteurs de recherche. La page devrait par exemple afficher une zone de ce type :

Note des utilisateurs : 5/5 sur la base de 136 évaluations.

Dans une mise en œuvre plus robuste, les visiteurs devraient également pouvoir comprendre l’origine de la note et accéder aux avis qui la composent. Google recommande notamment que les évaluations soient accompagnées, lorsque cela est possible, d’un commentaire et du nom de leur auteur. Pour une note globale, les données suivantes doivent être cohérentes :

• ratingValue correspond à la moyenne réellement calculée ;
• ratingCount correspond au nombre total de notes attribuées sur le site ;
• reviewCount, lorsqu’il est utilisé, correspond au nombre d’avis comportant ou non une note ;
• bestRating et worstRating décrivent correctement l’échelle employée.

Il convient de ne pas confondre ratingCount et reviewCount. Une personne peut attribuer une note sans rédiger de commentaire. Le nombre de notes peut donc être supérieur au nombre d’avis textuels. Google précise également que le nombre déclaré doit correspondre aux évaluations de l’élément présentées sur le site. Copier le nombre d’avis d’une plateforme externe sans collecte propre constitue une implémentation risquée.

Pourquoi Google peut afficher exactement le nombre déclaré dans le JSON-LD

Lorsqu’un résultat Google affiche précisément « 136 avis » et que le JSON-LD contient la propriété suivante, le rapprochement est généralement direct :

"ratingCount": 136

Google ne calcule pas nécessairement ce nombre à partir d’une fiche Google Business Profile, d’un annuaire ou d’une autre plateforme. Dans le cas d’un résultat enrichi lié à une application logicielle, il peut simplement reprendre la valeur structurée fournie par la page. Le moteur interprète alors les éléments de la manière suivante :

• le type principal désigne une application web ;
• l’application porte un nom identifiable ;
• elle est gratuite ou associée à une offre tarifaire ;
• elle possède une note moyenne ;
• cette moyenne repose sur 136 évaluations.

Ce fonctionnement explique pourquoi le nombre d’avis affiché dans Google peut être identique à la valeur du JSON-LD, même lorsqu’aucune fiche d’établissement locale n’est associée à la page. Il serait toutefois excessif d’en déduire que Google a vérifié individuellement l’existence des 136 évaluations. L’affichage signifie avant tout que ses systèmes ont, à un instant donné, accepté d’utiliser les informations fournies pour construire le résultat enrichi.

Les avis auto-promotionnels concernent surtout Organization et LocalBusiness

Une autre source de confusion vient de la politique de Google relative aux avis dits auto-promotionnels. Depuis 2019, les pages utilisant des données structurées de type Organization ou LocalBusiness ne sont généralement pas éligibles aux étoiles lorsque l’organisation évaluée contrôle elle-même les avis affichés sur son propre site. Cette règle concerne par exemple une agence qui ajouterait sur sa page d’accueil :

{
  "@type": "LocalBusiness",
  "name": "Exemple d'agence",
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.9",
    "ratingCount": "85"
  }
}

Même si les avis proviennent d’un widget tiers, Google peut considérer qu’il s’agit d’avis auto-promotionnels dès lors que l’entreprise évaluée contrôle la page qui les présente. La situation d’une application logicielle est différente. Le type SoftwareApplication, et par extension WebApplication, reste éligible aux extraits d’avis. L’application peut donc présenter ses propres évaluations d’utilisateurs, à condition que celles-ci soient authentiques, visibles et correctement collectées. Cela ne constitue pas une permission d’inventer une note. La différence porte uniquement sur le type d’élément évalué et sur les règles d’éligibilité appliquées par Google.

Les erreurs les plus risquées avec AggregateRating

L’apparition des étoiles peut encourager certains éditeurs à ajouter une notation purement artificielle dans le code. Cette pratique est déconseillée, car elle expose le site à la suppression des résultats enrichis et, dans les cas les plus sérieux, à une action manuelle sur les données structurées. Plusieurs erreurs doivent notamment être évitées.

Inventer une note ou un nombre d’avis

Déclarer 136 évaluations lorsqu’aucun système de notation n’existe sur le site constitue une information trompeuse. Le fait que Google affiche temporairement les étoiles ne rend pas la pratique conforme.

Masquer la note aux utilisateurs

Une note uniquement présente dans le JSON-LD, sans équivalent visible sur la page, ne respecte pas les recommandations générales de Google. L’utilisateur doit pouvoir retrouver l’information qui lui a été présentée dans le résultat de recherche.

Récupérer les avis d’une plateforme externe

Google demande de ne pas agréger dans le balisage les notes provenant d’autres sites. Il est donc déconseillé de reprendre directement une moyenne issue de Google Business Profile, Facebook, Trustpilot ou d’un autre service pour la présenter comme une notation propre au site.

Noter une catégorie ou une liste d’éléments

La note doit concerner un élément précis. Une page regroupant plusieurs applications, plusieurs produits ou plusieurs établissements ne devrait pas afficher une moyenne globale comme si elle concernait un seul objet clairement identifié.

Utiliser un type qui ne correspond pas au contenu principal

Déclarer une simple page éditoriale comme une WebApplication uniquement pour tenter d’obtenir des étoiles est également problématique. Le type principal doit refléter le véritable objet de la page.

Comment mettre en œuvre AggregateRating proprement pour une application web

Une implémentation durable commence par la collecte réelle des évaluations. L’application doit disposer d’un mécanisme permettant aux utilisateurs de donner une note, idéalement après une utilisation effective du service. Les données peuvent être enregistrées dans une base de données, un fichier structuré ou un système interne. La moyenne et le nombre d’évaluations doivent ensuite être calculés dynamiquement, et non saisis arbitrairement dans le modèle de la page. Le résultat doit être affiché à la fois :

• dans le contenu visible de la page ;
• dans les données structurées JSON-LD ;
• avec des valeurs strictement identiques dans les deux emplacements.

Voici un exemple plus complet :

{
  "@context": "https://schema.org",
  "@type": "WebApplication",
  "@id": "https://www.exemple.fr/#application",
  "name": "Nom de l'application",
  "url": "https://www.exemple.fr/",
  "applicationCategory": "SportsApplication",
  "operatingSystem": "Web",
  "description": "Description précise des fonctionnalités de l'application.",
  "offers": {
    "@type": "Offer",
    "price": "0",
    "priceCurrency": "EUR"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.8",
    "bestRating": "5",
    "worstRating": "1",
    "ratingCount": "136",
    "reviewCount": "92"
  }
}

Dans cet exemple, l’application a reçu 136 notes, dont 92 sont accompagnées d’un avis. La moyenne réellement calculée est de 4,8 sur 5. Une fois le code ajouté, plusieurs contrôles doivent être effectués :

1. tester l’URL dans le test des résultats enrichis de Google ;
2. vérifier l’absence d’erreur critique ;
3. contrôler le rendu HTML final, notamment lorsque le JSON-LD est généré en JavaScript ;
4. inspecter l’URL dans Google Search Console ;
5. surveiller les rapports relatifs aux résultats enrichis et aux actions manuelles.

Pourquoi les étoiles peuvent apparaître puis disparaître

L’affichage des étoiles n’est jamais définitivement acquis. Google peut modifier la présentation d’un résultat en fonction d’une requête, d’un appareil ou d’une réévaluation algorithmique. Les étoiles peuvent notamment disparaître lorsque :

• Google ne retrouve plus la note dans le contenu visible ;
• le nombre d’avis déclaré paraît incohérent ;
• le type principal de la page ne correspond pas à une véritable application ;
• le balisage change après une mise à jour du thème ou du développement ;
• Google estime que le résultat enrichi n’est pas utile pour une requête donnée ;
• les règles ou les systèmes de sélection de Google évoluent ;
• une action manuelle est appliquée aux données structurées.

Une disparition ne signifie donc pas nécessairement qu’une pénalité SEO a été appliquée. Une action manuelle relative aux données structurées peut supprimer l’éligibilité aux résultats enrichis sans entraîner automatiquement une baisse du classement organique classique. Il reste néanmoins préférable de corriger rapidement tout balisage trompeur ou invérifiable. Les données structurées doivent décrire fidèlement la page et non servir à créer artificiellement un avantage visuel dans les SERP.

Validité, éligibilité et affichage : Les trois contrôles à retenir

Pour analyser correctement un balisage AggregateRating, il faut donc poser trois questions successives.

Le code est-il valide selon Schema.org ?
Le type choisi accepte-t-il la propriété aggregateRating et le JSON-LD est-il correctement formé ?

Le contenu est-il éligible selon les règles de Google ?
Le type est-il pris en charge, les propriétés obligatoires sont-elles présentes et la note correspond-elle à un contenu réel et visible ?

Google décide-t-il d’afficher les étoiles ?
Cette dernière décision reste algorithmique et n’est jamais garantie, même lorsque les deux premières conditions sont remplies.

Dans le cas d’une véritable application web, l’utilisation de WebApplication avec une note globale n’est donc pas une anomalie. Elle peut être parfaitement conforme et officiellement prise en charge. Le risque apparaît lorsque les évaluations sont fictives, invisibles, récupérées sur une plateforme extérieure ou sans rapport avec l’élément réellement présenté sur la page.

La bonne pratique ne consiste pas à chercher le balisage qui déclenchera artificiellement des étoiles, mais à fournir à Google une représentation fidèle d’un système d’avis réellement utilisé par les internautes.