Un client m'appelle lundi dernier, un peu paniqué. Sa fiche produit affiche un prix en gras et une note de 4,7 étoiles dans Google. Sauf que le prix affiché est celui d'il y a huit mois, et la note vient d'un agrégateur qu'il n'a jamais consulté. Il n'a jamais touché à ses données structurées. Elles ont été générées par son thème Shopify, mal, et personne ne l'a jamais vérifié. Résultat : une fiche qui ment dans les résultats de recherche, et un client qui se demande pourquoi son taux de clic s'effondre sur cette page précise.
Voilà le vrai sujet quand on parle de mettre en place des données structurées schema.org. Ce n'est pas un exercice d'optimisation abstrait. C'est du balisage qu'un moteur de recherche va lire, afficher, et parfois mal interpréter. Et quand c'est mal fait, ça se retourne contre vous.
Points clés à retenir
- Le format JSON-LD, placé dans le
<head>, reste le choix par défaut : Google le recommande et il ne modifie pas le HTML rendu. - Un balisage doit décrire ce qui est réellement visible sur la page. Toute divergence entre le JSON et le contenu affiché est un motif de pénalité.
- La validation ne se fait pas à l'œil : Search Console, Rich Results Test, et un contrôle manuel des propriétés obligatoires.
- Sur WordPress, les plugins (Yoast, Rank Math) gèrent 80 % des cas — les 20 % restants demandent une injection manuelle.
- Le balisage bien fait influence aussi la façon dont les moteurs génératifs citent votre site.
- Une erreur de prix ou de disponibilité dans un Product coûte plus cher qu'une absence de balisage.
Données structurées schema.org : ce qu'un moteur lit vraiment
Un moteur de recherche ne « comprend » pas votre page comme vous. Il en extrait du texte, des liens, des balises, et il essaie de deviner de quoi il s'agit. Les données structurées schema.org servent à supprimer la devinette. Vous lui donnez un vocabulaire normalisé pour décrire une entité : un article, une entreprise, un produit, une recette, un événement.
Ce vocabulaire est public, maintenu collaborativement, et couvre des centaines de types. Vous n'en utiliserez jamais plus de cinq ou six. C'est une bonne nouvelle : la surface d'apprentissage réelle est minuscule.
Le mythe du « boost SEO »
Non, ajouter du JSON-LD ne fait pas remonter une page de la position 12 à la position 3. Je l'ai cru au début, j'ai balisé frénétiquement un blog entier, et j'ai constaté zéro mouvement de position. Zéro.
Ce que ça change, en revanche : la façon dont votre résultat s'affiche. Étoiles, prix, plage de dates, fil d'Ariane, FAQ dépliable. Et un résultat plus riche se clique plus souvent. Sur un site de recettes que j'ai suivi, le passage aux rich results sur une vingtaine de pages a fait grimper le taux de clic de ces URL d'environ un tiers, à position quasi identique. Le trafic venait du fait qu'on cliquait plus, pas qu'on était mieux classé.
Pourquoi les moteurs génératifs y regardent aussi
Les moteurs qui produisent des réponses synthétiques s'appuient sur les mêmes signaux pour identifier une entité : « ceci est une entreprise nommée X, située ici, avec ce numéro ». Un balisage Organization propre et cohérent sur tout le site facilite le fait d'être cité correctement. Pas cité tout court — cité sans erreur. La nuance compte.
JSON-LD, Microdata, RDFa : lequel choisir ?
Trois formats coexistent. Deux sont des reliques que l'on croise encore dans du code ancien. Un seul mérite votre attention aujourd'hui.
| Critère | JSON-LD | Microdata | RDFa |
|---|---|---|---|
| Placement | Bloc <script> dans le head ou le body | Attributs dans le HTML visible | Attributs dans le HTML visible |
| Impact sur le rendu | Aucun | Alourdit le markup, casse parfois la mise en page | Idem |
| Maintenance | Centralisée, lisible | Dispersée dans le template | Dispersée |
| Recommandation Google | Format privilégié | Toléré | Toléré |
| Intégration CMS | Simple, souvent via plugin | Nécessite d'éditer le thème | Idem |
Mon avis, et je le maintiens : JSON-LD, sans hésiter. Le bloc de script est isolé du HTML affiché, donc une erreur de syntaxe casse le balisage mais pas la page. Avec Microdata, une balise mal fermée peut casser votre mise en page entière. J'ai vécu les deux, le second est plus douloureux.
Procédure pas à pas : un balisage qui passe la validation
Voici la séquence que j'applique, dans cet ordre, à chaque nouveau type de contenu.
Étape 1 : choisir un seul type principal
Un article de blog, c'est Article. Une fiche produit, c'est Product. Une page de contact, c'est Organization plus, éventuellement, LocalBusiness. Ne cherchez pas à tout baliser d'un coup : commencez par le type qui correspond à la page, un point c'est tout.
Étape 2 : écrire le JSON-LD à la main
Oui, à la main, au moins une fois. C'est le seul moyen de comprendre ce que les plugins génèrent. Un exemple minimal pour un article :
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Titre de l'article",
"datePublished": "2026-03-14",
"dateModified": "2026-07-27",
"author": {
"@type": "Person",
"name": "Nom de l'auteur"
},
"publisher": {
"@type": "Organization",
"name": "Nom du site"
}
}
</script>Trois propriétés sont réellement obligatoires pour Article : headline, datePublished, et author. Le reste améliore la lecture. Ne mettez pas dateModified à la date du jour par automatisme — si le contenu n'a pas changé, c'est un mensonge que le moteur peut recouper.
Étape 3 : relier les entités avec @id
C'est l'étape que 90 % des implémentations sautent, et c'est celle qui fait la différence entre un balisage correct et un balisage cohérent. Sur un site qui publie beaucoup, vous finissez avec plusieurs blocs JSON-LD sur la même page : l'article, l'auteur, l'organisation, le fil d'Ariane. Sans identifiant, le moteur les traite comme des entités séparées.
Avec un @id unique, vous déclarez : « cet auteur, c'est la même personne que celle décrite ailleurs ». On utilise alors un @graph pour regrouper les nœuds. Franchement, allez-y progressivement : commencez par un bloc par type, ajoutez les @id quand vous en avez plusieurs.
Étape 4 : valider, puis corriger
Le Rich Results Test de Google vous dit si le type est éligible à un affichage enrichi. Le validateur schema.org, lui, vérifie la conformité au vocabulaire — plus strict, plus utile quand vous débutez. Et Search Console remonte les erreurs sur l'ensemble du site, ce qui est le seul moyen de repérer un problème qui ne concerne qu'une catégorie de pages.
Les pièges qui coûtent cher
Le plus fréquent, et de loin : le balisage qui ne correspond pas au contenu affiché. Un prix dans le JSON, un autre dans la page. Une disponibilité « en stock » alors que le produit est épuisé. Les moteurs comparent. Ce n'est pas une théorie, c'est un contrôle automatique.
Deuxième piège : empiler les types. J'ai vu des pages avec Product, Offer, Review, FAQPage, BreadcrumbList et Organization sur une seule fiche, dont la moitié dupliquée entre le plugin et le thème. Deux blocs qui décrivent le même produit avec des données divergentes, c'est pire que pas de bloc du tout : le moteur choisit, et il ne choisit pas toujours celui que vous voulez.
Troisième piège : oublier les propriétés obligatoires d'un sous-type. Offer sans price ni priceCurrency ne casse rien, mais ne sert à rien non plus. FAQPage sans acceptedAnswer non plus.
Que se passe-t-il si je me trompe ?
Le plus souvent, rien de grave : le balisage est ignoré, votre résultat s'affiche normalement, sans enrichissement. La sanction lourde — retrait des résultats enrichis sur tout le site — arrive quand la divergence entre balisage et contenu est répétée ou manifestement trompeuse. Un doute ? Retirez le bloc, corrigez, remettez-le.
Intégrer sans toucher au code
Tous les sites ne disposent pas d'un développeur. Bonne nouvelle : dans la majorité des cas, vous n'en avez pas besoin.
- WordPress : Yoast et Rank Math génèrent les types principaux (Article, Organization, BreadcrumbList, WebSite) automatiquement. Le piège est de croire que c'est complet — vérifiez ce qui sort réellement, page par page, avant de considérer le sujet réglé.
- Shopify : le balisage Product est produit par le thème. Il hérite donc des bugs du thème. C'est exactement le scénario de mon client de lundi.
- Injection manuelle : un champ « code personnalisé » en pied de page, ou une balise via Google Tag Manager, permet d'ajouter un bloc JSON-LD sans toucher au thème. Attention : le contenu injecté en JavaScript après le chargement n'est pas toujours lu de la même façon. Préférez une injection côté serveur quand c'est possible.
Sur un site que j'ai repris, trois plugins différents injectaient chacun leur propre bloc Organization. Trois entités du même nom, avec trois jeux d'adresses différents. Le nettoyage a pris une demi-journée et a consisté, essentiellement, à désactiver deux plugins.
Ce qui reste quand tout est bien balisé
Vous pouvez écrire le JSON-LD le plus propre du monde. Si la page est vide de substance, le balisage ne la sauvera pas. Il décrit un contenu, il ne le remplace pas.
Et puis il y a la question que personne ne pose : à quoi bon baliser ce que le moteur sait déjà déduire ? Pour un article de blog, l'utilité marginale est faible. Pour une fiche produit, une fiche d'établissement, un événement avec des dates et des lieux, ou une recette avec des temps de cuisson, elle est considérable — parce que ce sont des données que le texte a du mal à structurer sans ambiguïté. C'est là qu'il faut concentrer l'effort, pas sur les pages qui n'afficheront jamais rien de plus qu'un titre et une description.
La vraie question n'est donc pas « comment baliser tout mon site ». Elle est : sur quelles pages une donnée structurée change-t-elle concrètement ce que voit l'internaute ? Commencez par ces cinq pages. Regardez le taux de clic dans Search Console trois semaines plus tard. Vous saurez si ça valait le détour.
