Le Vérificateur de Données Structurées de Screpy examine le JSON-LD d’une page publique ou de code collé. Il repère les erreurs d’analyse, répertorie les entités déclarées et signale des problèmes sur certaines propriétés de cinq types de schéma pris en charge. Utilisez le rapport pour déterminer ce qui doit être corrigé et ce qui nécessite une vérification plus large. Une syntaxe valide, des contrôles pris en charge et l’éligibilité à un résultat enrichi Google sont des questions distinctes ; un statut vert ne répond pas aux trois.
Choisir une URL de page ou du JSON-LD collé
Sélectionnez URL de la page pour examiner une page publiée, par exemple une fiche produit ou une page de contact d’entreprise. Saisissez son adresse publique HTTP ou HTTPS plutôt que de choisir systématiquement la page d’accueil : les différents modèles peuvent contenir des balisages différents. Le mode URL lit le HTML renvoyé par la page. Une page privée ou protégée par mot de passe ne fournit pas les mêmes éléments publics ; un échec de récupération ne prouve pas que ses données structurées sont défectueuses.
Sélectionnez Coller du code pour vérifier un brouillon, un script extrait ou du HTML dont vous disposez déjà. Choisissez JSON-LD pour le JSON lui-même, sans élément <script> autour. Choisissez HTML si votre entrée contient des blocs <script type="application/ld+json">. L’adresse d’un fichier JSON indépendant n’est pas une page HTML ; collez son contenu en mode JSON-LD. L’entrée collée est limitée à 256 KiB mesurés en octets UTF-8 : le nombre de caractères autorisé dépend donc du texte.
Les vérifications par URL n’exécutent pas JavaScript. Un balisage ajouté après le chargement de la page peut être absent du code source récupéré. Google peut traiter du JSON-LD injecté dynamiquement : l’absence d’un bloc dans ce rapport ne prouve donc pas que Google n’en voit aucun. Examinez le balisage rendu pertinent ou utilisez le test de fonctionnalités de Google lorsque cette distinction compte. Coller du code vérifie ce que vous avez fourni, sans établir ce que la page publiée sert réellement.
Lire le rapport de données structurées
Commencez par la couverture, puis lisez les constats et le tableau des entités. Blocs JSON-LD compte les scripts détectés dans le HTML ; le JSON-LD collé est considéré comme un bloc. Entités compte les objets typés conservés dont le JSON a été analysé avec succès ; un script peut contenir plusieurs entités. Erreurs de syntaxe compte les blocs traités qui n’ont pas pu être analysés. Ces quantités sont différentes : une page comportant trois blocs n’a pas nécessairement trois entités. Dans un rapport partiel, le nombre de blocs détectés ne prouve pas qu’ils ont tous été examinés.
Chaque ligne distingue Syntaxe et Périmètre. Une syntaxe valide en vert signifie que l’analyseur JSON a accepté le bloc. Des contrôles pris en charge en vert signifient que l’entité remplissait les conditions des contrôles de propriétés sélectionnées de cet outil. Lisez aussi ses constats : aucune de ces indications ne confirme que toutes les propriétés sont correctes. Le rouge signale les erreurs d’analyse ou les constats d’erreur, le jaune souligne les avertissements et la couverture partielle, le gris indique des éléments non pris en charge ou indisponibles. Interprétez le statut écrit en plus de la couleur.
La colonne Chemin aide à retrouver les objets imbriqués. Par exemple, $.author pointe vers l’objet auteur dans la racine, tandis que $.@graph[1] désigne le deuxième objet d’un tableau @graph. Les chemins sont relatifs à leur bloc JSON-LD : un même chemin peut donc figurer dans plusieurs scripts. Le JSON téléchargé contient des numéros de bloc pour les distinguer.
La colonne Nom lit name, pas la propriété d’affichage propre à chaque type. Un Article doté d’un headline valide peut donc avoir une cellule Nom vide. Examinez la propriété et le constat correspondants avant de considérer ce vide comme un défaut du contenu.
Corriger la syntaxe JSON avant les avertissements de propriétés
Un bloc invalide ne peut pas fournir de constats fiables sur les entités. Réparez d’abord le JSON, puis relancez la vérification avant d’interpréter les avertissements de propriétés manquantes. Les causes courantes comprennent les guillemets simples autour des noms ou des chaînes, une virgule supplémentaire après la dernière propriété, un crochet ou une accolade fermante manquante et un guillemet non échappé dans un texte. JSON utilise des chaînes entre guillemets doubles et des virgules entre les membres ; la RFC 8259 définit cette grammaire.
Cette Organization fictive est un exemple minimal de syntaxe pour Coller du code → JSON-LD :
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "Example Studio",
"url": "https://example.com/"
}
L’exemple fournit les deux propriétés recherchées par cet outil pour Organization. Ce n’est pas un modèle complet pour une fonctionnalité de recherche Google. Remplacez les valeurs fictives par les faits exacts de la page et consultez les exigences de la fonctionnalité concernée avant publication.
Un JSON valide ne suffit pas à établir que les données structurées sont utilisables. Une chaîne ou un nombre isolé peut être du JSON valide, mais ne décrit pas l’entité attendue ; l’outil indique que la racine doit être un objet ou un tableau. De même, un objet analysé sans @type déclaré peut ne produire aucune ligne d’entité. Examinez la structure réelle avant d’ajouter des propriétés uniquement pour supprimer les alertes du rapport.
Quelles propriétés de schéma sont vérifiées ?
Le Vérificateur de Données Structurées applique certains contrôles à cinq types exacts lorsque leur contexte est reconnu. Utilisez ce tableau pour comprendre un constat, sans le prendre pour une liste complète des propriétés Schema.org ou des champs obligatoires de Google.
| Type déclaré | Ce que cet outil examine | Comment utiliser le constat |
|---|---|---|
Organization |
Présence de name et url |
Vérifiez qu’ils décrivent l’organisation réelle et son site web correct. |
LocalBusiness |
Présence de name et address |
Examinez l’identité et l’adresse réelles de l’entreprise ; les composants de l’adresse ne sont pas entièrement validés. |
Article |
Présence de headline, author, datePublished et image |
Comparez les valeurs à l’article et vérifiez les formats séparément. |
Product |
Présence de name ; fourniture d’au moins une valeur parmi offers, review ou aggregateRating |
Utilisez uniquement des données produit exactes et pertinentes. N’inventez pas d’offre ou d’avis pour faire disparaître un avertissement. |
BreadcrumbList |
Tableau itemListElement non vide ; position entière positive et name textuel non vide pour chaque élément examiné |
Corrigez l’élément indiqué, puis vérifiez séparément le fil d’Ariane complet et les URL de destination. |
La plupart de ces contrôles portent sur la présence. Une valeur peut exister alors que son URL, sa date, son image, sa structure d’objet ou son contenu factuel est incorrect. Un objet vide peut satisfaire un contrôle de présence ; les valeurs constituées uniquement d’espaces ne sont pas rejetées par tous les contrôles. Un statut pris en charge ne confirme donc pas qu’une adresse, un auteur ou une offre est complet.
Les contrôles du fil d’Ariane examinent aussi les valeurs sélectionnées de ses éléments, mais ne confirment pas des positions consécutives ou uniques, des URL item correctes ou toute la sémantique ListItem. Le rapport conserve au maximum 100 constats de propriétés par entité. Un long fil d’Ariane ou une entité présentant de nombreux défauts répétés peut nécessiter un examen supplémentaire après ces constats.
Corrigez un constat dans le contexte de la page. Si l’auteur d’un article est une personne, conservez la structure exacte de l’auteur même si la Person imbriquée apparaît hors du périmètre de l’outil. Modifier un balisage véridique uniquement pour obtenir des indications vertes peut masquer le problème initial plutôt que le résoudre.
Pourquoi un balisage valide est-il non pris en charge ou partiel ?
Non pris en charge signifie que l’outil n’a pas appliqué ses contrôles de propriétés sélectionnées à cette entité. Cela ne signifie pas que Schema.org interdit le type. Par exemple, un Article pris en charge peut contenir un auteur Person imbriqué. Article reçoit ses contrôles sélectionnés, mais Person apparaît comme non pris en charge, ce qui rend la couverture partielle. Restaurant se situe également hors des cinq types exacts pris en charge, bien qu’il s’agisse d’un type d’entreprise plus précis. Conservez le type qui décrit correctement le sujet et utilisez un validateur plus large pour les contrôles restants.
Le contexte peut entraîner la même distinction. Cet outil reconnaît un contexte simple http://schema.org ou https://schema.org, avec ou sans barre oblique finale, y compris s’il est hérité d’un objet parent. Il ne résout pas les contextes sous forme d’objet ou de tableau. Ces formes peuvent être légitimes selon la spécification W3C des contextes JSON-LD. Si une entité déclare plusieurs types, tous doivent appartenir à l’ensemble pris en charge pour que ses propriétés soient vérifiées.
La couverture est également limitée. L’outil considère les 50 premiers blocs JSON-LD et conserve jusqu’à 500 lignes de résultats, y compris les lignes de blocs invalides. Il arrête le parcours au-delà de 32 niveaux d’imbrication ou de 10 000 valeurs visitées par bloc. Ces limites peuvent laisser des entités suivantes sans vérification. La détection de Microdata ou RDFa dans le HTML rend aussi le rapport partiel, car ces formats ne sont pas validés ici.
Pour de grandes entrées collées, répartissez des blocs JSON-LD complets entre des vérifications séparées ; ne coupez pas un objet au milieu, ce qui créerait une nouvelle erreur de syntaxe. Conservez la source originale et identifiez les parties couvertes par chaque rapport. Ces vérifications ne sont pas automatiquement réunies en un audit complet de la page.
Vérifier la page après correction du balisage
Comparez d’abord le balisage à ce qu’un visiteur peut lire sur la page. Vérifiez les identités, dates, adresses, détails produit et éventuels avis à partir du contenu réel. Les consignes de Google relatives aux données structurées demandent des informations pertinentes et exactes ainsi que le respect des exigences applicables aux fonctionnalités ; un analyseur ne peut pas confirmer ces faits. N’ajoutez pas de détails inventés pour satisfaire un avertissement de propriété.
Choisissez la vérification suivante selon la question encore ouverte. Utilisez le Validateur de Balisage Schema.org pour examiner plus largement le balisage Schema.org, y compris Microdata et RDFa. Il a lui aussi des limites : il ne récupère ni n’interprète les autres URL de contexte. Utilisez le Test des résultats enrichis de Google pour examiner les fonctionnalités de recherche Google prises en charge et leurs erreurs ou avertissements signalés. Réussir un test ne garantit pas l’affichage d’un résultat enrichi par Google.
Si vous préparez un balisage d’entreprise, le Générateur de Schema pour Entreprises Locales peut produire du JSON-LD à partir de vos informations réelles. Examinez la sortie avant publication. Des types d’entreprise précis et des objets PostalAddress imbriqués peuvent rester non pris en charge par cet outil ; la génération et la validation sélectionnée sont des tâches distinctes.
Après une correction, relancez la vérification pertinente sur la page publiée, pas seulement sur le brouillon. Confirmez que le balisage servi contient la modification prévue et comparez les constats restants. Utilisez Télécharger JSON pour conserver les numéros de bloc, chemins d’entités, constats et couverture de cette exécution. Gardez l’entrée et le périmètre avec l’export pour qu’un autre relecteur comprenne les éléments examinés. Un rapport sauvegardé documente une vérification ; il ne surveille pas continuellement les futures modifications de modèle ou de contenu.