Validateur de balisage Schema

Extrais le JSON-LD d'une URL ou d'un markup collé, parcours les nodes du graph et les types imbriqués, et lis la couverture des propriétés des familles de schemas courantes.

Ce validateur de balisage schema va chercher le JSON-LD d'une URL publique ou du markup que tu colles, puis te montre ce qu'il y a vraiment dedans. Il parse chaque bloc, parcourt les tableaux et les nodes @graph, liste les valeurs @type imbriquées avec leurs références @id, et lit la couverture des propriétés pour les familles que tu croises le plus : Article, FAQPage, BreadcrumbList, Product, SoftwareApplication, Organization, WebSite et WebPage. Un bloc peut parser nickel et rester de la mauvaise structured data, mauvais type, une clé qui manque, du markup pour du contenu qu'aucun visiteur ne voit, donc les checks regardent la syntaxe, la forme du graph et la couverture d'un coup. C'est une deuxième paire d'yeux rapide, pas un substitut à la doc de Google, et il y a un rapport en clair que tu peux survoler avant que tout ça n'atterrisse dans un template en prod. Tout tourne dans ton navigateur et rien de ce que tu colles ne quitte la page.

100% dans votre navigateur. Rien de ce que vous tapez ne quitte cette page.

Labo d'audit schema JSON-LD

Colle une URL ou un bout de markup. L'outil va chercher le JSON-LD, parse chaque bloc, puis parcourt les nodes du graph et les types imbriqués pour que tu voies vraiment ce qu'il y a dedans. Tu obtiens aussi une lecture de la couverture des propriétés pour les schemas les plus courants. Honnêtement, la partie sur laquelle je m'appuie le plus, c'est le rapport en clair que tu peux survoler avant que tout ça n'atterrisse dans un template en prod.

URL à analyser

Mode d'entrée

Exemple à coller

JSON-LD ou HTML collé

L'extraction par URL lit les blocs script JSON-LD. Le mode coller ? C'est pour les brouillons, la sortie brute d'un plugin, un snippet isolé que tu testes, ou n'importe quelle page qui refuse tout simplement un fetch via le navigateur.

Un JSON valide, ce n'est que le premier test du schema

Un validateur de balisage schema devrait faire plus que te dire que le JSON parse. Voilà le truc que personne ne te dit. Un bloc peut parser nickel et rester de la mauvaise structured data. Mauvais type. Ou il oublie la seule propriété qui explique vraiment l'entité. Parfois il balise des trucs qu'un visiteur ne voit jamais sur la page, et ça, c'est un problème à part entière. Et parfois le graph n'est qu'un fouillis d'identifiants et d'objets imbriqués que personne n'aura envie de maintenir dans six mois. Donc un schema markup validator qui vaut ton temps, je trouve, doit te montrer la syntaxe et la forme du graph d'un coup, plus la couverture de contenu que tout le monde oublie.

Du coup l'outil lit le JSON-LD depuis du HTML public ou depuis ce que tu colles. Il liste chaque bloc, parcourt les tableaux et les nodes @graph, note les valeurs @type imbriquées, et passe en revue les familles de schemas habituelles : Article, FAQPage, BreadcrumbList, Product, SoftwareApplication, Organization, WebSite, WebPage. Les checks restent lisibles, c'est volontaire. Ce sont une deuxième paire d'yeux. Pas un substitut à la doc des rich results de Google ni au vocabulaire de Schema.org, et tu ne devrais pas les prendre pour ça.

Ce qu'il faut vérifier avant de publier de la structured data

Syntaxe : chaque bloc devrait parser, sans dégât de copier-coller caché qui se glisse dedans.
Adéquation du type : le type devrait correspondre à la page et à l'entité qu'un visiteur voit vraiment.
Couverture : des champs comme headline, itemListElement, acceptedAnswer, publisher. Ils ont une façon de disparaître discrètement d'un template, et tu ne le remarques que plus tard.
Forme du graph : les références @id et les nodes imbriqués devraient toujours avoir du sens une fois réutilisés à l'échelle du site.
Conformité aux règles : ne promets pas du contenu ou des avis que le visiteur ne peut pas trouver.

Un workflow schema concret

Récupère l'URL en live juste après un changement de plugin WordPress ou SEO. Les modifs de thème aussi. C'est généralement là que les choses cassent.
Ouvre le tableau des nodes du graph. Vérifie que les entités principales de la page sont bien là.
Lis l'onglet de couverture des propriétés pour le type de page qui t'intéresse.
Colle un snippet de brouillon si tu veux tester le markup avant qu'il n'atterrisse dans le template.
Et quand l'éligibilité réelle ou la validation du vocabulaire compte vraiment, va lancer les outils officiels de rich results ou de Schema.org.

Questions fréquentes

Un schema valide garantit-il un rich result ?

Non. Un markup valide qui respecte les exigences du moment peut rendre une page éligible, bien sûr. Que la fonctionnalité s'affiche réellement, c'est une autre histoire, et celle-là dépend des systèmes de recherche et de leurs propres règles. Éligible, ce n'est pas la même chose qu'affiché.

Pourquoi cet outil se concentre-t-il sur le JSON-LD ?

Parce que c'est ce que la plupart des CMS et plugins SEO modernes recrachent, et tu peux l'inspecter sans entremêler des annotations dans ton HTML visible. Le microdata et le RDFa existent encore, je sais. Ils restent juste en dehors de cet audit, qui ne fait que du JSON-LD.

Chaque page devrait-elle utiliser autant de types de schema que possible ?

Non, et honnêtement cet instinct se retourne contre toi. Un petit graph qui décrit la page avec précision est bien plus facile à vivre qu'un graph gonflé que tu as bourré de types juste pour courir après des fonctionnalités.

Quand devrais-je tout de même lancer les validateurs officiels ?

Dès que l'éligibilité réelle ou la justesse du vocabulaire compte. Cet outil est une deuxième paire d'yeux rapide sur la syntaxe, la forme du graph et la couverture des propriétés. Pour une décision de fonctionnalité, colle ton markup dans le Test des résultats enrichis de Google et vérifie le validateur Schema.org face aux exigences en vigueur.