Un client m'appelle l'an dernier, paniqué. Sa fiche produit affiche des étoiles dans Google depuis deux ans. Du jour au lendemain, plus rien. Pas une pénalité, pas un message dans la Search Console. Juste le vide. On a mis trois jours à comprendre : son développeur avait réécrit le template produit et supprimé le bloc JSON-LD au passage. Un deploy de routine, un balisage à zéro, un CTR qui chute de 18 % en une semaine sur les pages catégorie.
Voilà pourquoi les données structurées méritent mieux qu'un plugin installé puis oublié. Elles ne sont pas une décoration SEO : c'est la seule partie de votre page que Google lit sans interpréter, sans deviner. Vous lui donnez un prix, une note, une date, un auteur. Il vous rend des rich snippets — ces résultats enrichis qui prennent deux lignes de plus dans un écran où tout le monde se bat pour une ligne.
Points clés à retenir
- JSON-LD reste le format recommandé par Google, mais Microdata et RDFa ne sont pas morts.
- Un balisage qui décrit mal le contenu visible peut déclencher une action manuelle.
- Le rapport « Améliorations » de la Search Console est votre meilleur allié, pas l'outil de test.
- FAQ et HowTo ont été largement restreints : ne balisez plus en espérant des étoiles partout.
- Ce qui compte en 2026 : la cohérence entre le balisage, le contenu affiché et la promesse commerciale.
Données structurées et rich snippets : ce que Google fait vraiment de votre balisage
La confusion est tenace. Les données structurées sont le code. Les rich snippets sont le résultat visuel, et vous ne les contrôlez pas. Vous fournissez une déclaration ; Google décide s'il l'affiche, quand, et sur quelle requête. J'ai vu des équipes passer des semaines à baliser des recettes pour découvrir que le type était éligible mais que le rendu n'apparaissait jamais sur mobile en France. Frustrant, mais logique : le moteur arbitre en fonction de la qualité globale de la page, de la requête, de l'appareil.
JSON-LD, Microdata, RDFa : lequel choisir en 2026
Google recommande JSON-LD, et depuis longtemps. Ce n'est pas un détail de style. JSON-LD vit dans une balise <script>, séparé du HTML visible, ce qui veut dire que votre balisage peut évoluer sans toucher au rendu. Sur un site e-commerce avec 40 000 références, cette séparation change tout : un seul template modifié, une régénération, et c'est reparti.
Microdata et RDFa restent lus par Google. Si votre CMS est ancien et imbrique déjà les attributs dans le HTML, ne lancez pas une migration pour le plaisir. J'ai accompagné une PME qui voulait tout réécrire en JSON-LD « pour être propre » : six semaines de dev, zéro gain mesurable. Le balisage existant fonctionnait.
| Format | Où il vit | Quand le préférer | Principal défaut |
|---|---|---|---|
| JSON-LD | Bloc script séparé | Presque toujours, surtout sur gros catalogue | Duplique parfois l'info si mal maintenu |
| Microdata | Attributs dans le HTML | Site existant déjà balisé, refonte coûteuse | Pollue le markup, rigide |
| RDFa | Attributs dans le HTML | Contextes éditoriaux avec besoin sémantique fin | Syntaxe plus lourde à écrire à la main |
Pourquoi Google ne vous croit pas sur parole
Un balisage est une affirmation. Google la vérifie contre ce que l'utilisateur voit. Si vous déclarez un prix de 49 € en JSON-LD et que la page affiche 59 €, vous ne trompez personne durablement — vous risquez une action manuelle pour balisage trompeur. C'est arrivé à un confrère sur un site de comparateurs : les notes d'avis étaient générées aléatoirement côté serveur. Trois semaines plus tard, les étoiles disparaissaient de tout le domaine. Pas de retour en arrière possible avant correction et réexamen.
La règle est simple, et je la répète à chaque audit : le balisage décrit le visible. Pas ce que vous aimeriez afficher. Pas une moyenne de notes calculée sur un échantillon flatteur.
Les types Schema.org qui rapportent encore quelque chose
Tous les types ne se valent pas. Certains produisent un rendu quasi systématique, d'autres sont devenus décoratifs. Voici ce que j'observe sur les sites que je suis, par ordre d'impact réel.
- Product — le plus rentable pour l'e-commerce : prix, disponibilité, note. À condition que le prix soit à jour, ce qui suppose une synchro avec le stock, pas une saisie manuelle.
- Article et NewsArticle — auteur, date de publication, date de mise à jour. Utile pour les AI Overviews, qui recyclent volontiers une date fraîche.
- LocalBusiness — horaires, adresse, téléphone. Indispensable pour une enseigne physique, mais le rendu dépend beaucoup de la fiche Google Business Profile en amont.
- BreadcrumbList — le fil d'Ariane dans les résultats. Peu spectaculaire, très fiable, presque toujours affiché quand il est correct.
- Organization — utile pour le logo et les liens sociaux, sans effet visible direct sur le classement.
Et les types qu'on m'interroge souvent : FAQPage et HowTo. Le premier a vu son affichage drastiquement réduit pour les sites commerciaux ; le second a été retiré des résultats enrichis. Baliser une FAQ reste pertinent pour la structure sémantique, mais n'attendez plus les accordéons dans Google. J'ai eu tort de promettre l'inverse à un client en 2024. Il m'en parle encore.
Mise en place : le JSON-LD ligne par ligne
Assez de théorie. Voici un bloc Product minimal mais suffisant, celui que je colle systématiquement comme point de départ :
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Chaise bistrot bois",
"sku": "CHB-2026-01",
"offers": {
"@type": "Offer",
"price": "129.00",
"priceCurrency": "EUR",
"availability": "https://schema.org/InStock"
},
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.4",
"reviewCount": "87"
}
}Trois choses à surveiller ici. Le priceCurrency en EUR, évidemment, mais surtout le format du prix : point décimal, pas virgule. Une erreur qui m'a coûté une après-midi de débogage sur un site français, parce que la locale du serveur formatait en « 129,00 ». Ensuite, availability doit pointer vers une URL Schema.org valide, pas vers « in stock ». Enfin, reviewCount doit correspondre au nombre d'avis réellement affichés sur la page.
Tester, corriger, puis surveiller
L'outil d'aide au balisage et le test des résultats enrichis servent à valider un bloc avant mise en ligne. Bien. Mais ils ne voient que l'instant présent. Le vrai suivi se fait dans la Search Console, onglet « Améliorations » : vous y voyez les types détectés sur votre site, les erreurs groupées, et surtout les éléments valides qui ont cessé de l'être. C'est là qu'on repère un déploiement qui a cassé quelque chose. C'est là que j'aurais dû regarder chez mon client paniqué plutôt que de fouiller son serveur pendant trois jours.
Un rituel que j'impose désormais à chaque projet : export hebdomadaire du rapport Améliorations, comparaison avec la semaine précédente, alerte si le volume chute de plus de 10 %. Automatisable en dix minutes, et ça rattrape les régressions avant qu'elles ne coûtent un mois de trafic.
Les pièges de 2026 et ce que je ferais différemment
Le paysage a bougé, et pas dans le sens confortable. Les AI Overviews absorbent une part croissante des clics sur les requêtes informationnelles. Résultat : un rich snippet qui brillait sur une requête « comment faire » rapporte moins qu'avant, parce que la réponse est déjà dans l'aperçu généré. Ce n'est pas une raison pour abandonner le balisage — c'est une raison de le recentrer.
Ce que je priorise aujourd'hui, concrètement :
- Le balisage transactionnel (Product, Offer) sur toutes les pages où un achat est possible.
- Les données d'entité (Organization, LocalBusiness) pour être correctement identifié dans les réponses génératives.
- La fraîcheur des dates sur les contenus éditoriaux, parce que les modèles s'en servent pour arbitrer.
- Rien sur les types restreints, sauf besoin de structure interne.
Avouons-le, personne ne sait exactement comment les moteurs génératifs pondèrent le JSON-LD. Ce que je constate, c'est que les sites dont le balisage est propre et cohérent sont cités plus souvent dans les réponses assistées. Corrélation ou causalité ? Je n'ai pas de preuve formelle, et je préfère le dire.
Ce qui reste quand on a tout oublié
Le balisage n'est pas un calque posé sur une page. C'est la version lisible par machine de ce que vous affirmez à un humain. Quand les deux divergent, Google tranche contre vous. Quand ils concordent, il vous offre parfois ces deux lignes de plus qui changent un taux de clic.
Alors avant d'ajouter un type Schema.org à votre prochaine page, posez-vous une question bête : est-ce que ce que je déclare est vrai, visible, et à jour ? Si la réponse hésite, ne balisez pas. Un résultat enrichi absent ne coûte rien. Une action manuelle, elle, se paie en mois de trafic perdu — et en conversations gênantes avec des clients qui, eux, n'avaient rien demandé.
