Comment utiliser les données structurées pour les avis clients

Un client m'a envoyé un jour une capture d'écran de sa fiche Google. Il était furieux. « Mes concurrents ont cinq étoiles, moi j'ai que dalle. » Sauf qu'il avait 47 avis à 4,8 de moyenne, et que le problème n'était pas la qualité de ses avis. C'était le balisage. Personne, à part lui et ses clients les plus motivés, ne voyait ces 47 avis dans les résultats de recherche. Sa fiche affichait un vide, alors que ses étoiles existaient depuis huit mois.

Voilà ce que font vraiment les données structurées pour les avis clients : elles ne créent pas la confiance, elles rendent visible une confiance qui est déjà là mais que Google n'arrive pas à interpréter tout seul. Et quand c'est mal fait, cette confiance reste invisible. Je vais vous montrer comment procéder, avec le code, les pièges que j'ai rencontrés, et deux cas où ça n'a rien donné du tout.

Comment utiliser les données structurées pour les avis clients sans se tromper de cible

Première chose à intégrer : les données structurées ne sont pas de la magie marketing. C'est un vocabulaire. Vous décrivez à Google, dans une langue qu'il comprend, ce qu'est votre contenu. Pour un avis, ça veut dire lui dire trois choses : qui est noté, quelle est la note, et qui l'a donnée.

Et là, la plupart des gens se plantent. Ils balisent tout. L'avis produit, l'avis entreprise, la notation interne, la moyenne pondérée maison. Résultat : un bazar que Google n'exploite pas, et parfois sanctionne.

Review ou AggregateRating : lequel choisir ?

Review décrit un avis unique. AggregateRating décrit une moyenne calculée sur plusieurs avis. Dans la pratique, vous avez presque toujours besoin des deux : l'agrégat pour afficher les étoiles dans les résultats, l'avis individuel pour muscler la page et donner du texte à lire.

Spoiler : la balise AggregateRating seule, sans Review derrière, fonctionne parfois. Mais Google peut la rejeter s'il ne trouve pas trace des avis individuels correspondants sur la page. J'ai vu un site passer de 4,6 à zéro étoile pendant trois semaines après avoir supprimé les Review individuelles parce qu'un développeur les trouvait « redondantes ». Ça a coûté une refonte du template.

Le code concret, copiable

Le format recommandé est JSON-LD, à insérer dans le `

` ou juste avant la fermeture du ``. Voici un exemple minimal et fonctionnel pour une entreprise locale :

{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "Le Comptoir des Halles",
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.8",
    "reviewCount": "47"
  },
  "review": [{
    "@type": "Review",
    "author": { "@type": "Person", "name": "Claire M." },
    "datePublished": "2026-03-14",
    "reviewRating": {
      "@type": "Rating",
      "ratingValue": "5"
    },
    "reviewBody": "Service rapide, cuisine honnête."
  }]
}

Les propriétés qui comptent réellement : ratingValue, reviewCount, author, datePublished. Oubliez datePublished et vous perdez la fraîcheur perçue. Oubliez author et Google considère l'avis comme non fiable.

Pour un produit, la structure change : on remplace LocalBusiness par Product et on ajoute itemReviewed. Pour un article de blog qui parle d'un service, on utilise Product avec des Review imbriquées. Toute la documentation schema.org est là pour ça.

Pourquoi votre balisage ne s'affiche pas (la vraie raison, pas celle qu'on vous donne)

Avouons-le : c'est le piège numéro un. Un site WordPress avec un plugin d'avis relié à son CRM (ou pire, à un widget tiers), et le balisage injecté en JavaScript après chargement. Google exécute le JS, mais pas toujours, pas immédiatement, et rarement de façon fiable sur tous les crawls.

Résultat : Search Console vous dit « Aucun élément détecté » alors que vous voyez le code dans le DOM en inspectant la page. Vous vous arrachez les cheveux. Je suis passé par là pendant un bon mois avant de comprendre.

Les solutions qui marchent vraiment

• Rendu côté serveur : le HTML contient déjà le balisage au moment de la réponse, avant tout JavaScript. C'est la seule méthode fiable à 100 %.
• Pré-rendu statique : vous générez le HTML une fois, vous le servez comme un fichier figé. Parfait pour des pages qui bougent peu.
• Injection statique via le template : si vos avis sont stockés en base, faites-les sortir directement dans le template PHP ou dans un fichier généré. Pas de requête AJAX, pas de widget externe.

Et là, question rhétorique : pourquoi payer un abonnement mensuel à un widget d'avis qui, en plus, va peut-être bloquer votre balisage ? Dans 90 % des cas que j'ai vus, une boucle PHP de vingt lignes fait mieux que le widget à 39 €/mois.

Les règles d'éligibilité que personne ne lit

Google a des règles strictes, et elles tuent 80 % des tentatives de balisage d'avis. Les voici, résumées sans langue de bois.

Avis auto-hébergés vs avis tiers

Si vous collectez les avis directement sur votre site (formulaire de contact, module dédié), vous pouvez les baliser. Si vous les prenez depuis Google Business Profile ou Trustpilot et que vous les affichez sur votre site, c'est plus délicat : Google demande que l'avis soit visible pour un utilisateur sur la page concernée, avec le nom de l'auteur et la note.

