Validateur JSON-LD

Collez un bloc JSON-LD (avec ou sans balises <script>) : la syntaxe est vérifiée, et les champs requis/recommandés sont contrôlés pour les types Schema.org les plus courants.

Valide

Product

  • name — Nom du produit (requis, présent)
  • image — Image du produit (recommandé, présent)
  • description — Description du produit (recommandé, présent)
  • offers — Offre associée (prix, disponibilité) (recommandé, présent)

Ce que valide un contrôle JSON-LD

Valider un JSON-LD, c'est vérifier deux choses distinctes. D'abord la syntaxe JSON : accolades, virgules, guillemets doubles, absence de virgule finale. Ensuite la conformité au vocabulaire Schema.org : pour le @type déclaré, les propriétés attendues sont-elles présentes ? Un bloc peut être un JSON parfait et un balisage inutilisable.

L'outil enchaîne ces deux passes. Si le texte collé contient une balise <script type="application/ld+json">, son contenu est extrait automatiquement — inutile de nettoyer avant de coller. En cas d'erreur de syntaxe, la position signalée par le moteur JavaScript est convertie en numéro de ligne et de colonne. Si le JSON est valide, tous les objets porteurs d'un @type sont collectés, y compris ceux imbriqués dans un @graph, et chacun est confronté à la liste de champs de son type.

Champs contrôlés par type

@typeRequisRecommandés
FAQPagemainEntity
Questionname, acceptedAnswer
Articleheadline, imagedatePublished, author
Productnameimage, description, offers
HowToname, step
BreadcrumbListitemListElement
Eventname, startDatelocation
Recipenameimage, recipeIngredient, recipeInstructions
LocalBusinessname, addresstelephone
Organizationnameurl, logo

Un champ requis manquant remonte en erreur, un champ recommandé manquant en avertissement. Tout autre @type est reconnu comme non couvert : la syntaxe est validée, les champs ne sont pas contrôlés.

Ce que cet outil ne vérifie pas

Il ne contrôle ni la valeur des propriétés (format de date, devise, URL absolue), ni la conformité au vocabulaire Schema.org complet, ni les règles d'éligibilité propres à chaque résultat enrichi Google — notamment la règle la plus souvent enfreinte : les données balisées doivent correspondre à un contenu réellement visible sur la page. Baliser un prix ou une note absents de la page expose à une action manuelle pour spam de données structurées.

Le flux de travail raisonnable : rédiger le balisage avec le générateur JSON-LD, le relire ici à chaque itération, puis passer un test unique avec le Rich Results Test de Google avant publication.

Collez le bloc dans le champ ci-dessus : l'analyse est faite en JavaScript dans votre navigateur. Le texte est d'abord débarrassé de son éventuelle balise <script type="application/ld+json">, passé à JSON.parse pour la syntaxe, puis parcouru pour retrouver tous les objets porteurs d'un @type — y compris ceux imbriqués dans un @graph — et confronter chacun aux champs attendus pour son type. Rien n'est envoyé sur le réseau.

Une erreur bloquante signale un JSON syntaxiquement invalide ou un champ requis manquant pour le type Schema.org déclaré : le résultat enrichi correspondant a de fortes chances d'être refusé. Un avertissement signale un champ recommandé absent : le balisage reste valide, mais Google peut afficher un résultat moins complet ou juger la page moins éligible.

Un balisage valide et complet ne garantit jamais l'affichage. Google applique ensuite ses propres critères : qualité et cohérence du contenu de la page, politique du type de résultat concerné, requête et appareil de l'utilisateur. Certains types ne donnent d'ailleurs plus lieu à aucun affichage enrichi — HowTo a été retiré, et FAQPage est réservé à un petit nombre de sites institutionnels et de santé faisant autorité.

Dix types parmi les plus utilisés en SEO : FAQPage, Question, Article, Product, HowTo, BreadcrumbList, Event, Recipe, LocalBusiness et Organization. Pour tout autre @type, seule la syntaxe JSON est vérifiée et le type est signalé comme non couvert — le vocabulaire Schema.org complet compte plusieurs centaines de types et des milliers de propriétés.

Non : il contrôle la présence des propriétés attendues, pas la validité de leur contenu. Une date au mauvais format, un prix en texte libre ou une URL relative dans image passeront le contrôle de présence tout en étant refusés par Google. C'est une relecture de structure, à compléter par un test officiel.

Non. Il sert à repérer immédiatement une erreur de syntaxe ou un champ manquant pendant la rédaction, sans quitter votre poste ni exposer une page en préproduction. Seul l'outil officiel de Google fait foi pour valider l'éligibilité réelle d'une page publiée.

Autres outils · SEO