Validateur de données structurées JSON-LD

Collez du HTML ou du JSON-LD brut pour valider les données structurées FAQPage, BreadcrumbList et Article. Repérez instantanément les propriétés obligatoires manquantes et les erreurs courantes des résultats enrichis de Google.

Dernière mise à jour : 2026-09-19

Qu'est-ce que le Validateur de données structurées JSON-LD

JSON-LD est un format de balisage qui indique à Google, de manière lisible par une machine, ce qu'est réellement un contenu de page — une FAQ, un article, un fil d'Ariane, etc. Il s'écrit sous forme de JSON à l'intérieur d'une balise <script type="application/ld+json">, ce qui permet d'ajouter des données structurées sans toucher du tout au HTML visible. Correctement mis en œuvre, il peut activer des résultats enrichis dans la recherche, comme des extraits de FAQ dépliables ou des fils d'Ariane, qui tendent à améliorer le taux de clics même sans changement de classement.

Cet outil extrait automatiquement les blocs <script> du code HTML collé (ou accepte directement du JSON-LD brut) et vérifie chaque entité FAQPage, BreadcrumbList et de type Article (Article / NewsArticle / BlogPosting) par rapport aux propriétés obligatoires définies par Schema.org. Il signale également les erreurs classiques qui font silencieusement échouer les résultats enrichis de Google — par exemple lorsque acceptedAnswer.text est un objet au lieu d'une simple chaîne de caractères, ou lorsque les valeurs de position ne sont pas séquentielles. Effectuer cette vérification avant de publier, ou juste après une correction, permet de détecter ces problèmes plus tôt que d'attendre de les repérer plus tard dans Search Console.

Comment utiliser le Validateur de données structurées JSON-LD

Récupérez le code HTML ou le JSON-LD de votre page Le code HTML complet obtenu via « Afficher le code source de la page », ou simplement le contenu d'une balise <script>, fonctionnent tous deux comme entrée.
Collez-le dans le champ de saisie, ou récupérez-le depuis une URL Vous pouvez coller le texte directement, ou, pour une page déjà publiée, saisir son URL et la récupérer automatiquement.
Examinez les entités détectées et leurs résultats Si la saisie contient plusieurs blocs <script> ou plusieurs entités @type, chacune est listée et validée séparément.
Corrigez toute propriété marquée « Manquant » ou « Avertissement » Chaque propriété est marquée OK, Avertissement ou Manquant, ce qui vous permet d'aller directement à l'endroit correspondant dans votre JSON-LD d'origine pour le corriger.
Revalidez après correction, avant de publier Collez à nouveau le JSON-LD corrigé et confirmez que toutes les propriétés affichent OK avant de mettre le changement en production.

Astuces pour en tirer le meilleur parti

Pour FAQPage, acceptedAnswer.text doit toujours être une simple chaîne de caractères. Y placer un objet ou un tableau empêche les résultats enrichis de Google de l'interpréter.
Pour BreadcrumbList, gardez position comme une séquence commençant à 1 : des trous ou des doublons empêchent qu'il soit reconnu comme un fil d'Ariane valide.
Limitez le headline d'un Article à environ 110 caractères, ce qui correspond à la recommandation approximative de Google ; un titre plus long peut être tronqué dans les résultats de recherche.
Vous pouvez coller une page HTML entière : l'outil extrait automatiquement le contenu de tout bloc <script type="application/ld+json">. Coller uniquement le JSON brut fonctionne également.
Si une page contient plusieurs blocs de données structurées, conserver chacun dans sa propre balise <script> en facilite la maintenance et le débogage.

Quand cet outil est utile

Vérifier le balisage FAQPage avant sa mise en ligne

Repérez les erreurs classiques, comme un acceptedAnswer.text mal structuré, qui empêchent silencieusement l'extrait enrichi de FAQ d'apparaître, avant de publier.

Auditer le fil d'Ariane après une restructuration du site

Lorsque des catégories changent ou que des URL sont modifiées, confirmez en une seule fois que les valeurs de position du BreadcrumbList restent dans le bon ordre.

Passer en revue le schéma Article d'un article de blog

Vérifiez rapidement si le headline est trop long ou si author, datePublished ou image sont absents, les propriétés recommandées pour les pages de type article.

Retrouver la cause d'une erreur signalée par le test des résultats enrichis

Lorsque l'outil officiel de Google signale une erreur, identifiez d'abord ici précisément quelle propriété pose problème, puis corrigez la source.

Glossaire

