Données structurées schema.org : la clé pour booster vos rich snippets

Vous avez déjà vu votre fiche produit afficher cinq étoiles dans Google, puis ces étoiles disparaître du jour au lendemain sans qu'aucun humain n'ait touché au back-office. Ce scénario, je l'ai vécu sur un site e-commerce que je gérais en solo. Le coupable n'était pas un bug, ni une mise à jour d'algorithme surprise, mais une ligne de JSON-LD mal fermée qu'un développeur avait poussée en production un vendredi soir.

Voilà pourquoi je continue de m'intéresser aux données structurées schema.org : elles restent le levier le plus rentable pour obtenir des rich snippets, à condition d'accepter qu'elles ne pardonnent pas l'à-peu-près. Dans ce qui suit, je vous montre du code réel, les erreurs qui coûtent cher, et comment mesurer si ça fonctionne vraiment sur votre trafic.

Schema.org et rich snippets : comprendre ce que vous demandez vraiment à Google

Il faut dissocier deux choses que l'on confond en permanence. Schema.org est un vocabulaire, un dictionnaire de propriétés que vous utilisez pour décrire votre page. Les rich snippets sont une décision de Google, qui pioche dans ce vocabulaire quand ça l'arrange. Écrire du schema.org ne déclenche pas un rich snippet ; ça rend seulement votre page éligible.

La confusion vient du fait que les deux sont toujours présentés ensemble dans les mêmes tutoriels. Je comprends pourquoi : sans balisage, la question ne se pose même pas. Mais la marge entre « ma page est propre » et « Google affiche mes étoiles » est plus large qu'on ne le croit.

Ce que Google regarde avant d'afficher un résultat enrichi

Trois conditions, dans cet ordre. Le type de contenu doit faire partie de ceux qui ouvrent droit à un affichage enrichi (avis, produit, recette, événement, FAQ, fil d'Ariane, entre autres). Les propriétés obligatoires doivent être présentes et correctement remplies. Et le contenu balisé doit correspondre à ce que l'internaute voit réellement sur la page.

Cette dernière règle est celle qui piège le plus de monde. Un prix balisé à 49 € alors que la fiche affiche 59 € ne passe pas. Google considère qu'il y a tromperie potentielle et retire la prise en compte du balisage pour cette URL.

Les types schema.org qui servent à quelque chose, et les autres

Tous les types ne donnent pas droit à un affichage enrichi. Certains servent uniquement à préciser le sens d'une page pour les moteurs et pour d'autres systèmes qui consomment le web.

• Product : prix, disponibilité, note. Le plus rentable en e-commerce.
• FAQPage : questions/réponses dépliables, mais dont l'affichage s'est nettement raréfié.
• BreadcrumbList : le fil d'Ariane sous l'URL.
• Article : utile pour les actualités et les blogs, sans bénéfice visuel direct.
• Event, Recipe, JobPosting : chacun avec ses propres règles d'éligibilité.

Le reste, comme Organization ou Person, aide à la compréhension mais n'apporte rien de visible dans la page de résultats. Je le précise parce que beaucoup de gens balisent frénétiquement en espérant un effet, puis se demandent pourquoi rien ne bouge.

Un exemple JSON-LD prêt à l'emploi pour un produit

Passons au concret. Voici le squelette que j'utilise par défaut pour une fiche produit, et que j'adapte ensuite selon le site.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Nom exact du produit",
  "image": ["https://exemple.fr/image.jpg"],
  "description": "Description reprise de la page",
  "sku": "REF-1234",
  "brand": {"@type": "Brand", "name": "Marque"},
  "offers": {
    "@type": "Offer",
    "price": "49.00",
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock",
    "url": "https://exemple.fr/produit"
  }
}
</script>

Trois propriétés méritent votre attention : name, offers.price, et availability. Si l'une d'elles manque ou diverge du visible, le balisage ne produira rien. Le reste améliore la compréhension mais n'est pas bloquant.

Product, Offer, AggregateRating : dans quel ordre les remplir

Commencez toujours par Product avec son Offer intégré. Une fois que ça passe au test, ajoutez AggregateRating seulement si vous avez de vrais avis vérifiables sur la page. Le balisage d'avis inventé est ce qui déclenche le plus rapidement une action de la part de Google, et ce n'est pas le genre de chose qu'on veut provoquer.

