Un client m'appelle il y a deux ans, paniqué. Son concurrent direct truste la première position Google sur "meilleur logiciel de compta pour TPE" avec une fiche produit beaucoup moins riche, moins documentée, moins bien écrite que la sienne. Sauf que la sienne n'a jamais décroché un extrait enrichi. Pas une étoile. Pas un prix affiché en gras. Rien. Je lui demande s'il a implémenté du JSON-LD. Silence au téléphone. "Le quoi ?"
Voilà le problème. Les données structurées ne rendent pas votre contenu meilleur. Elles rendent votre contenu lisible par les machines. Et en 2026, les machines ont leur mot à dire sur qui apparaît dans les résultats — et surtout, sur qui apparaît dans les réponses générées par Gemini, Perplexity ou les AI Overviews. Ce n'est plus un bonus technique. C'est la différence entre être cité et ne pas exister.
Points clés à retenir
- Les données structurées décrivent votre contenu dans un format que les moteurs comprennent sans ambiguïté.
- Le format standard est JSON-LD, placé dans le
<head>de la page. - Le vocabulaire de référence s'appelle Schema.org — vous n'inventez rien, vous piochez dedans.
- Un balisage correct n'augmente jamais un CTR à lui seul : il rend possible un affichage que Google décide ensuite d'accorder.
- Mauvais balisage ou balisage trompeur = risque d'action manuelle, pas juste zéro bonus.
- L'intérêt a basculé : nourrir les moteurs IA génératifs autant que Google classique.
C'est quoi, concrètement, une donnée structurée ?
Votre page dit "Notre formation coûte 490 €, elle dure 12 heures, elle est notée 4,8 sur 5 par 62 personnes". Un humain comprend tout de suite. Un robot, non. Pour lui, vous avez écrit des mots dans un ordre quelconque. Il doit deviner lequel est le prix, lequel est la durée, lequel est l'auteur.
Les données structurées, c'est le moment où vous cessez de laisser deviner. Vous ajoutez au code un bloc qui dit explicitement : "ceci est un Cours, son prix est 490 EUR, sa durée est P12H."
Schema.org : le dictionnaire que tout le monde utilise
Vous ne créez pas votre propre vocabulaire. Il existe depuis 2011 et il est maintenu par un consortium (Google, Microsoft, Yahoo, Yandex) : Schema.org. C'est une bibliothèque de types — Article, Product, Event, LocalBusiness, FAQPage, Recipe, Person, Organization — et chacun de ces types a des propriétés attendues.
Le principe est bête comme chou : vous choisissez le type qui correspond à votre page, puis vous remplissez les propriétés obligatoires et recommandées. Un type mal choisi (baliser une recette comme un Article) ne plante pas, mais il ne déclenche rien.
Trois formats possibles, un seul à retenir
Historiquement, on balisait en Microdata ou en RDFa — c'est-à-dire dans le HTML, en collant des attributs un peu partout sur vos balises. C'était pénible à maintenir et ça cassait dès qu'un intégrateur retouchait un template.
Depuis, la recommandation officielle de Google est JSON-LD : un bloc JavaScript isolé, posé dans le <head>, qui ne touche pas à votre HTML visible. Vous pouvez le générer à la main, ou automatiquement avec un plugin si vous êtes sur WordPress, Shopify ou Webflow.
| Format | Où il vit | Maintenance | Recommandé |
|---|---|---|---|
| JSON-LD | Bloc séparé dans le head | Facile, isolé du template | Oui, par défaut |
| Microdata | Mélangé au HTML visible | Fragile dès qu'on touche au design | Non |
| RDFa | Mélangé au HTML visible | Verbeux, rarement utilisé seul | Non |
Franchement, si vous débutez, ne cherchez pas midi à quatorze heures. JSON-LD, point.
Comment implémenter un JSON-LD sans se planter
Je vais vous montrer la version minimale pour un article de blog, parce que c'est le cas le plus fréquent et celui qui rapporte le plus vite.
La structure du bloc
Un objet racine, un tableau @context qui pointe vers Schema.org, un @type qui dit ce que vous décrivez, puis les propriétés. Les champs headline, datePublished, author et image sont ceux que Google regarde en priorité pour ce type. Si l'un des quatre manque ou est faux, l'extrait ne s'affiche pas.
Erreur que j'ai commise au début : j'avais mis une URL d'image relative (/img/photo.jpg). Google attend une URL absolue. Trois semaines à me demander pourquoi mes articles n'affichaient pas de vignette alors que le balisage était "valide" selon l'outil de test. Avouons-le, j'ai relu la doc en soupirant.
Tester, encore tester
Il existe deux outils distincts, et il faut passer par les deux — je le répète parce que la moitié des gens s'arrêtent au premier :
- Le test des résultats enrichis de Google, pour vérifier que le balisage est syntaxiquement correct et éligible à un type d'extrait.
- Le rapport dans la Search Console, qui montre ce que Google a réellement traité sur votre site, avec les erreurs regroupées par type.
La différence est cruciale. Le test vous dit "votre code est bon". La Search Console vous dit "voici ce que Google a compris de vos 340 pages". On peut avoir un code impeccable et zéro résultat enrichi — parce que le type choisi ne correspond pas au contenu réel, ou parce que Google a décidé de ne pas l'afficher.
Et c'est précisément là que la plupart des articles sur le sujet vous mentent.
Non, les données structurées ne garantissent aucun résultat
C'est la phrase que je répète à chaque audit, et personne n'aime l'entendre : baliser ne suffit jamais. Google choisit, requête par requête, d'accorder ou non un affichage enrichi. Vous ne cochez pas une case, vous ne récoltez pas une étoile.
Le balisage vous rend éligible. C'est tout. Et "éligible" est déjà énorme, mais ce n'est pas "gagnant".
Ce que risque un mauvais balisage
- Un prix affiché dans le JSON-LD qui ne correspond pas au prix visible sur la page : au mieux ignoré, au pire considéré comme trompeur.
- Des avis inventés, sans utilisateurs réels derrière. C'est le cas typique d'action manuelle sur le balisage.
- Un type FAQPage posé sur des questions qui ne sont pas sur la page. Même sanction possible.
- Une date de publication modifiée à chaque micro-retouche pour gratter de la fraîcheur. Google finit par repérer le manège.
Le point commun de ces erreurs : elles essaient de faire dire au balisage autre chose que ce que contient la page. Le balisage décrit. Il ne raconte pas d'histoires.
Quels types prioriser quand on a 200 pages à traiter
Je classe toujours par valeur décroissante. Pour un site e-commerce, Product et Offer d'abord — les étoiles et le prix affiché dans le résultat font bouger le clic. Pour un site de contenu, Article et Person (l'auteur, avec ses liens vers ses réseaux et ses autres publications). Pour un site local, LocalBusiness avec les horaires et la géolocalisation. FAQPage ensuite, si et seulement si les questions sont réellement sur la page.
Et si vous devez choisir entre tout faire à moitié et faire trois types à fond ? Faites trois types à fond. Un balisage incomplet sur 150 pages ne vous rapportera strictement rien.
Pourquoi ça compte double à l'heure des moteurs IA
Revenons à mon client du début. Aujourd'hui, sa vraie question n'est plus "est-ce que j'ai des étoiles sur Google". Elle est : "quand quelqu'un demande à une IA de me recommander, est-ce que je suis cité ?"
Or, comment une IA générative décide-t-elle quelle source citer ? Elle a besoin de comprendre, sans ambiguïté, de quoi parle votre page, qui l'a écrite, quand, sur quelle entité précise. Les données structurées sont exactement ce langage-là. Le JSON-LD est devenu la carte d'identité que vous tendez à une machine qui n'a pas le temps de lire 1 800 mots pour deviner votre sujet.
Est-ce que ça garantit une citation ? Non. Est-ce que ça augmente sérieusement vos chances d'être compris et repris ? De mon expérience, oui — nettement.
Données structurées et non structurées : la vraie distinction
Une donnée non structurée, c'est votre texte brut, vos images, vos vidéos. Riche pour un humain, opaque pour un moteur. Une donnée structurée, c'est l'étiquette que vous collez sur ce contenu pour en expliciter le sens. Les deux ne s'opposent pas : la seconde décrit la première.
Une page sans balisage n'est pas "pauvre". Elle est juste silencieuse sur ce qu'elle est.
Comment mesurer si ça marche vraiment
C'est la partie où tout le monde bâcle, moi compris pendant longtemps. On implémente, on attend, on regarde vaguement le trafic, et on conclut "bof, ça n'a rien changé". Sauf qu'on n'a rien mesuré.
La seule méthode honnête : notez votre CTR moyen dans la Search Console sur un groupe de requêtes donné, sur les 28 derniers jours. Implémentez. Attendez six à huit semaines — le temps que Google recrawle, retraite et décide. Recomparez, sur les mêmes requêtes, à saisonnalité comparable.
Sur un site de services B2B que j'ai suivi, le passage d'une position 4 à une position 3 sans aucun changement enrichi a fait bouger le clic de quelques dixièmes. Sur un autre, l'affichage des avis sur la fiche produit a été bien plus net. Mais deux fois, sur d'autres projets, je n'ai strictement rien vu. Le balisage était bon. Google a simplement choisi de ne rien afficher. C'est le jeu.
Ne mesurez pas "l'effet des données structurées" en général. Mesurez un type précis, sur un groupe de pages précis, sur une fenêtre précise. Le reste, c'est de la croyance.
Par où commencer ce soir
Si vous ne faites rien aujourd'hui, faites ça : ouvrez une page de votre site qui compte, identifiez son type Schema.org, écrivez le bloc JSON-LD correspondant à la main, collez-le dans le <head>, et passez-le au test des résultats enrichis. Une page. Pas cinquante.
Ensuite seulement, industrialisez.
La vérité que je constate depuis des années, c'est que presque personne ne perd à cause d'un balisage trop ambitieux. Les gens perdent parce qu'ils ont attendu que ce soit parfait avant de commencer, pendant que leur concurrent écrivait quinze lignes de JSON et prenait la place.
Une dernière chose, et c'est peut-être le point qui compte le plus : les données structurées n'ont jamais été un levier de croissance. Elles sont une déclaration d'honnêteté. Vous dites à la machine exactement ce qu'il y a sur la page. Les sites qui gagnent sur ce terrain depuis quelques années ne sont pas ceux qui balisent le plus — ce sont ceux dont le balisage n'a jamais menti. La question que je laisserais en suspens n'est donc pas "quel type Schema ajouter", mais : votre page dirait-elle la même chose si on la lisait sans vous ?
