Faut-il vraiment normaliser les avis sur cinq points pour le SEO ?

Pourquoi Google insiste-t-il sur le format ISO pour les dates ?

Le format ISO 8601 est une norme internationale de représentation des dates et heures. Concrètement, cela ressemble à « 2023-03-15 » ou « 2023-03-15T14:30:00Z ». Google recommande ce format car ses robots analysent des milliards de pages rédigées dans des langues différentes, avec des conventions de date variables.

Quand un site français affiche « 15/03/2023 » tandis qu'un site américain montre « 03/15/2023 », l'ambiguïté est totale pour un crawler. La balise meta permet de lever cette incertitude : vous affichez la date dans le format que vous voulez pour vos utilisateurs, mais vous donnez à Google une version standardisée qu'il peut interpréter sans erreur. Le format ISO devient la langue commune entre votre site et le moteur.

Les notes doivent-elles absolument être sur cinq points ?

Google parle d'une recommandation, pas d'une obligation technique. Le vocabulaire schema.org supporte différentes échelles de notation via les propriétés bestRating et worstRating. Vous pouvez donc techniquement baliser un système sur 10, 100 ou même des échelles inversées.

La normalisation sur cinq points est suggérée parce que c'est l'échelle la plus répandue dans les rich snippets que Google affiche. En pratique, si votre système interne utilise une autre échelle, vous devez déclarer explicitement les bornes dans votre balisage. Google convertira ensuite pour l'affichage dans les résultats de recherche. Mais cette conversion crée des approximations, et la question reste : à quel point ces approximations impactent-elles réellement le CTR ?

Quel lien entre ce balisage et l'affichage en SERP ?

Le balisage schema.org pour les notes permet de générer des étoiles dans les snippets enrichis. Ces étoiles augmentent la surface visuelle de votre résultat et, en théorie, le taux de clic. Mais Google ne garantit jamais l'affichage des rich snippets, même avec un balisage parfait.

Plusieurs facteurs entrent en jeu : la concurrence sur la requête, la qualité perçue du contenu, la cohérence entre le balisage et le texte visible, et des critères opaques de filtrage anti-spam des avis. Un site peut avoir un balisage impeccable et ne jamais voir ses étoiles s'afficher. C'est frustrant, mais c'est la réalité terrain.

• Format ISO 8601 requis dans une balise meta si le format visible diffère de la norme internationale
• Normalisation sur cinq points recommandée pour les notes, mais pas strictement obligatoire techniquement
• Propriétés bestRating et worstRating permettent de déclarer des échelles personnalisées dans schema.org
• Affichage des rich snippets non garanti, même avec un balisage conforme
• Cohérence entre balisage et contenu visible essentielle pour éviter le filtrage anti-spam

Cette recommandation reflète-t-elle vraiment les pratiques observées ?

Sur le terrain, beaucoup de sites internationaux utilisent déjà le format ISO pour les dates dans leurs balises meta, ne serait-ce que pour des raisons de standardisation technique interne. Les CMS modernes gèrent souvent cette conversion automatiquement. Le vrai problème apparaît sur des sites legacy ou des développements custom où les développeurs n'ont jamais pensé à cette couche de métadonnées.

Pour les notes, la situation est plus nuancée. On observe des sites avec des échelles sur 10 (comme TrustPilot dans certains marchés) ou 100 qui apparaissent quand même en rich snippets. Google semble convertir à la volée, mais la perte de granularité est réelle. Un 87/100 devient un 4,4/5 approximatif, ce qui peut trahir une nuance importante pour un acheteur potentiel. [A vérifier] : Google n'a jamais publié de données sur l'impact SEO réel d'une échelle 5 vs. une autre échelle bien balisée.

Quelles incohérences subsistent dans cette directive ?

Google parle de « recommandation » pour la normalisation sur cinq points, mais ses propres outils de test de données structurées ne signalent aucune erreur quand on utilise une échelle différente. Cette ambiguïté crée une zone grise où les praticiens se demandent s'ils risquent une pénalité ou simplement un affichage sous-optimal.

