Donnees structurees schema.org expliquées simplement pour enfin tout comprendre

Un client m'a envoyé un jour un mail paniqué : « Google affiche 4,2 étoiles sous mon produit alors que je n'ai jamais collecté un seul avis. C'est légal ? » La réponse est oui, et non, il n'y a pas de magie noire là-dessous. Simplement quelqu'un, avant lui, avait ajouté trois lignes invisibles dans le code de sa fiche produit. Ces trois lignes, ce sont des données structurées. Et une fois qu'on a compris à quoi elles servent, on ne peut plus voir une page web de la même façon.

Je vais vous expliquer le principe sans jargon inutile, avec un vrai bloc de code commenté ligne par ligne — parce que c'est exactement ce qui manque partout ailleurs quand on cherche « schema.org expliqué simplement ». On trouvera des définitions, rarement du concret.

Données structurées : la définition la plus simple possible

Imaginez une boîte de conserve. Sur l'étiquette, il y a écrit : « haricots verts, 400 g, origine France, à consommer avant juin ». Personne ne réfléchit : l'information est rangée dans des cases. Une donnée structurée, c'est exactement ça, mais pour une page web. On range le contenu dans des cases que la machine connaît d'avance.

Concrètement, une page HTML normale ressemble à un texte libre. Un moteur de recherche la lit et doit déduire : « Ce titre en gras est probablement le nom du plat. Ce nombre à côté d'un symbole € est probablement le prix. » Parfois il devine juste, parfois non. Avec un balisage, vous supprimez la devinette.

Le vocabulaire utilisé s'appelle Schema.org. C'est un projet collaboratif lancé à l'origine par Google, Microsoft, Yahoo et Yandex, qui ont fini par se mettre d'accord sur un dictionnaire commun plutôt que d'imposer chacun le sien. Ce dictionnaire liste des types (« Restaurant », « Article », « Événement ») et, pour chaque type, des propriétés attendues (« nom », « adresse », « date de publication »).

Schema.org et JSON-LD, c'est la même chose ?

Non, et la confusion est fréquente. Schema.org est le vocabulaire — la liste des mots autorisés. JSON-LD est le format d'écriture — la façon de présenter ces mots dans un bloc de code. Vous pouvez écrire du schema.org dans trois formats différents (Microdata, RDFa, JSON-LD). Google recommande JSON-LD depuis des années, et honnêtement, c'est le seul que je conseille de retenir. Il se place dans une balise script, isolé du reste de la page, donc il ne casse rien si vous vous trompez.

Je me souviens avoir passé une après-midi entière, au début, à écrire du Microdata directement dans mes balises HTML. Gros gâchis. Une seule erreur de parenthèse et le thème entier s'affichait de travers. Avec JSON-LD, une virgule mal placée fait échouer uniquement le bloc de données. Le reste du site continue de fonctionner.

Un exemple réel, commenté ligne par ligne

Voici, réduit à l'essentiel, le bloc que j'ajoute aujourd'hui sur n'importe quel article de blog. Les commentaires en vert sont les miens — vous ne les mettrez pas tels quels dans votre code, c'est uniquement pour la lecture.

<script type="application/ld+json">
{
  "@context": "https://schema.org",   // le dictionnaire utilisé
  "@type": "Article",                  // le type de contenu de cette page
  "headline": "Titre de l'article",
  "datePublished": "2026-03-12",
  "author": {
    "@type": "Person",
    "name": "Votre nom"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Nom du site"
  }
}
</script>

Sept propriétés, sept cases remplies. La première, @context, dit simplement « je parle en schema.org ». La deuxième, @type, répond à la question « qu'est-ce que je suis » — ici un article, mais ça pourrait être un produit, un événement, un profil d'entreprise. Les suivantes remplissent les cases correspondantes.

Ce que ça change dans la vraie vie : sur une page d'actualité ou de blog, Google peut afficher la date et l'auteur dans la liste de résultats. Sur une fiche produit, il peut afficher le prix, la disponibilité et les étoiles. C'est ce qu'on appelle un résultat enrichi. Votre position ne monte pas artificiellement, mais votre lien prend plus de place à l'écran, et le taux de clic grimpe. Sur un ancien site clients, ajouter le balisage FAQ sur cinq articles a fait bouger le taux de clic de ces pages d'environ 12 % en un mois — même position, plus de clics.

Quels types de balisage valent le coup ?

Vous n'allez pas baliser votre site entier d'un coup. Il faut choisir par ordre d'impact. Voici comment je priorise, selon ce que la page cherche à obtenir :

• Article et BlogPosting — pour tout contenu éditorial. Base quasi obligatoire.
• Product — prix, stock, note moyenne. Le plus rentable en e-commerce.
• FAQPage — une liste de questions-réponses. Attention : Google ne l'affiche plus systématiquement, mais le balisage reste lu.
• LocalBusiness, pour une vitrine avec adresse physique.
• BreadcrumbList — le fil d'Ariane. Peu spectaculaire, mais il remplace l'URL moche dans les résultats.
• Organization — à mettre une fois, sur la page d'accueil, pour clarifier l'identité du site.

Un mot sur le format FAQ : depuis quelques années, Google en affiche beaucoup moins dans les résultats, il les a resserrés. Beaucoup de blogueurs ont jeté ce balisage en criant à l'arnaque. Erreur. Le balisage aide toujours la machine à comprendre que ce bloc est un ensemble de questions-réponses — utile pour les moteurs de réponse alimentés par IA, qui recyclent ce contenu. Je continue de le poser, même sans étoiles visibles.