JSON-LD: Une spécification pour écrire des données structurées au format JSON. Il est intégré comme un bloc indépendant à l'intérieur d'une balise <script type="application/ld+json">, ce qui permet d'ajouter des informations destinées aux moteurs de recherche sans modifier la mise en page HTML existante.
Schema.org: Un vocabulaire partagé pour les données structurées, maintenu conjointement par Google, Microsoft, Yahoo et d'autres. Il définit des types (@type), comme FAQPage ou Article, ainsi que les propriétés que chacun prend en charge.
FAQPage: Un type Schema.org permettant d'indiquer à Google une liste de questions et de réponses. Son mainEntity contient un tableau d'entités Question, chacune nécessitant un name (le texte de la question) et acceptedAnswer.text (le texte de la réponse).
BreadcrumbList: Un type Schema.org représentant un fil d'Ariane — la position de la page au sein de la hiérarchie d'un site. Son itemListElement contient un tableau d'entités ListItem, chacune nécessitant position, name et item.
Résultats enrichis: Des résultats de recherche améliorés qui affichent plus qu'un simple titre et une description — comme un extrait de FAQ dépliable ou un fil d'Ariane — et qui nécessitent des données structurées correctement implémentées pour apparaître.
Propriété obligatoire: Une propriété dont Google a besoin pour afficher un résultat enrichi donné ; si elle manque, le résultat enrichi n'apparaîtra tout simplement pas. Une propriété recommandée, en revanche, n'est pas strictement obligatoire mais améliore la façon dont le résultat est affiché.
Google Search Console: L'outil officiel de Google pour surveiller les performances de recherche et l'état d'indexation d'un site. Ses rapports « Améliorations » montrent comment Google interprète réellement les données structurées de vos pages publiées.

Questions fréquentes

JSON-LD stocke les données structurées sous forme de JSON dans sa propre balise <script>, complètement séparée du HTML visible. Microdata et RDFa, eux, intègrent le balisage directement dans les attributs HTML (comme itemprop), ce qui nécessite de modifier la structure HTML existante. Google recommande désormais JSON-LD, dont la simplicité de mise en œuvre en a fait le format dominant.

Les données structurées en elles-mêmes ne constituent pas un facteur de classement direct. Cependant, un balisage FAQPage ou BreadcrumbList correctement implémenté peut activer des résultats enrichis, comme des extraits de FAQ dépliables ou un fil d'Ariane dans les résultats de recherche, ce qui peut améliorer le taux de clics (CTR) même sans changement de classement.

Schema.org exige que acceptedAnswer.text soit une simple chaîne de texte. S'il est défini par erreur comme un objet ou un tableau (par exemple une structure imbriquée du type { "value": "la réponse" }), le test des résultats enrichis de Google le signalera comme avertissement ou erreur.

Oui, c'est tout à fait possible. FAQPage, BreadcrumbList, Article et d'autres types de schéma peuvent chacun être écrits dans leur propre bloc <script type="application/ld+json"> sur la même page. Cet outil détecte et valide plusieurs blocs et plusieurs entités à partir d'une seule saisie.

Utilisez les rapports « Améliorations » de la Google Search Console, ou l'outil officiel de Google de test des résultats enrichis, sur votre URL réellement publiée pour voir exactement comment Google les interprète. Cet outil est surtout utile en autocontrôle pendant la rédaction ou juste après une correction, avant la publication.

Anecdote — Pourquoi JSON-LD a remplacé Microdata et RDFa

JSON-LD (JSON for Linking Data) est né au début des années 2010 sous la forme d'un format de données liées standardisé par un groupe communautaire du W3C. Contrairement aux anciennes notations de données structurées, Microdata et RDFa, qui intègrent le balisage directement dans les attributs des éléments HTML, JSON-LD réside entièrement à l'intérieur d'une balise <script> sous la forme d'un bloc JSON indépendant. Cela signifie que les données structurées peuvent être ajoutées, modifiées ou supprimées sans toucher du tout à la mise en page HTML environnante. Google a commencé à privilégier JSON-LD comme format recommandé vers 2015, et sa documentation actuelle sur les résultats enrichis est rédigée presque entièrement autour de la syntaxe JSON-LD.

Les sections de questions fréquentes de ce site fonctionnent de la même manière : les auteurs rédigent chaque question et réponse une seule fois, et un bloc JSON-LD de type FAQPage correspondant est généré automatiquement en coulisses. Il n'est donc pas nécessaire d'écrire deux fois le même contenu, une fois pour l'accordéon lisible par les humains et une fois pour le schéma lisible par les machines, si bien que les deux ne se désynchronisent jamais comme cela arrive souvent avec un balisage dupliqué manuellement.

Même un JSON syntaxiquement valide peut échouer aux résultats enrichis s'il manque une propriété exigée par Schema.org, ou une propriété recommandée par Google. Les champs profondément imbriqués comme acceptedAnswer.text sont un exemple classique d'erreur de structure. Effectuer une telle vérification avant la publication permet de détecter ces erreurs plus tôt que de les découvrir plus tard dans le rapport « Améliorations » de Search Console.

Voir toutes les anecdotes