Un client m'envoie un mail paniqué l'an dernier : « Search Console me dit que mes données structurées sont invalides, et pourtant j'ai tout activé dans Yoast. » Je jette un œil à son code. Résultat : deux blocs JSON-LD qui se contredisent, un @type Product sur une page catégorie, et un prix saisi à la main en texte libre. Le site était propre. Le balisage était un champ de ruines.
C'est toujours la même chose avec les données structurées schema.org : tout le monde sait qu'il en faut, presque personne ne regarde ce qui est réellement publié. Et quand on regarde, on comprend pourquoi Google n'affiche aucune étoile.
Ce qui suit n'est pas une définition de plus. C'est ce que j'ai appris en nettoyant, page après page, le balisage de sites qui avaient « tout bien configuré » leur SEO.
Points clés à retenir
- Les données structurées ne font pas monter un site dans les résultats classiques : elles changent l'apparence et la compréhension du contenu.
- Le JSON-LD est le seul format que je recommande, parce qu'il se sépare proprement du HTML.
- Le vrai travail n'est pas d'ajouter du balisage, mais d'éviter les doublons injectés par les plugins.
- Un
@idet un graphe@graphbien pensés règlent 80 % des conflits d'entités. - Un type mal choisi coûte plus cher qu'aucun type : il envoie un signal faux.
À quoi servent réellement les données structurées pour le SEO
Définition sèche : les données structurées sont un balisage qui décrit le sens de votre contenu selon un vocabulaire partagé, schema.org, pour que les moteurs de recherche sachent qu'un chiffre est un prix, qu'une date est une date de publication, qu'une note est une note d'avis.
Ce qu'il faut comprendre, c'est la différence avec le HTML seul. Une page HTML dit « voici du texte et des liens ». Une page balisée dit « voici un article, signé par telle organisation, publié le tel jour, à propos de tel produit à tel prix ». Le moteur n'a pas à deviner. C'est là tout l'intérêt : vous remplacez une interprétation statistique par une déclaration explicite.
Données structurées et non structurées : la vraie différence
Vous produisez déjà des données non structurées en permanence : paragraphes, avis laissés en vrac, descriptions de produit rédigées à la main. Elles sont lisibles par un humain, exploitables difficilement par une machine. Le balisage les rend lisibles par une machine. Un avis client en texte libre est une donnée non structurée. Le même avis dans un bloc JSON-LD avec reviewRating et author devient une donnée structurée.
Est-ce que ça améliore le classement ?
Non, pas directement. Et je préfère le dire tout de suite, parce que c'est la promesse vendue par la moitié des plugins SEO. Google s'en sert pour la compréhension et pour fabriquer des résultats enrichis : étoiles, prix, fil d'Ariane, FAQ dépliée, dates. Le gain se joue sur le taux de clic et sur la place occupée à l'écran.
Sur un site de e-commerce que j'ai suivi pendant huit mois, ajouter un balisage Product complet a fait passer le taux de clic sur les pages produit d'environ 1,9 % à 2,6 %. Pas un mot de contenu n'avait changé. Position moyenne : identique. C'est ça, le vrai bénéfice, et c'est déjà beaucoup.
Pourquoi le JSON-LD est le format qui marche
Trois formats existent : Microdata (attributs glissés dans le HTML), RDFa, et JSON-LD (un bloc de script à part). Google recommande le JSON-LD, et après avoir hérité de sites en Microdata, je comprends pourquoi.
Avec Microdata, chaque balise HTML porte une partie du sens. Vous changez le template, vous cassez le balisage. Vous passez par un plugin qui réécrit le HTML, vous cassez le balisage. Le JSON-LD, lui, vit dans un bloc <script type="application/ld+json"> indépendant du rendu visuel. On peut le relire, le comparer, le tester, le versionner.
Un exemple de balisage concret
Pour un article de blog, le squelette minimal ressemble à ceci :
@context: « https://schema.org »@type: Article (ou BlogPosting)headline,datePublished,dateModifiedauthoravec un@typePerson et un@idpointant vers la fiche auteurimageen URL absolue, pas en chemin relatif
Franchement, ce n'est pas compliqué. Ce qui est compliqué, c'est ce qui arrive quand trois sources différentes en injectent chacune un morceau.
Le problème dont personne ne parle : les doublons de balisage
Voici le scénario que je rencontre dans environ un audit sur deux. Le plugin SEO injecte déjà un bloc JSON-LD Organization sur toutes les pages. Un développeur a ajouté, à la main, un second bloc Organization dans le header du thème. Un module d'avis génère un troisième bloc Product sur les pages produit. Résultat : trois entités Organization concurrentes, deux Product qui ne déclarent pas le même prix.
Google ne plante pas. Il choisit. Et il choisit rarement ce que vous vouliez.
La solution : un graphe et des identifiants
La sortie propre passe par @graph et @id. Au lieu d'empiler des blocs indépendants, vous déclarez une fois pour toutes votre Organization avec un identifiant stable (par exemple https://votresite.fr/#organization), puis vous y faites référence depuis les autres blocs via "publisher": {"@id": "..."}. Une seule entité, référencée partout.
Concrètement, ma méthode depuis deux ans :
- Lister toutes les sources de JSON-LD du site (plugin SEO, thème, plugins tiers, code maison).
- Désactiver le balisage dupliqué dans les réglages du plugin quand l'option existe.
- Centraliser dans un seul point d'injection, avec un
@graphmaître. - Vérifier page par page qu'il ne reste qu'un bloc.
Sur un site de 400 pages, ce chantier m'a pris trois jours. Le nombre d'avertissements Search Console est passé de 260 à 14. Et avouons-le, j'aurais dû commencer par là au lieu de courir après des types manquants.
Quel type schema.org pour quelle page : la matrice qui manque partout
« Est-ce que je mets Product ou Offer ? » On me pose la question à chaque mission. Voici comment je tranche, page par page.
| Type de page | Type principal | Erreur fréquente |
|---|---|---|
| Article, billet de blog | Article ou BlogPosting | NewsArticle sur du contenu non journalistique |
| Fiche produit | Product + Offer | Product seul, sans prix ni devise |
| Page catégorie | CollectionPage avec hasPart | Baliser chaque produit de la liste comme une fiche |
| Accueil | Organization + WebSite | LocalBusiness sur une entreprise sans local |
| Page de contact | LocalBusiness avec adresse complète | Organization générique, sans address |
| FAQ | FAQPage | Baliser des questions qui ne sont pas visibles à l'écran |
Product contre Offer : Product décrit la chose, Offer décrit la vente (prix, devise, disponibilité). Il faut les deux. Product seul, c'est une fiche sans étiquette de prix.
Organization ou LocalBusiness : comment choisir ?
LocalBusiness est une sous-catégorie d'Organization qui implique une implantation physique vérifiable, avec adresse et horaires. Si vous êtes une agence 100 % à distance, LocalBusiness est un mensonge que Google finira par repérer. Restez sur Organization. Je l'ai vu faire sur un site de conseil sans locaux. Ça n'a rien apporté, et ça a brouillé la fiche d'établissement.
Les erreurs que je vois le plus souvent (et comment les repérer)
Les avertissements remontés par les outils de validation se répètent. Trois reviennent systématiquement dans mes audits.
- Champ obligatoire manquant. Un Product sans
name, un Article sansheadline. Le balisage est ignoré en silence. - Prix sans devise.
pricerenseigné,priceCurrencyoublié. Invalide, tout simplement. - Dates au mauvais format.
12/03/2025au lieu d'un format ISO 8601. La date est rejetée. - URL d'image en relatif
- Type mal orthographié en minuscules
Le test des données structurées le plus utile n'est pas un outil externe. C'est l'inspection d'URL dans Search Console : elle affiche le JSON-LD tel que Google l'a lu, pas tel que vous croyez l'avoir écrit. Combien d'erreurs j'ai trouvées en comparant le code source et ce rendu ? Beaucoup trop pour l'admettre.
Et l'arrivée des moteurs génératifs
Un point qui prend de l'ampleur : les assistants qui répondent directement à la place de l'internaute s'appuient eux aussi sur du contenu balisé pour identifier les entités, les auteurs et les sources. Un site dont le graphe Organization est propre est plus simple à citer correctement. C'est encore tôt, je n'ai pas de chiffre sérieux à avancer, et je me méfie des promesses de « SEO pour IA » vendues à prix d'or. Mais l'argument tient : un balisage cohérent reste la meilleure façon de dire à une machine ce que vous êtes.
Une chose m'agace, en revanche. Tout le monde parle d'AEO et de GEO, et personne ne nettoie ses doublons de JSON-LD. C'est comme refaire la façade d'une maison dont les fondations bougent.
Par où commencer, concrètement
Si vous ne devez retenir qu'une chose : commencez par ce que vous avez déjà publié. Ouvrez l'inspection d'URL sur cinq pages représentatives, lisez le JSON-LD réel, corrigez les types et les doublons, puis seulement ajoutez de nouveaux types.
Un dernier détail qui ne se voit pas dans les tutoriels. Le jour où vous aurez un graphe propre, vous arrêterez de recevoir ces mails paniqués de clients. Et ça, franchement, ça n'a pas de prix.
