Un client m'a envoyé un screenshot l'autre jour. Sa fiche produit affichait 4,7 étoiles, un prix barré, la mention "en stock". Lui, il voyait son propre site depuis des années. Ce jour-là, il a cliqué sur son propre résultat dans Google, juste pour vérifier que c'était bien lui. C'était bien lui. Et il a vendu six pièces dans l'après-midi.
Les données structurées ne sont pas de la magie. C'est du balisage. Mais ce balisage change la façon dont Google affiche votre page, et donc la façon dont on clique dessus. Le sujet, c'est les rich snippets : ces résultats enrichis (étoiles, FAQ, fil d'Ariane, horaires, prix) qui prennent plus de place et attirent plus l'œil que le lien bleu standard.
Points clés à retenir
- Les données structurées sont un langage que Google comprend pour afficher des rich snippets.
- Le format JSON-LD est aujourd'hui le plus simple à maintenir et celui que Google recommande.
- Un balisage correct ne garantit pas l'affichage d'un rich snippet : Google décide.
- Le gain réel porte sur le CTR, pas sur le classement brut.
- Tester avec l'outil de validation officiel avant de déployer évite 90 % des surprises.
Pourquoi les données structurées changent la donne dans les résultats de recherche
Un résultat enrichi, dans la page de résultats, occupe plus d'espace vertical. C'est mécanique. Et plus vous prenez de place, moins il en reste pour le concurrent juste en dessous.
Mais l'essentiel n'est pas là. Le vrai levier, c'est la qualification du clic. Quand votre extrait affiche un prix, une note ou une disponibilité, la personne qui clique sait déjà à quoi s'attendre. Elle clique moins par curiosité, plus par intention.
Ce que Google laisse vraiment afficher
Google ne montre pas tout, et pas toujours. Voici les types les plus courants, avec leur utilité concrète :
- Produit : prix, disponibilité, note d'avis. Utile pour le e-commerce.
- Avis : étoiles sur une fiche locale ou un service.
- FAQ : questions dépliables directement dans le résultat.
- Recette : temps de préparation, calories, note.
- Événement : dates, lieu, billetterie.
- Article et fil d'Ariane : signalent la structure du site.
- Organisation : logo, réseaux, coordonnées.
Ce qui compte, c'est d'en choisir un ou deux pertinents. J'ai vu des sites baliser absolument tout et se retrouver avec rien d'affiché, parce que le contenu réel ne correspondait pas au balisage. Google recoupe systématiquement.
JSON-LD, Microdata, RDFa : lequel choisir en 2026 ?
Trois formats coexistent pour écrire les mêmes données. En pratique, un seul est vraiment confortable aujourd'hui.
| Format | Où il vit | Maintenance | Recommandation |
|---|---|---|---|
| JSON-LD | Dans un script, à part du HTML | Simple, isolé du rendu | Format privilégié |
| Microdata | Directement dans le HTML visible | Verbeux, mélange fond et forme | Ancien, encore lu |
| RDFa | Attributs dans le HTML | Puissant mais lourd | Rare en pratique |
Franchement, si vous débutez, allez sur JSON-LD et ne regardez pas derrière. Le balisage vit dans un bloc séparé de votre code, vous pouvez le générer depuis un CMS, le modifier sans toucher au template, et le relire six mois plus tard sans vous arracher les cheveux.
Le cas où Microdata garde un intérêt : un site ancien, déjà balisé, qui fonctionne. Refactoriser pour refactoriser n'apporte rien tant que Google continue de lire.
À quoi ressemble un balisage JSON-LD minimal
Un bloc script de type application/ld+json posé dans le head ou juste avant la fermeture du body. À l'intérieur, un objet qui décrit votre entité :
- Le
@type: "Product", "Article", "LocalBusiness", etc. - Le
nameet l'image. - Les propriétés spécifiques au type (
offerspour un produit,aggregateRatingpour des avis). - Une URL canonique cohérente avec la page.
Rien de sorcier. Le piège, c'est de le remplir avec des valeurs fausses. Un prix qui ne correspond pas à la page, et Google ignore le balisage. Parfois pour longtemps.
Mise en place : la démarche qui évite les mauvaises surprises
Bon, la théorie c'est bien. Passons à l'ordre des opérations, celui que j'applique quand je reprends un site.
Les quatre étapes qui comptent
- Choisir le type pertinent. Pas celui qui a le plus de champs disponibles. Celui qui décrit ce que la page est réellement.
- Écrire le JSON-LD en s'appuyant sur le vocabulaire Schema.org.
- Valider avec le test officiel de Google, puis inspecter l'URL dans la Search Console.
- Surveiller les rapports de la Search Console sur les données structurées pendant quelques semaines.
Un détail que j'ai appris à la dure : le balisage peut être parfaitement valide et pourtant ne jamais s'afficher. Sur un projet, j'avais soigné les FAQ de trois articles. Deux semaines plus tard, rien. Le problème n'était pas le code, mais la concurrence : Google décidait simplement de ne pas afficher d'extrait FAQ sur ces requêtes. Je ne pouvais rien y faire. Le balisage servait quand même à la compréhension, mais visuellement, zéro gain.
Les erreurs qui coûtent cher
- Baliser une note globale sans avis réels sur la page.
- Répéter le même
@typesur chaque article d'un blog, sans distinction. - Oublier de mettre à jour le prix après une promo terminée.
- Coller un balisage généré par une extension sans le relire.
La dernière est ma préférée. Une extension m'a un jour généré un aggregateRating avec une note fabriquée, "pour l'exemple". Heureusement repéré avant mise en ligne. Google sanctionne ce genre de chose quand il s'en aperçoit.
Rich snippets et IA : faut-il encore y croire ?
La question revient souvent. Avec les réponses générées par l'IA qui s'affichent en haut des résultats, à quoi bon enrichir sa ligne ?
Deux choses. D'abord, ces réponses ne remplacent pas le clic pour tout le monde : beaucoup de requêtes gardent des liens visibles en dessous. Ensuite, les données structurées alimentent aussi la compréhension du contenu par ces systèmes. Un balisage propre aide à identifier ce que vous êtes et ce que vous proposez, ce qui reste utile quand un modèle décide quelle source citer.
Le classement brut, lui, ne bouge pas grâce au balisage. C'est un point qu'il faut dire clairement : les données structurées ne sont pas un facteur de positionnement direct. Elles améliorent l'affichage et, souvent, le taux de clic. C'est déjà beaucoup.
Que faire quand les extraits affichés disparaissent ?
Vérifiez d'abord que le balisage est toujours valide et que le contenu de la page n'a pas changé. Ensuite, souvenez-vous que Google affiche les extraits de façon sélective. Une disparition n'est pas une sanction. C'est parfois juste une décision algorithmique sur une requête donnée.
Ne sur-réagissez pas. J'ai vu des équipes tout casser et repartir de zéro après trois jours sans étoiles. Mauvais réflexe. On attend, on observe, on corrige uniquement ce qui est réellement en erreur.
Combien ça rapporte, vraiment ?
Je n'ai pas de chiffre universel à vous donner, et quiconque vous en promet un précis vous raconte n'importe quoi. Le gain dépend de votre position, de la requête, du type d'extrait et du secteur.
Ce que je peux dire, d'expérience : sur un site e-commerce où j'avais ajouté les étoiles d'avis et la disponibilité sur les fiches produit, le taux de clic sur ces pages a grimpé nettement en quelques semaines — de l'ordre de 20 à 30 % sur les requêtes où l'extrait s'affichait. Sur d'autres projets, l'effet a été proche de zéro. La différence ? La pertinence de l'extrait par rapport à l'intention de la recherche.
Les étoiles aident quand on compare. Un prix aide quand on cherche à acheter. Une FAQ aide quand on pose une question. L'extrait doit parler la même langue que la requête. Sinon, il ne sert à rien.
Faut-il baliser toutes les pages d'un site ?
Non. Concentrez-vous sur celles où un extrait apporte une information distinctive : fiches produit, articles de fond, pages de contact locales, événements. Baliser du contenu générique pour baliser ne produit rien.
Peut-on se faire pénaliser pour du balisage mal fait ?
Un balisage invalide est simplement ignoré. Un balisage qui contredit le contenu visible peut, lui, entraîner une action manuelle. La règle est simple : le balisage doit refléter ce qu'un visiteur voit sur la page.
Le balisage, au fond, c'est de la traduction. Vous décrivez votre contenu dans un vocabulaire que la machine comprend, et en échange elle accepte de l'afficher un peu plus joliment. Pas de formule magique, pas de raccourci. Juste un travail précis, répété, testé.
Et puis un jour, un client vous envoie un screenshot, surpris de voir ses étoiles pour la première fois. Ça ne sauvera pas votre trimestre. Mais ça fait plaisir.