Comment tester, et ce qui se passe en cas d'erreur

La question que tout le monde se pose après avoir copié un bloc de code : « Est-ce que ça marche vraiment ? » Réponse courte : vous le vérifiez en deux minutes.

Google fournit un outil de test des résultats enrichis dans lequel vous collez une URL ou un morceau de code. Il affiche les données qu'il a réussi à lire et signale les propriétés manquantes. Il en existe aussi un autre, plus complet, tenu par schema.org directement, qui valide davantage de types.

Que se passe-t-il si mon balisage contient une erreur ?

Rien de dramatique. Google ignore purement et simplement le balisage et retombe sur sa lecture classique de la page. Pas de pénalité, pas de sanction manuelle. Vous perdez juste le bénéfice du résultat enrichi. La seule exception : si le balisage contredit le contenu réel — par exemple, une note de 5 étoiles alors que vous n'avez aucun avis — Google peut restreindre l'affichage. Il ne vous punit pas pour s'être trompé, il vous punit pour avoir menti.

Trois erreurs que je vois chez presque tous mes clients

Ce ne sont jamais des erreurs de syntaxe. Ce sont des erreurs de logique :

1. Baliser un contenu qui n'est pas visible sur la page. Si le prix n'apparaît nulle part dans le texte affiché, le balisage devient incohérent. Google vérifie.
2. Coller le même bloc Organization sur toutes les pages du site en dupliquant le code dans chaque gabarit, sans compte unique. Ça finit par créer des doublons d'entités que la machine ne sait pas relier.
3. Oublier de mettre à jour la date de publication modifiée. Un article réécrit en 2026 mais balisé avec une date de 2022, c'est une information fausse que vous donnez sciemment.

La troisième me fait sourire jaune : je l'ai faite pendant plus d'un an sans m'en rendre compte. Mes articles rafraîchis portaient toujours l'ancienne date de mise à jour. Aucun impact visible sur le trafic, mais un détail qui m'agaçait une fois compris.

Est-ce encore utile en 2026, avec les réponses générées par IA ?

Oui, et je dirais même plus qu'avant. Voilà le point que je défends bec et ongles : les moteurs de réponse qui composent une synthèse à partir de plusieurs sources n'inventent pas leur contenu à partir de rien — ils s'appuient sur ce qu'ils parviennent à extraire proprement. Une page dont les informations sont rangées dans des cases se fait citer plus facilement qu'une page où il faut deviner qui est l'auteur, quand la donnée a été publiée, et de quoi elle parle exactement.

Le paradoxe est là : le balisage a été inventé pour les faux résultats enrichis des moteurs de recherche classiques. Il devient, accessoirement, la meilleure prise que les IA ont pour vous attribuer un fait. Je n'ai pas de chiffre solide à vous donner là-dessus — personne n'a de mesure publique propre — mais dans mon expérience, les passages que je rédige avec un balisage soigné se retrouvent reformulés plus fidèlement que les autres.

Faut-il baliser absolument tout ?

Non, et insister là-dessus est important. Baliser cinquante types différents sur une même page ne rend pas la page meilleure, ça la rend illisible pour la machine. Deux ou trois types bien renseignés sur les pages qui comptent battent toujours vingt types approximatifs. J'ai vu un site e-commerce avec douze balisages empilés par fiche produit. Résultat : Google n'en retenait qu'un, le mauvais.

Par où commencer, concrètement, cette semaine

Voici la séquence que je suis aujourd'hui, systématiquement, quand je reprends un site :

• Je choisis une seule page prioritaire : la fiche produit qui vend le plus, ou l'article qui apporte le plus de trafic organique.
• J'écris le bloc JSON-LD à la main, en ne remplissant que les propriétés dont je suis sûr.
• Je le passe dans le validateur de Google et je corrige ce qui remonte.
• J'attends quelques semaines, je compare le taux de clic de cette page avant/après.
• Si ça bouge, j'étends le modèle au reste du site par gabarit, pas page par page.

Un détail que personne ne mentionne : la première fois, ça prend deux heures. La deuxième, vingt minutes. La troisième, vous copiez-collez un modèle que vous gardez dans un coin de votre éditeur de texte, et vous changez juste trois valeurs. Le coût réel n'est pas technique, il est de s'y mettre une bonne fois.

Et si vous vous demandez si ça vaut le déplacement pour un petit site : oui, à condition d'en attendre autre chose que des étoiles. Vous n'obtiendrez pas forcément de résultat enrichi — Google décide au cas par cas, et c'est opaque. Ce que vous obtenez à coup sûr, c'est une page que les machines comprennent sans ambiguïté. Dans un environnement où la moitié du web se bat pour être cité par des modèles qui n'ont aucune patience pour les approximations, cette clarté vaut plus que n'importe quelle astuce de référencement.

La première fois que j'ai vu un extrait enrichi s'afficher sous une page que j'avais balisée de mes propres mains, je n'ai pas crié victoire. J'ai juste regardé le prix et la note apparaître sous mon lien, et j'ai pensé : voilà, j'ai arrêté de deviner. C'est peut-être ça, au fond, l'essentiel des données structurées — apprendre à parler clairement à une machine qui, jusque-là, écoutait à moitié.