JSON-LD
JSON-LD (JavaScript Object Notation for Linked Data) est un format de données structurées, normalisé par le W3C, qui décrit le contenu d'une page dans un bloc <script type="application/ld+json"> séparé du HTML visible. Avec le vocabulaire Schema.org, c'est le format que Google recommande pour les données structurées, devant les microdonnées et RDFa, parce qu'il est le plus simple à mettre en place et à maintenir, et qu'il peut être injecté par JavaScript.
Définition détaillée de JSON-LD
JSON-LD est, selon sa spécification, « un format fondé sur JSON pour sérialiser des données liées » (Linked Data). JSON, la notation d'objets de JavaScript, est le format d'échange le plus répandu sur le web : des paires clé-valeur entre accolades, lisibles par un humain et par n'importe quel langage. JSON-LD lui ajoute une couche de sens : chaque clé est rattachée à un identifiant sans ambiguïté (une IRI, la forme internationalisée de l'URL), si bien que deux documents qui parlent d'un « auteur » ou d'un « prix » désignent la même notion, définie au même endroit.
Ce rattachement passe par quelques mots-clés réservés, reconnaissables à leur arobase :
@context: le vocabulaire qui donne leur sens aux clés. Pour le SEO, c'est presque toujourshttps://schema.org.@type: le type de la chose décrite (Article,Product,Organization,FAQPage...).@id: l'identifiant unique d'une entité, sous forme d'IRI, qui permet de la référencer depuis un autre bloc ou une autre page.@graph: un tableau d'entités indépendantes réunies dans un même bloc, reliées entre elles par leurs@id.
Le format a été normalisé par le W3C en deux temps : JSON-LD 1.0, recommandation du 16 janvier 2014, puis JSON-LD 1.1, recommandation du 16 juillet 2020, qui la remplace. Ses auteurs principaux sont Manu Sporny, Dave Longley, Gregg Kellogg, Markus Lanthaler et Pierre-Antoine Champin. En SEO, le mot désigne par extension le bloc de données structurées Schema.org écrit dans ce format, que les référenceurs opposent aux deux autres syntaxes possibles, les microdonnées et RDFa.
Pourquoi Google recommande JSON-LD
La documentation Google Search Central (mise à jour le 10 décembre 2025) prend en charge trois formats de données structurées et les juge « tout aussi acceptables pour Google, tant que le balisage est valide et correctement implémenté ». Mais elle recommande d'utiliser « le format le plus simple à implémenter et à maintenir (dans la plupart des cas, JSON-LD) », et marque JSON-LD comme « recommandé » dans sa liste. Trois raisons ressortent de cette documentation :
- La séparation du contenu visible. Les microdonnées et RDFa s'écrivent dans des attributs HTML (
itemprop,property) posés sur les éléments visibles de la page ; un changement de gabarit peut casser le balisage. Le JSON-LD, lui, « n'est pas entrelacé avec le texte visible par l'utilisateur ». - L'imbrication. Décrire le pays de l'adresse postale de la salle d'un événement est naturel en JSON, et laborieux en attributs HTML dispersés. Google cite précisément cet exemple.
- L'injection dynamique. Google « peut lire les données JSON-LD lorsqu'elles sont injectées dynamiquement dans le contenu de la page », par du JavaScript ou par un widget de CMS. Les deux autres formats ne s'y prêtent pas.
La documentation précise aussi que le bloc peut se placer « dans les éléments <head> et <body> » de la page, et qu'une même page peut en contenir plusieurs. Le vocabulaire est celui de Schema.org, dont Google ne prend en charge qu'une partie des types pour ses résultats enrichis ; l'ancien vocabulaire data-vocabulary.org n'y donne plus droit.
À quoi ressemble un bloc JSON-LD
Un article de presse ou de blog se décrit ainsi, dans une balise script dont l'attribut type vaut application/ld+json :
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Titre de l'article",
"datePublished": "2026-09-13",
"author": { "@type": "Person", "name": "Prénom Nom" },
"publisher": { "@type": "Organization", "name": "Nom du site" },
"image": "https://www.exemple.fr/images/visuel.jpg"
}
</script>Les usages SEO les plus fréquents sont l'article (Article, NewsArticle), la fiche produit (Product avec Offer), l'organisation (Organization, avec la propriété sameAs vers les profils officiels), le fil d'Ariane (BreadcrumbList), l'établissement local (LocalBusiness), l'événement, la recette, la vidéo et la FAQ. Chaque type donne accès, quand les conditions sont réunies, à un résultat enrichi ; les propriétés obligatoires et recommandées de chacun sont listées dans la documentation Google du type concerné.
Un motif répandu, adopté par les extensions SEO de WordPress, consiste à regrouper toutes les entités d'une page dans un seul bloc avec @graph : le site (WebSite), l'organisation, la page (WebPage), l'article, l'auteur et le fil d'Ariane, chacun avec un @id, l'article pointant vers son auteur et sa page par ces identifiants. Cette construction décrit les relations entre entités plutôt qu'une liste de faits isolés, ce qui sert la compréhension des entités par les moteurs.
JSON-LD, microdonnées et RDFa
Les trois formats expriment le même vocabulaire Schema.org, et Google les accepte tous. La différence tient à leur place dans le code :
- Les microdonnées ajoutent des attributs
itemscope,itemtypeetitempropaux balises HTML existantes. Le balisage est proche du contenu, donc cohérent avec lui par construction, mais il dépend du gabarit et devient vite illisible pour des structures imbriquées. - RDFa, une extension de HTML5, fonctionne sur le même principe avec les attributs
vocab,typeofetproperty. C'est aussi la syntaxe d'Open Graph. - JSON-LD vit dans son propre bloc, sans toucher au HTML. Sa faiblesse est symétrique de sa force : rien ne garantit mécaniquement que ce qu'il décrit correspond à ce que la page affiche. Cette cohérence est une obligation des consignes Google : « ne balisez pas un contenu qui n'est pas visible par les lecteurs de la page ».
En pratique, la plupart des sites récents ont adopté le JSON-LD, les CMS et leurs extensions le génèrent par défaut, et les microdonnées survivent surtout dans les thèmes anciens. Mélanger les formats sur une même page est possible, mais multiplie les risques de doublons et de contradictions.
Mettre en place et valider
- Dans un CMS : les extensions SEO de WordPress (Yoast SEO, Rank Math, All in One SEO...) génèrent un bloc JSON-LD complet ; Shopify, Wix ou HubSpot en produisent nativement. Le travail consiste alors à vérifier ce qui est généré et à compléter les types absents (FAQ, produit, événement) plutôt qu'à tout écrire.
- Sur mesure : le bloc est produit par le gabarit, côté serveur, à partir des données de la page, ce qui garantit sa cohérence avec le contenu visible.
- Par JavaScript ou Google Tag Manager : Google documente les deux voies. Avec Google Tag Manager, une balise HTML personnalisée contient le bloc, et des variables y injectent les données de la page. Google prévient toutefois que « le balisage généré dynamiquement peut rendre les crawls Shopping moins fréquents et moins fiables » pour les contenus qui changent souvent, comme le prix et la disponibilité d'un produit, et recommande le rendu côté serveur pour ces cas.
- La validation : le test des résultats enrichis de Google (Rich Results Test) vérifie qu'une page est éligible aux résultats enrichis qu'il connaît, de préférence par son URL plutôt que par un collage de code, pour tenir compte du JavaScript. Le Schema Markup Validator, hébergé par Schema.org, contrôle la syntaxe et le vocabulaire de tout balisage, y compris les types que Google n'exploite pas. Après la mise en ligne, les rapports « Améliorations » de la Search Console suivent les erreurs et les avertissements sur l'ensemble du site, et l'outil d'inspection d'URL montre le HTML rendu.
Les consignes générales de Google (mises à jour le 10 juillet 2026) rappellent le cadre : fournir toutes les propriétés obligatoires du type, préférer « moins de propriétés recommandées mais complètes et exactes » à une liste exhaustive mal remplie, ne pas bloquer les pages balisées par robots.txt ou noindex, et ne créer aucune page vide « juste pour contenir des données structurées ». Un balisage trompeur (faux avis, contenu sans rapport avec la page, usurpation) peut entraîner une action manuelle, qui retire l'éligibilité aux résultats enrichis sans affecter le classement de la page.
Les erreurs fréquentes
- Un JSON invalide : une virgule en trop, un guillemet non échappé, et tout le bloc est ignoré. Le validateur le signale en premier.
- Un balisage qui ne correspond pas à la page : une note d'avis absente du contenu visible, une FAQ balisée sans questions affichées, un prix différent de celui de la fiche. C'est le motif d'action manuelle le plus courant.
- Des blocs en double, l'un du thème, l'autre de l'extension, qui décrivent deux fois la même entité avec des valeurs différentes.
- Un
@contexten HTTP ou mal orthographié, ou un type qui n'existe pas dans Schema.org. - Croire que le JSON-LD garantit un résultat enrichi : il rend la page éligible ; Google décide ensuite de l'affichage selon la qualité de la page et le contexte de la requête.
- Baliser des types que Google ignore en attendant un effet : Google précise pouvoir faire « un usage général » des autres données Schema.org, sans engagement d'affichage.
Sources :
- Introduction to structured data markup in Google Search (Google Search Central), le 10 décembre 2025
- JSON-LD 1.1 - A JSON-based Serialization for Linked Data (W3C), le 16 juillet 2020
- Generate structured data with JavaScript (Google Search Central), le 10 décembre 2025
- General structured data guidelines (Google Search Central), le 10 juillet 2026
- Schema Markup Validator (Schema.org)
FAQ
Où placer le bloc JSON-LD, dans le head ou dans le body ?
Les deux fonctionnent : la documentation Google indique que le script JSON-LD peut se trouver dans les éléments head et body de la page. Le head est l'usage le plus courant, parce que le bloc y est lu tôt et ne dépend pas du gabarit. Une page peut contenir plusieurs blocs.
Le JSON-LD injecté par JavaScript ou Google Tag Manager est-il pris en compte ?
Oui, Google le documente : il peut lire les données JSON-LD injectées dynamiquement, et décrit la mise en place par une balise HTML personnalisée dans Google Tag Manager. Deux réserves : la vérification doit se faire par URL dans le test des résultats enrichis, pour tenir compte du rendu JavaScript, et Google prévient que le balisage dynamique peut rendre les crawls Shopping moins fréquents et moins fiables sur les prix et disponibilités.
JSON-LD ou microdonnées : lequel choisir ?
Google accepte les trois formats et recommande JSON-LD, le plus simple à implémenter et à maintenir : il vit dans son propre bloc, exprime facilement les imbrications et peut être injecté par JavaScript. Les microdonnées restent valides et n'ont pas à être migrées si elles fonctionnent, mais mélanger les deux sur une même page crée des doublons.
Comment vérifier un balisage JSON-LD ?
Avec le test des résultats enrichis de Google pour l'éligibilité aux résultats enrichis, avec le Schema Markup Validator de Schema.org pour la syntaxe et le vocabulaire de tout balisage, puis avec les rapports Améliorations de la Search Console pour suivre les erreurs sur l'ensemble du site après la mise en ligne.
Le JSON-LD améliore-t-il le classement ?
Pas directement. Les données structurées rendent une page éligible à des résultats enrichis, qui améliorent la visibilité et le taux de clic dans les résultats, et aident Google à comprendre le contenu et les entités de la page. Une action manuelle pour données structurées trompeuses retire cette éligibilité sans changer le classement de la page, ce qui montre que les deux mécanismes sont séparés.
En résumé
- JSON-LD : un format du W3C (1.0 en 2014, 1.1 en 2020) qui sérialise des données liées en JSON ; en SEO, le bloc script application/ld+json qui décrit une page avec Schema.org.
- Recommandé par Google : les trois formats sont acceptés, mais JSON-LD est le plus simple à implémenter et à maintenir, séparé du HTML visible, adapté aux imbrications et lisible même injecté par JavaScript.
- Syntaxe : @context (le vocabulaire), @type (le type), @id (l'identifiant d'une entité), @graph (plusieurs entités reliées dans un bloc) ; placement dans le head ou le body.
- Validation : test des résultats enrichis de Google, Schema Markup Validator de Schema.org, rapports Améliorations de la Search Console.
- Règle : le balisage doit correspondre au contenu visible ; un balisage trompeur entraîne une action manuelle qui retire l'éligibilité aux résultats enrichis.
Abondance c'est aussi des audits SEO, un service de contenus et des formations en e-learning !
Publié le Mis à jour le
Autres définitions :
Les outils SEO pour vous aider
