Les données structurées décrivent le contenu d’une page dans un vocabulaire normalisé que les moteurs de recherche savent lire. Correctement posées, elles ouvrent l’accès aux résultats enrichis — étoiles d’avis, fil d’Ariane, questions dépliables — sans rien changer à ce que voit le visiteur. Ce guide détaille le format JSON-LD, les types Schema.org réellement utiles et la marche à suivre pour les déployer et les contrôler.
Ce que sont les données structurées
Une donnée structurée est un balisage qui annote le contenu d’une page pour en expliciter le sens : « ceci est un article », « son auteur est untel », « il a été publié à telle date ». Le vocabulaire de référence est Schema.org, maintenu par un consortium réunissant Google, Microsoft, Yahoo et Yandex. Ce balisage ne modifie pas l’affichage : il s’adresse aux machines, pas au lecteur.
L’enjeu est la visibilité. Les moteurs s’appuient sur ces annotations pour générer des résultats enrichis, plus grands et plus cliquables. Elles ne constituent pas un facteur de classement direct, mais le gain de surface et de taux de clic est mesurable — un effet à suivre dans les rapports de Search Console.
JSON-LD, Microdata, RDFa : lequel choisir
Trois syntaxes coexistent pour exprimer le même vocabulaire. JSON-LD s’est imposé parce qu’il sépare le balisage du HTML : un bloc de script autonome, plus simple à générer, à injecter et à maintenir.
| Format | Où il vit | Maintenance | Recommandation |
|---|---|---|---|
| JSON-LD | Un bloc <script> autonome | Simple, découplée du HTML | Format recommandé par Google |
| Microdata | Attributs dans le HTML visible | Couplée au balisage, verbeuse | Hérité, à migrer |
| RDFa | Attributs dans le HTML | Puissante mais complexe | Cas spécifiques |
Les types Schema.org qui comptent
Le vocabulaire compte des centaines de types, mais une poignée couvre l’essentiel des besoins d’un site professionnel.
| Type | Usage | Résultat enrichi possible |
|---|---|---|
Article / NewsArticle | Contenu éditorial | Grande vignette, date, auteur |
Product + Offer | Fiche produit | Prix, disponibilité, avis |
FAQPage | Questions et réponses | Accordéon déplié sous le lien |
BreadcrumbList | Fil d’Ariane | Chemin de navigation affiché |
Organization / LocalBusiness | Identité, coordonnées | Panneau de connaissance, horaires |
Deux principes guident le choix : ne baliser que ce qui est visible sur la page, et privilégier les types qui déclenchent réellement un affichage enrichi pour l’activité concernée.
Écrire un bloc JSON-LD correct
Un bloc JSON-LD se place dans le <head> ou le <body>, dans une balise script au type dédié. Voici un exemple complet pour un article :
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Structured data with JSON-LD",
"datePublished": "2026-09-08",
"dateModified": "2026-09-08",
"author": { "@type": "Person", "name": "Simon Janvier" },
"publisher": {
"@type": "Organization",
"name": "Mail Studio",
"logo": { "@type": "ImageObject", "url": "https://www.mail-studio.com/logo.png" }
},
"image": "https://www.mail-studio.com/cover.jpg"
}Ce bloc est ensuite déclaré dans la page, seul dans sa balise :
<script type="application/ld+json">
{ "@context": "https://schema.org", "@type": "Article", "headline": "..." }
</script>Quelques règles évitent la majorité des erreurs : des dates au format ISO 8601, des URL absolues, et une cohérence stricte entre les valeurs balisées et le contenu affiché.
Les données structurées ne changent rien à ce que voit le lecteur ; elles changent la façon dont la page apparaît dans les résultats de recherche.
Générer et injecter le balisage sans se répéter
Rares sont les sites qui écrivent leur JSON-LD à la main, page par page. Trois approches cohabitent selon la stack :
- Génération côté serveur : le gabarit produit le bloc à partir des données de la page (titre, date, auteur). C’est l’approche la plus fiable, car la source de vérité est unique.
- Extension de CMS : sur WordPress, les greffons SEO posent automatiquement
Article,BreadcrumbListetOrganization. Pratique, mais à auditer : les réglages par défaut balisent parfois des types inutiles. - Gestionnaire de balises : injecter le JSON-LD par un gestionnaire de balises reste possible, mais dépend du rendu JavaScript par le moteur — moins robuste qu’un rendu serveur.
Quelle que soit la méthode, un principe prime : une seule source de vérité. Un datePublished qui contredit la date affichée est un signal négatif, pas un détail.
Les erreurs qui font échouer un balisage
La plupart des données structurées ignorées par les moteurs le sont pour des raisons répétitives, faciles à corriger une fois identifiées. Les connaître fait gagner un temps réel au moment du déploiement.
- Des propriétés requises manquantes. Chaque type impose des propriétés obligatoires : un
Productsansnamenioffersvalides n’ouvrira aucun résultat enrichi. Le test des résultats enrichis liste précisément ce qui fait défaut. - Des valeurs qui contredisent la page. Un prix balisé différent du prix affiché, une note moyenne sans avis visibles : autant de signaux qui déclenchent une action manuelle plutôt qu’un bonus de visibilité.
- Plusieurs blocs concurrents. Un thème, un greffon SEO et un gestionnaire de balises qui posent chacun leur
Organizationproduisent des doublons contradictoires. Une seule source doit générer chaque type. - Des entités non reliées. Relier les objets avec
@idévite de redéclarer l’organisation ou l’auteur d’une page à l’autre et aide les moteurs à consolider le graphe du site. - Des images non conformes. Plusieurs types recommandent des images en haute résolution et dans des ratios précis ; une URL d’image manquante ou trop petite prive l’article de sa grande vignette.
- Du contenu chargé en JavaScript. Si les données balisées n’existent qu’après exécution d’un script, le robot doit pouvoir les voir au rendu, faute de quoi le balisage décrit une page qu’il ne perçoit pas.
Un même document peut légitimement combiner plusieurs types : un article qui répond à des questions fréquentes porte à la fois Article et FAQPage. L’imbrication est permise, à condition que chaque type ajouté corresponde à un contenu réellement présent, sous peine de diluer le signal. Aucune de ces erreurs n’est fatale : toutes se détectent avant mise en ligne, dès lors que le test devient une étape systématique du déploiement.
Déployer, tester et surveiller
Avant toute mise en ligne, le test des résultats enrichis de Google valide la syntaxe et signale les propriétés manquantes. Une fois en production, le rapport « Améliorations » de Search Console suit l’indexation des balises, les avertissements et les erreurs par type.
La surveillance rejoint alors le pilotage global du site : les résultats enrichis se lisent dans les mêmes tableaux de bord que le trafic et les Core Web Vitals, aux côtés desquels ils forment le socle technique du référencement.
Point de vigilance. Baliser un contenu absent de la page, gonfler des avis ou déclarer une FAQ invisible expose à une action manuelle pour « spam de données structurées ». Le balisage doit toujours refléter fidèlement le contenu réellement visible.
Ce qu’il faut retenir
- Les données structurées annotent le contenu pour les moteurs ; elles ouvrent les résultats enrichis sans modifier l’affichage.
- JSON-LD est le format recommandé : découplé du HTML, simple à générer et à maintenir.
- Se concentrer sur quelques types utiles (Article, Product, FAQPage, BreadcrumbList, Organization) et ne baliser que le visible.
- Valider au test des résultats enrichis, puis surveiller le rapport « Améliorations » de Search Console.
Sur mes propres sites média, le balisage Article et BreadcrumbList a fait plus pour la visibilité que bien des optimisations plus spectaculaires. Mon conseil : commencer petit, un seul type propre et testé, plutôt qu’un empilement de schémas approximatifs que Google finira par ignorer. La régularité bat l’exhaustivité. — Simon Janvier
Source primaire : la documentation Google sur les données structurées et le vocabulaire de référence Schema.org.