Autre point : la documentation schema.org elle-même ne privilégie aucune échelle particulière. C'est une surcouche Google qui n'est pas forcément alignée avec les standards ouverts qu'elle prétend suivre. En pratique, si vous optimisez pour d'autres moteurs ou pour des agrégateurs de données, la normalisation sur cinq peut même être contre-productive. Soyons honnêtes, personne ne teste systématiquement l'impact d'un changement d'échelle sur le CTR, donc on navigue à vue.

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

Pour les sites BtoB avec des notations complexes ou des scores de conformité, forcer une échelle sur cinq est absurde. Un score de certification technique ne se résume pas à des étoiles sympas. Dans ces cas, le balisage schema.org devient un vernis marketing plutôt qu'une information utile.

De même, certains marchés locaux (Chine, Japon) utilisent des systèmes de notation culturellement ancrés qui ne se calquent pas sur une échelle occidentale. Google n'en parle jamais, ce qui montre les limites de ses recommandations globales. Enfin, si votre site affiche des avis agrégés provenant de multiples sources avec des échelles différentes, la conversion devient un cauchemar technique et une source potentielle de biais dans la représentation des données.

Que faut-il implémenter concrètement sur votre site ?

Pour les dates, ajoutez une balise meta avec la propriété content en format ISO 8601 chaque fois que vous affichez une date dans un format localisé. Exemple pratique : si vous montrez « 15 mars 2023 » à l'écran, placez une balise meta avec content="2023-03-15". La plupart des CMS peuvent automatiser cette conversion via des plugins ou des snippets de code.

Pour les notes, assurez-vous que votre balisage schema.org inclut les propriétés ratingValue, bestRating et worstRating. Si vous utilisez une échelle sur 10, déclarez-le explicitement : bestRating="10" et worstRating="1" (ou 0 selon votre logique). Google fera la conversion pour l'affichage, mais au moins vous aurez fourni les bonnes métadonnées. Testez systématiquement avec l'outil de test des résultats enrichis de Google.

Quelles erreurs éviter absolument ?

Ne laissez jamais un écart entre le balisage et le contenu visible. Si votre page affiche « 4,7/5 (230 avis) » mais que votre schema.org déclare 4,2/5, Google peut considérer cela comme une tentative de manipulation et ne pas afficher vos étoiles. La cohérence est plus importante que la perfection technique.

Autre piège classique : utiliser le balisage AggregateRating pour des avis qui ne sont pas réellement agrégés ou vérifiés. Google a resserré ses critères ces dernières années et filtre de plus en plus les notations auto-déclarées ou douteuses. Si vos avis proviennent d'une source unique non vérifiable, attendez-vous à ce que vos rich snippets disparaissent tôt ou tard. Évitez aussi de baliser des pages sans contenu réel d'avis : une page catégorie avec juste un score moyen mais aucun avis détaillé risque d'être ignorée.

Comment vérifier que votre implémentation fonctionne ?

Utilisez l'outil de test des résultats enrichis de Google (anciennement outil de test des données structurées). Collez l'URL de vos pages clés et vérifiez que toutes les propriétés requises sont détectées sans erreur ni avertissement. Attention, un test réussi ne garantit pas l'affichage en SERP, mais un test échoué garantit qu'il n'y aura rien.

Surveillez également vos impressions et CTR dans la Search Console en filtrant par type de résultat enrichi. Si vos pages avec balisage n'obtiennent pas de rich snippets après plusieurs semaines, creusez : soit le balisage est mal formé, soit le contenu ne remplit pas les critères de qualité de Google, soit la concurrence sur la requête ne permet pas l'affichage.

• Ajouter une balise meta ISO 8601 pour toutes les dates affichées dans un format localisé
• Déclarer explicitement bestRating et worstRating dans le balisage schema.org des notes
• Vérifier la cohérence stricte entre les données visibles et le balisage structuré
• Tester chaque page avec l'outil de test des résultats enrichis de Google
• Surveiller les impressions de résultats enrichis dans la Search Console
• Éviter les notations auto-déclarées sans source vérifiable ou agrégation réelle