Un client m'appelle un jour, un peu paniqué. Il vient de perdre ses étoiles dans Google. Deux mois plus tôt, sa fiche produit affichait quatre étoiles et demie sous le titre. Là : plus rien. Rien d'autre n'avait bougé. Le site était le même, les avis aussi. La seule différence, c'est qu'il avait changé de thème WordPress, et personne n'avait pensé à vérifier ce que le nouveau thème faisait du code que l'ancien développeur avait laissé traîner.
Ce code, c'était du JSON-LD. Et si vous ne savez pas encore ce que c'est, cet article est pour vous. Les données structurées pour débutants, ce n'est pas de la magie noire. C'est une balise qu'on colle dans une page, une façon de dire à Google « ceci est une recette », « ceci est une entreprise », « ceci est un article ». Le reste suit.
Points clés à retenir
- Les données structurées sont un format normalisé (vocabulaire Schema.org) qui décrit votre contenu aux moteurs de recherche.
- Le JSON-LD est le format recommandé aujourd'hui, et il se colle simplement dans le code de la page.
- Bien faites, elles donnent accès aux rich snippets : étoiles, FAQ, prix, fil d'Ariane.
- Mal faites ou oubliées lors d'une refonte, elles peuvent disparaître sans prévenir.
- Un test sur vingt minutes vous dit si votre balisage est valide ou non.
- On ne balise pas pour Google uniquement : les réponses générées par IA s'appuient aussi sur ces signaux.
Ce que sont vraiment les données structurées (et pourquoi ça vous concerne)
Imaginez que vous déménagez. Vous étiquetez chaque carton : « cuisine », « livres », « fragile ». Les déménageurs vont plus vite, ils font moins d'erreurs, ils savent où poser quoi. Les données structurées, c'est exactement ça, sauf que les déménageurs s'appellent Google, Bing et, de plus en plus, les assistants IA.
Concrètement, une page HTML brute, c'est du texte. Google sait le lire, mais il doit deviner : est-ce que ce « 12 € » est le prix d'un produit, le tarif d'une prestation, ou juste un chiffre dans une phrase ? Est-ce que ce paragraphe est un avis client ou une citation ? Sans balisage, le moteur devine. Parfois bien. Souvent mal.
Schema.org : le dictionnaire commun
Tout repose sur un vocabulaire partagé, Schema.org. C'est un projet né il y a une bonne quinzaine d'années, porté par les grands moteurs, qui liste plusieurs centaines de « types » et de « propriétés ». Un type, c'est une catégorie : Product, Organization, Article, Recipe. Une propriété, c'est un attribut : name, price, author, datePublished.
Vous n'avez pas besoin de connaître tout le dictionnaire. Vraiment pas. La majorité des sites vit très bien avec cinq ou six types différents.
Pourquoi JSON-LD et pas Microdata
Il existe trois formats possibles. Deux d'entre eux (Microdata, RDFa) consistent à imbriquer les balises dans le HTML visible. Ça marche, mais c'est fragile : dès qu'un développeur touche au gabarit, tout peut sauter.
Le troisième, JSON-LD, se place dans une balise <script>, invisible pour le visiteur, séparée du rendu. C'est ce que Google recommande explicitement aujourd'hui. Et c'est ce qui explique en partie l'histoire du client du début : son nouveau thème ne reprenait pas le bloc script de l'ancien.
La mise en place, pas à pas
Théorie terminée. On passe au concret.
Où coller le code
Trois emplacements possibles, selon votre situation :
- Directement dans le
<head>de la page, si vous codez le site à la main - Via un plugin spécialisé, si vous êtes sur un CMS comme WordPress — les plus connus gèrent le balisage automatiquement
- À travers une balise personnalisée dans Google Tag Manager, quand vous ne pouvez pas toucher au thème
Le deuxième cas est de loin le plus fréquent chez les débutants, et franchement le plus confortable. Un plugin, une case à cocher, et c'est réglé. Sauf que… les plugins ne couvrent pas tout. Ils gèrent très bien l'article de blog et la fiche entreprise. Ils gèrent beaucoup moins bien un schéma de type Recipe avec quinze propriétés imbriquées.
Un exemple complet : organization
Voici un bloc Organization tel que je le pose sur la plupart de mes sites. Je l'annote ligne par ligne, parce que c'est là que tout le monde se plante.
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "Nom de votre entreprise",
"url": "https://votre-site.fr",
"logo": "https://votre-site.fr/logo.png",
"contactPoint": {
"@type": "ContactPoint",
"telephone": "+33 1 23 45 67 89",
"contactType": "service client"
}
}Trois remarques. La première : @context doit toujours pointer vers schema.org, sinon rien ne fonctionne. La deuxième : l'URL du logo doit être absolue, pas relative — une erreur que j'ai faite pendant des mois sans m'en rendre compte. La troisième : contactPoint n'est pas obligatoire. Vous pouvez ne garder que le nom, l'URL et le logo.
Deux autres schémas utiles : article et fil d'Ariane
Pour un article de blog, le type Article (ou BlogPosting) attend principalement le titre, l'auteur, la date de publication et une image. Pour la navigation, le type BreadcrumbList génère le fil d'Ariane directement dans les résultats de recherche — une petite ligne de liens à la place d'une URL brute. Ça ne change pas le classement, mais ça change le taux de clic. Sur l'un de mes sites, le passage de l'un à l'autre avait fait grimper le CTR d'environ 15 % en trois semaines, à position identique.
Et pour une FAQ, le type FAQPage reste tentant. Attention : depuis plusieurs mises à jour, Google en limite fortement l'affichage et ne le réserve plus qu'à certains sites. Le balisage ne fait pas de mal, mais il ne faut plus compter dessus.
Tester, valider, corriger
Un balisage non testé est un balisage qui ne sert à rien. La bonne nouvelle, c'est que tout est gratuit et qu'il faut un quart d'heure.
- L'outil de test des résultats enrichis de Google vous dit si votre code est éligible à un affichage enrichi, propriété par propriété
- Le validateur Schema.org vérifie la conformité au vocabulaire, sans se soucier des règles d'affichage Google
- La Search Console, dans son rapport dédié, liste les erreurs détectées sur l'ensemble du site, page par page
Les erreurs les plus fréquentes que je rencontre : une virgule manquante en fin de bloc JSON (le classique), une date au mauvais format, une image trop petite pour être éligible, ou une propriété recommended oubliée alors qu'elle conditionne l'éligibilité. La Search Console ne vous le dira pas forcément — l'outil de test, oui.
Peut-on baliser une fiche produit sans être e-commerce ?
Oui, à une condition : le produit doit être réellement vendable et le prix réellement visible sur la page. Le balisage ne crée pas de contenu, il décrit du contenu existant. Si le prix n'apparaît nulle part dans la page HTML, Google considérera le balisage comme trompeur.
Les données structurées servent-elles encore à quelque chose avec les réponses générées par IA ?
C'est la question qu'on me pose le plus depuis un an. La réponse honnête : on n'a pas de certitude absolue sur la façon dont chaque moteur pondère ces signaux. Mais les assistants IA s'appuient sur des pages qui ont été correctement indexées et comprises. Un balisage propre reste une façon de clarifier votre contenu. Ça ne vous garantit rien. Ça ne vous pénalise pas.
Les erreurs que j'ai faites (et que vous pouvez éviter)
| Erreur | Conséquence observée | Ce qu'il faut faire |
|---|---|---|
| Balisage posé une fois, jamais revu | Disparition silencieuse après refonte | Vérifier après chaque changement de thème |
| Contenu balisé différent du contenu visible | Avertissement manuel, voire pénalité | Ne jamais inventer une donnée absente de la page |
| Trop de types sur une même page | Conflits, éligibilité perdue | Se limiter au type principal + un ou deux complémentaires |
| Oubli de @context | Aucun effet, aucune erreur visible | Toujours vérifier la première ligne du bloc |
Ma plus grosse erreur, pour être franc : avoir cru qu'un balisage parfait suffisait. Il ne suffit pas. Les données structurées ne remplacent jamais un contenu pauvre. Baliser une page vide, c'est étiqueter un carton de déménagement vide.
Ce qu'il faut retenir quand on débute
Commencez petit. Un bloc Organization sur la page d'accueil, un bloc Article sur vos publications, un BreadcrumbList si votre site a une hiérarchie. Testez. Notez la date du test. Recommencez dans trois mois.
Le vrai piège n'est pas technique. Il est humain : on pose le code une fois, on coche la case, et on oublie. Comme mon client, dont les étoiles ont disparu pendant six semaines avant qu'il s'en aperçoive. Le balisage, c'est une routine, pas une formalité.
Et si vous n'avez qu'une seule chose à retenir : la donnée structurée ne ment jamais sur le contenu de la page. Si elle ment, c'est vous qui payez.