Le point qui coince : l'auto-notation. Baliser ses propres avis alors que personne n'a jamais rien noté, c'est une porte ouverte à une action manuelle. J'ai vu un e-commerce le faire sur 300 produits. Trois mois plus tard, plus aucune étoile sur tout le domaine. Il a fallu tout nettoyer et attendre.

Ce qui change entre entité locale, produit et organisation

Le type d'entité que vous balisez détermine la structure attendue. Voici la comparaison qui m'a le plus servi :

Type	Balise principale	Ce que ça affiche	Piège fréquent
Entreprise locale	LocalBusiness + AggregateRating	Étoiles sur la fiche	Confondre avec la fiche Google Business Profile
Produit	Product + Review	Étoiles + nombre d'avis	Oublier itemReviewed
Organisation	Organization + AggregateRating	Rarement exploité par Google	Attendre un affichage qui n'arrive pas
Article de blog	Article + Review	Étoiles sur le résultat de recherche	Baliser des avis inexistants sur la page
Vidéo	VideoObject + Review	Miniature enrichie	Doublonner avec le balisage produit

Ce tableau m'a coûté deux semaines de tests. Gardez-le.

Et le balisage FAQ, on en fait quoi en 2026 ?

Question que l'on me pose souvent. Google a progressivement abandonné l'affichage des rich results FAQ dans les résultats de recherche. Le balisage n'est pas « interdit », mais il ne produit plus grand-chose en termes d'affichage visuel.

Du coup, ma position est simple : si vous avez une section FAQ sur une page produit, balisez-la quand même en FAQPage. Ça ne coûte rien, ça aide les moteurs à comprendre le contenu, et si Google revient en arrière (ce qui arrive), vous êtes déjà prêt. Mais ne construisez pas une stratégie entière autour de ça.

Surveiller ce que Google voit réellement

Vous avez posé le code. Bravo. Maintenant, comment savoir s'il est lu ?

Deux outils, dans cet ordre :

1. Le test des résultats enrichis de Google : il analyse une URL en direct et vous dit quels types de balises sont détectés, valides, ou en erreur.
2. Le rapport « Résultats enrichis » dans Search Console : il agrège toutes les pages du site et distingue les catégories valides, les avertissements et les erreurs. C'est ici que vous voyez si vos étoiles sont réellement prises en compte.

Un détail que j'ai mis du temps à piger : il y a souvent un délai de plusieurs jours, parfois deux semaines, entre un déploiement de balisage et sa prise en compte dans les rapports. Ne paniquez pas à J+2, attendez J+14.

Et une bonne habitude : mettez une alerte sur les changements de statut de balisage. Un template modifié, un plugin mis à jour, et vos étoiles disparaissent sans prévenir. Ça m'est arrivé sur un site e-commerce en pleine période de soldes. Cinq jours sans étoiles sur 200 produits. Niveau conversion, ça s'est senti.

Deux cas où les données structurées n'ont rien changé

Je ne vais pas vous vendre du rêve. J'ai deux expériences où le balisage parfait n'a strictement rien apporté.

Premier cas : une marque de cosmétiques bio, fiche produit impeccable, avis balisés correctement. Aucun changement sur le CTR en trois mois. Pourquoi ? Parce que les étoiles apparaissaient déjà via le comparateur d'avis tiers qu'elle utilisait. Le balisage propre n'a rien ajouté visuellement. Le seul gain : la robustesse, si le tiers décidait de couper l'affichage.

Second cas : une petite agence locale avec peu d'avis (moins de dix). Les étoiles se sont affichées, mais le volume trop faible a poussé Google à ne pas les mettre en avant sur les requêtes concurrentielles. Le balisage n'est pas un levier magique si vous n'avez pas masse critique d'avis. Il amplifie, il ne crée pas.

Ce que j'en retire : les données structurées pour les avis clients sont un multiplicateur. Sur une base solide, elles font gagner du clic. Sur une base vide, elles ne font rien.

La mise en place, dans l'ordre

Si vous devez le faire cette semaine, voilà la séquence que j'applique à chaque nouveau projet :

• Lister toutes les pages qui contiennent des avis (produit, service, accueil).
• Vérifier que les avis sont visibles dans le HTML brut (Ctrl+U, pas l'inspecteur).
• Écrire le JSON-LD à la main pour une page test, la plus représentative.
• Passer la page au test des résultats enrichis, corriger, redéployer.
• Attendre la prise en compte dans Search Console, puis généraliser au template.
• Poser une alerte de surveillance sur les changements de balisage.

Trois jours de travail réel, maximum, sur un site propre. Si ça vous prend deux semaines, c'est que le rendu côté serveur n'est pas en place.

Il reste une question que je ne sais pas trancher : est-ce que Google finira par se passer complètement du balisage et extraira les avis directement depuis les pages, avec ses propres modèles ? Vu la direction prise sur les FAQ, ce n'est pas absurde. En attendant, le balisage propre reste la seule façon de parler à Google dans sa langue. Et tant que ce sera vrai, ça vaudra les trois jours.