Vous avez déjà vu une fiche produit Amazon afficher ses étoiles jaunes, son prix et sa disponibilité directement dans Google, sans qu'on ait cliqué dessus. Ce n'est pas de la magie, et ce n'est pas non plus du référencement agressif. C'est du balisage. Une poignée de lignes de code invisibles pour vous, mais parfaitement lisibles par la machine qui décide de ce qu'elle affiche dans les résultats.
Quand j'ai commencé à m'intéresser sérieusement aux données structurées, j'ai fait l'erreur classique : copier un bout de code trouvé quelque part, le coller dans mon site, et attendre. Trois semaines plus tard, rien. Pas une étoile, pas un extrait enrichi. Le problème ? J'avais mal compris ce que je faisais. Je balisais des choses que Google n'avait aucune raison de croire. Je vous raconte tout ça, simplement, parce que la documentation officielle a un don pour transformer une idée simple en charabia technique.
Points clés à retenir
- Les données structurées sont un format standardisé qui rend l'information lisible par les logiciels, pas seulement par les humains.
- Le schema markup est l'implémentation concrète : le code que vous ajoutez à votre page pour étiqueter son contenu.
- schema.org est le vocabulaire partagé ; le markup, c'est la façon dont vous l'écrivez dans votre HTML.
- Le format recommandé par Google est JSON-LD, placé dans une balise script dédiée.
- Le balisage ne garantit jamais l'affichage d'un résultat enrichi, et ce n'est pas un facteur de classement direct.
- De fausses données structurées vous font plus de mal que pas de données du tout.
Données structurées et schema markup expliqués simplement
Trois termes circulent en permanence et tout le monde les mélange, moi le premier pendant des mois. Schema.org est le vocabulaire : un dictionnaire commun, créé pour que tous les sites du web décrivent la même chose de la même façon. Une recette reste une recette, un événement reste un événement, quel que soit le site.
Les données structurées, c'est le concept général : donner à votre contenu un format standardisé pour qu'un logiciel puisse l'analyser efficacement, ligne par ligne, attribut par attribut.
Et le schema markup ? C'est la mise en œuvre. Le code réel que vous écrivez dans votre page. Voyez ça comme la recette (schema.org), l'idée de cuisiner quelque chose de précis (données structurées) et le plat que vous servez réellement (le markup).
Qu'est-ce qu'un schéma de base de données et comment est-il structuré ?
Attention, piège terminologique fréquent. Un schéma de base de données n'a rien à voir avec le schema markup d'une page web, même si le mot "schéma" revient dans les deux cas.
Un schéma de base de données décrit l'organisation logique de vos tables : quelles colonnes existent, quel type de valeur chacune accepte, comment les tables se relient entre elles. Pensez à un plan de métro : il ne contient aucun passager, mais il définit où passent les lignes et où elles se croisent. Le schéma markup, lui, décrit le sens d'un contenu déjà présent sur une page. Deux mondes différents, un même mot.
Quels sont les formats de données structurées ?
Trois formats existent, et Google n'en privilégie vraiment qu'un seul aujourd'hui.
| Format | Où il vit | Ce qu'il faut savoir |
|---|---|---|
| JSON-LD | Dans une balise script dédiée, séparée du contenu visible | Format recommandé par Google. Facile à générer, facile à maintenir, ne touche pas à votre HTML existant. |
| Microdata | Directement greffé sur les balises HTML de votre contenu | Historiquement le premier format supporté, mais il alourdit le code et devient vite ingérable. |
| RDFa | Également dans les attributs HTML | Plus souple que Microdata sur le papier, mais rarement choisi en pratique. |
Ma position est tranchée : si vous débutez, n'utilisez que JSON-LD. J'ai perdu un temps fou à vouloir "bien faire" en testant Microdata sur un ancien site. Résultat : un code source illisible, des erreurs de balises imbriquées impossibles à traquer, et un gain finalement nul. Le JSON-LD se place dans un bloc à part, vous le modifiez sans rien casser. C'est le seul choix raisonnable.
À quoi ressemble concrètement un bloc JSON-LD ?
Voici un exemple simple et commenté, pour une page d'article de blog. C'est le type Article, l'un des plus utiles quand vous publiez du contenu rédactionnel.
<script type="application/ld+json">
{
"@context": "https://schema.org", // le dictionnaire utilisé
"@type": "Article", // le type de contenu décrit
"headline": "Titre de votre article",
"datePublished": "2026-03-14", // date de publication
"author": {
"@type": "Person",
"name": "Votre nom"
}
}
</script>Lisez-le à voix haute. Vous décrivez en clair : voici un article, voici son titre, voici quand il a été publié, voici qui l'a écrit. Aucune formule obscure. Le `@context` dit quel vocabulaire vous parlez, le `@type` dit de quoi vous parlez, le reste remplit les cases.
Vous trouverez le vocabulaire complet et tous les types disponibles en consultant la documentation de schema.org, qui liste chaque propriété attendue pour chaque objet. C'est aride, mais c'est la référence.
Quelle est la différence entre les données structurées et les données non structurées ?
Les données structurées ont un format standardisé : typiquement un tableau avec des lignes et des colonnes qui définissent clairement les attributs. Un fichier de clients avec les colonnes nom, adresse et téléphone en est l'exemple type. Parce qu'elles sont quantitatives, un logiciel les traite vite et en tire des enseignements immédiats — combien de clients au total, quelle ville en concentre le plus.
Les données non structurées, elles, résistent à ce traitement. Une liste de messages sur les réseaux sociaux, un enregistrement audio, une photo : leur contenu est là, mais rien ne dit à la machine comment le découper. Vous pouvez analyser la chose, mais il faut d'abord lui donner une forme.
Il existe une zone intermédiaire, les données semi-structurées, qui possèdent une organisation partielle sans se plier à un tableau rigide.
Schema validator : comment vérifier que votre balisage fonctionne ?
Vous ne devez jamais publier du code balisé sans l'avoir testé. Un outil de validation de schema prend l'URL de votre page, lit les données structurées qu'elle contient et vous signale les erreurs ou les avertissements. Le test des résultats enrichis de Google fait exactement cela, en vous montrant en plus quels types de résultats votre balisage rend éligibles.
Mon réflexe après chaque publication : coller l'URL, corriger ce qui remonte en rouge, ignorer ce qui remonte en jaune quand je sais pourquoi je l'ai fait. Une propriété manquante fait souvent échouer tout le bloc. C'est binaire, et c'est tant mieux.
Les types de balisage qui servent vraiment
Tous les types ne se valent pas. Voici ceux qui comptent le plus, classés par utilité réelle selon ce que j'observe sur mes propres projets.
- Article — pour les billets de blog et les actualités. Le plus fréquent, le plus simple à poser.
- Product — prix, disponibilité, avis. C'est lui qui fait apparaître les étoiles dans les résultats.
- Organization — identité de votre entreprise, logo, coordonnées. Utile pour asseoir votre entité.
- FAQPage — quand une page répond à des questions précises.
- LocalBusiness — horaires, adresse, zone desservie, pour les commerces physiques.
- BreadcrumbList — le fil d'Ariane, celui qui remplace l'URL brute par un chemin lisible dans les résultats.
Un mot sur ce fil d'Ariane, justement. Il ne rapporte pas de trafic à lui seul, mais il change la façon dont un résultat s'affiche, et j'ai remarqué une hausse mesurable des clics sur les pages où je l'avais posé proprement. Rien de spectaculaire. Mais quand vous avez des centaines de pages, ces petits gains s'additionnent.
Ce que le balisage ne fait pas
Il faut casser une croyance tenace : les données structurées ne sont pas un facteur de classement direct. Elles n'aident pas magiquement à monter dans les résultats. Elles aident la machine à comprendre ce que dit votre page, ce qui peut ensuite améliorer son affichage.
Deuxième mise en garde, plus grave : ne balisez jamais quelque chose que votre page ne contient pas. Une note de 4,9 sur un produit qui n'a aucun avis, c'est une porte ouverte à une pénalité. La règle est simple — le balisage décrit, il n'invente pas.
Et l'affichage enrichi n'est jamais garanti. Vous fournissez les données, le moteur décide. J'ai balisé des pages parfaitement valides qui n'ont jamais obtenu le moindre extrait enrichi, et d'autres, moins soignées, qui en ont obtenu. Le balisage ouvre une possibilité, il ne signe pas un contrat.
Faut-il baliser chaque page de son site ?
Non. Ciblez les pages qui ont du sens à décrire : vos articles, vos fiches produit, votre page d'accueil pour l'entité Organization, vos pages de questions fréquentes. Baliser une page de mentions légales n'apportera rien à personne. Priorisez, puis étendez.
Le vrai changement, ces derniers temps, c'est que les moteurs génératifs s'appuient eux aussi sur ces données pour comprendre et citer vos contenus. Un balisage propre devient une façon de se rendre lisible par des systèmes qui, eux, ne lisent pas votre mise en page.
La première fois que j'ai vu une de mes fiches produit afficher ses étoiles dans les résultats, j'ai passé dix minutes à vérifier que ce n'était pas un cache. C'était bien réel. Le code était là, discret, et il faisait son travail. Rien de plus, rien de moins.
Alors posez un seul balisage, sur une seule page, et validez-le. Vous verrez vite si l'idée vous parle. La plupart des gens qui abandonnent le font parce qu'ils ont voulu tout faire d'un coup, du premier coup, parfaitement. Ceux qui continuent ont commencé par une ligne.