Erreurs fréquentes que je vois sur les sites que j'audite

Le balisage masqué arrive en tête. Vous codez une note en dur dans le script sans jamais l'afficher pour l'internaute. Ça peut fonctionner quelques semaines, puis disparaître. Ensuite vient la casse entre plusieurs blocs : un plugin qui injecte un Product et votre code maison qui en ajoute un second avec des valeurs différentes. Google choisit, mais pas forcément celui que vous voulez.

Bref, la troisième erreur, la plus sournoise, c'est l'oubli de mise à jour. Le prix change côté administration, le JSON-LD reste figé sur l'ancienne valeur parce qu'il a été écrit à la main. C'est exactement le scénario qui m'a coûté mes étoiles il y a quelques années.

WordPress : ce que les plugins font vraiment à votre place

Sur WordPress, la question n'est pas tellement « faut-il baliser » que « qui balise quoi ». Yoast, Rank Math, SEOPress génèrent automatiquement du JSON-LD. Le résultat est généralement propre, mais vous ne contrôlez pas tout.

Ce que les plugins génèrent par défaut, selon le contexte

Plugin	Type principal injecté	Limite notable
Yoast SEO	Article, WebPage, Organization, BreadcrumbList	Le balisage produit dépend d'un module complémentaire
Rank Math	Product, FAQ, Article, plusieurs types simultanés	Peut empiler des blocs si vous ajoutez du code à côté
SEOPress	Article, Breadcrumb, types personnalisés	Configuration initiale plus manuelle

Une vérification que je fais systématiquement : je compare le nombre de blocs JSON-LD sur la page avec ce que je crois avoir configuré. Il m'est arrivé de trouver quatre blocs sur une même page produit, dont deux qui se contredisaient. Le plugin principal n'était pas en cause : c'était un thème enfant qui réinjectait sa propre version.

Faut-il écrire son JSON-LD à la main ?

Pour un blog ou un site vitrine, non. Pour un e-commerce avec des prix évolutifs, oui, mais alors pas à la main : via le thème ou un petit plugin maison qui lit les vraies valeurs de la base. Un prix codé en dur dans un script est une dette qui se rappellera à vous.

Tester, puis mesurer : la partie que tout le monde saute

Le test des résultats enrichis de Google vous dit si le code est valide. Il ne vous dit pas si le rich snippet s'affichera. Et il ne vous dit surtout pas s'il apporte du trafic.

Pour ça, direction Search Console, rapport « Résultats de recherche ». Le CTR sur les pages concernées, comparé à la période précédente, c'est votre seule mesure honnête. Les ordres de grandeur qu'on lit partout sur l'effet des rich snippets sur le taux de clic varient énormément selon le secteur, la position et le type d'affichage. Je me méfie des chiffres ronds qu'on me présente comme universels.

Que faire si le rich snippet n'apparaît pas malgré un balisage valide

Attendez déjà quelques semaines. L'indexation n'est pas instantanée et l'affichage suit encore plus lentement. Ensuite, vérifiez que le type de contenu est bien éligible. Si c'est le cas et que rien ne bouge, regardez la concurrence : sur certaines requêtes, Google choisit d'afficher un autre format, ou pas de format enrichi du tout. Ce n'est pas un échec de votre côté.

Faut-il baliser les avis clients importés d'un tiers ?

Non. Les avis balisés doivent provenir d'utilisateurs qui ont réellement publié sur votre site et être visibles pour eux. Réutiliser une note agrégée depuis une place de marché n'est pas conforme et peut entraîner la perte du balisage pour l'ensemble du domaine.

Ce qu'on retient vraiment, une fois le code écrit

Les données structurées schema.org ne sont pas une astuce pour forcer Google à vous donner un beau résultat. C'est une déclaration de bonne foi : voici ce que contient ma page, vérifiez-le par vous-même. Tant que cette déclaration reste vraie, vous avez une chance. Dès qu'elle cesse de l'être, tout s'effondre sans prévenir.

La vraie compétence n'est donc pas d'écrire du JSON-LD une fois. C'est de mettre en place quelque chose qui le régénère à chaque changement de prix, de stock ou de note, et qui vous prévient quand la cohérence se casse. Si vous ne savez pas répondre à cette question, vous n'avez pas un problème de balisage. Vous avez un problème d'automatisation.