Les données structurées sont un vocabulaire normalisé, Schema.org, qui permet de décrire explicitement le contenu d'une page : « ceci est un article », « écrit par telle personne », « publié à telle date ». Google lit ce balisage pour mieux comprendre vos pages — et, dans certains cas, les afficher de façon enrichie.
Pourquoi c'est utile
Deux bénéfices distincts, qu'il ne faut pas confondre :
- La compréhension. Le balisage lève les ambiguïtés. Une date dans le texte peut être une date de publication, d'événement, de péremption… Schema.org le dit sans équivoque. Google n'a plus à deviner.
- Les résultats enrichis. Certains types débloquent un affichage amélioré dans les résultats de recherche : étoiles d'avis, FAQ dépliables, fil d'Ariane, image de recette. Ces enrichissements augmentent la visibilité et le taux de clic.
Une mise au point importante : les données structurées ne sont pas un facteur de classement direct. Baliser une page ne la fait pas monter. Mais elles améliorent la compréhension et l'apparence, ce qui influence indirectement le trafic.
JSON-LD : le format recommandé
Il existe trois syntaxes (Microdata, RDFa, JSON-LD). Google recommande JSON-LD, et pour de bonnes raisons : le balisage est regroupé dans un seul bloc <script>, séparé du HTML visible. Il est donc facile à générer, à lire et à maintenir, sans polluer votre markup.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Titre de l'article",
"datePublished": "2026-07-07",
"author": { "@type": "Person", "name": "Prénom Nom" }
}
</script>Note technique pour les développeurs utilisant un moteur de template : le symbole @ de @context et @type entre en conflit avec certains moteurs (comme Blade, où @ a une signification). Pensez à échapper ou à isoler ces blocs, faute de quoi vous obtiendrez une erreur de rendu. Un oubli de ce type suffit à casser une page entière.
Les types les plus utiles
- Organization / WebSite : à déclarer une fois pour tout le site (identité, logo, contact). C'est la carte d'identité de votre domaine.
- Article / BlogPosting : pour vos contenus éditoriaux. Titre, auteur, dates de publication et de mise à jour, éditeur.
- BreadcrumbList : le fil d'Ariane. Souvent affiché tel quel dans les résultats, il clarifie votre arborescence.
- FAQPage : pour une vraie liste de questions/réponses. Attention, à n'utiliser que si le contenu est réellement visible sur la page.
- Product, LocalBusiness, Recipe, Event : des types spécialisés qui débloquent des affichages dédiés selon votre activité.
Les erreurs à éviter
Google surveille de près l'abus de données structurées, et les sanctions existent. Trois règles :
- Ne balisez que ce qui est réellement présent sur la page. Déclarer une FAQ ou des avis que l'utilisateur ne voit pas est une violation des consignes, passible d'une action manuelle.
- Restez cohérent. La date, l'auteur et le titre du balisage doivent correspondre à ce qu'affiche la page. Une incohérence détruit la confiance.
- Renseignez les champs requis. Chaque type a des propriétés obligatoires et recommandées. Un balisage incomplet ne débloque pas les résultats enrichis.
Tester avant de publier
Deux outils gratuits à utiliser systématiquement : le test des résultats enrichis de Google (pour vérifier l'éligibilité aux affichages améliorés) et le validateur Schema.org (pour la conformité au vocabulaire). Un balisage qui passe les deux est propre. Ensuite, le rapport « Améliorations » de la Search Console suit vos données structurées dans le temps et signale les erreurs sur l'ensemble du site.
Bien utilisées, les données structurées sont un investissement modeste — quelques lignes de JSON-LD par type de page — pour un site que la machine comprend mieux. Dans un web où les moteurs et les assistants s'appuient de plus en plus sur des données explicites, c'est une base qui prend de la valeur avec le temps.