JSON-LD : données structurées exprimées en JSON lié

Format fondé sur JSON pour les données structurées liées, généralement intégré dans un script afin qu'une page décrive des entités et leurs relations sans modifier le HTML visible.

Format fondé sur JSON pour exprimer des données structurées liées, généralement intégré dans un élément script afin qu'une page décrive des entités et leurs relations sans modifier le HTML visible.

La décision et sa limite

Le JSON-LD sérialise des données liées au format JSON. Sur les pages web, il est souvent placé dans un élément script et utilise le vocabulaire Schema.org pour décrire les mêmes entités que le lecteur voit : un article, un produit, une organisation, un fil d'Ariane ou un événement. C'est un format de représentation, et non une promesse de résultat enrichi. Le graphe doit être syntaxiquement valide et concorder avec les faits visibles et à jour de la page.

Le schéma relie les faits visibles de la page aux propriétés de données structurées qui les décrivent.

Ce qu'il faut inspecter

Récupérez le HTML rendu plutôt que de supposer que le gabarit source a survécu au déploiement. Analysez le JSON-LD, identifiez chaque nœud et ses identifiants, puis comparez les propriétés importantes avec la page visible. Vérifiez que les URL répondent, que les références pointent vers les entités voulues, et que des valeurs comme les dates, les prix, la disponibilité, l'auteur et l'image ne sont pas périmées. Interprétez les avertissements du validateur dans leur contexte : un message du validateur est un indice à examiner, et non automatiquement un défaut.

Une démarche de mise en œuvre

Choisissez le type Schema.org le plus petit et adapté, décrivez d'abord l'entité principale, et ajoutez les entités liées uniquement lorsque la page expose leurs faits. Générez les valeurs à partir de la même source structurée que le gabarit visible, dans la mesure du possible. Validez une page représentative après la mise en production, puis ajoutez des contrôles de non-régression pour les gabarits qui produisent beaucoup de pages. Gardez les contrôles du sitemap, de la balise canonical et du robots.txt séparés de la validation JSON-LD.

Erreurs et limites de mesure

Le piège typique est le « théâtre du schéma » : ajouter un vocabulaire que la page ne justifie pas, dans l'espoir de forcer une fonctionnalité de recherche. Des propriétés cachées, inventées ou contradictoires créent un risque de maintenance et rendent le graphe moins fiable. Je valide d'abord les données structurées par rapport à la page visible, puis j'inspecte le graphe. Je corrige les vraies erreurs de vocabulaire ou de référence, et non ce qui rend simplement le contrôleur silencieux.

Exemple d'implémentation détaillé. Pour un article éditorial, commencez par l'enregistrement visible : titre, signature, date de publication, image principale, URL canonique et identité de l'éditeur. Modélisez cet article en JSON-LD à partir des mêmes champs de contenu qui rendent la page. Donnez à l'article un identifiant stable, et ne liez l'éditeur et l'image que si ces entités existent réellement et sont résolvables. Si l'auteur, la date ou l'image n'apparaissent pas sur la page visible, ne les inventez pas dans le graphe pour satisfaire un validateur.

Critères de contrôle. Récupérez le HTML rendu après déploiement, extrayez chaque script JSON-LD et analysez chaque graphe. Comparez le titre, la date, l'image, l'URL et l'auteur avec la page telle que la voit l'internaute. Vérifiez que les identifiants et les URL renvoient aux ressources voulues, et qu'un article ne décrit pas par erreur une autre entité du gabarit. Lancez le test de données structurées pertinent, mais classez les constats : une erreur d'analyse, un écart de vocabulaire, une recommandation facultative manquante et une note d'éligibilité à une fonctionnalité de recherche ne sont pas la même chose.

Erreurs courantes. Ne collez pas un bloc de schéma générique sur chaque page, et ne marquez pas un service, une catégorie et un produit comme étant la même entité principale. N'utilisez pas le JSON-LD pour masquer des prix, des notes, des stocks, des avis ou des auteurs que les utilisateurs ne voient pas. Un test de résultat enrichi ne peut pas vérifier la balise canonical, le robots.txt, le sitemap ni la véracité du contenu : ces points doivent figurer aussi dans le contrôle de mise en production. Le JSON-LD aide à décrire une page ; il ne compense pas une page inaccessible ou peu utile.

FAQ

Le JSON-LD garantit-il des résultats enrichis ?
Non. Il aide les moteurs de recherche à comprendre les données structurées éligibles, mais l'affichage des résultats enrichis reste à la discrétion du moteur de recherche.
Le JSON-LD doit-il reprendre les faits visibles ?
Oui. Les principales données structurées doivent correspondre à la page que voit le visiteur.
Comment valider le JSON-LD ?
Inspectez le HTML rendu, analysez le JSON, comparez-le au contenu visible et utilisez le validateur pertinent comme outil de diagnostic, et non comme unique contrôle.