Vérifier les données structurées d’un site web

Choisir une entité et un objectif précis

Identifiez ce que représente réellement la page : organisation, article, produit, événement ou liste. Décrivez l’entité principale avant d’ajouter des propriétés. Une page de service ne devient pas un produit avec prix fixe parce que le schéma existe ; Google Search ne propose plus de résultats enrichis FAQ depuis le 7 mai 2026, selon son historique officiel.

Vérifiez dans la galerie officielle des résultats enrichis de Google si un type possède une fonctionnalité prise en charge. Schema.org décrit davantage de vocabulaires que ceux utilisés pour ces affichages. Le besoin sémantique et l’éligibilité à une fonctionnalité sont deux questions distinctes.

Comparer chaque valeur au contenu publié

Confrontez nom, description, image, auteur, date, adresse, prix et disponibilité à ce que voit un visiteur. Écartez avis, notes, montants ou lieux non affichés ou non établis. Les règles de Google demandent un contenu représentatif et visible ; elles ne garantissent aucun résultat enrichi.

Pour les pages traduites, utilisez les valeurs et URL de la langue correspondante. Reprenez les dates seulement si elles décrivent la publication ou la modification réelles. Évitez de répliquer la même entité locale sur des pages qui décrivent simplement une zone desservie.

• Valeurs vérifiables sur la page.
• Dates et images cohérentes.
• Aucune promesse de fonctionnalité garantie.

Valider la syntaxe et les identifiants

Lisez le JSON-LD produit par la page finale, y compris après rendu si du JavaScript le construit. Vérifiez les champs obligatoires ou recommandés du type visé, les URL absolues, les doublons et la stabilité des identifiants @id. Le test des résultats enrichis et le validateur Schema.org répondent à des questions différentes : prise en charge Google et conformité du vocabulaire.

Une erreur de syntaxe doit être corrigée dans le gabarit ou la source de données, puis contrôlée sur plusieurs pages du même type. Une page de test unique ne révèle pas les champs vides, les caractères échappés ou les données particulières d’autres fiches.

Distinguez l’identité de l’entité de l’adresse du document qui la décrit. Dans JSON-LD, @id fournit un identifiant de nœud ; les références relatives doivent être interprétées avec leur base et leur contexte. Exemple fictif : deux descriptions utilisant la même IRI absolue https://example.com/#org désignent le même nœud, même si elles apportent des propriétés différentes. Deux organismes portant le même nom ne deviennent pas pour autant une seule entité. Évitez de réutiliser l’identifiant de l’organisation pour sa page, son auteur ou chaque établissement distinct.

Un @id contenant #org ne crée pas automatiquement un élément HTML id="org". Si vous proposez aussi un lien de navigation vers une partie de la page, testez sa cible HTML séparément. Conservez les identifiants de référence de l’entité à travers les modèles lorsque cela décrit bien la même entité, tout en gardant les pages linguistiques et leurs contenus correctement identifiés. Vérifiez ensuite les propriétés sur la page visible : JSON valide, identité cohérente et éligibilité Google restent trois contrôles différents. Aucun de ces contrôles ne garantit un résultat enrichi.

Faites défiler le tableau horizontalement pour lire toutes les colonnes. Au clavier, placez le focus sur le tableau puis utilisez les flèches.

Suivre les changements et les limites

Après publication, examinez les erreurs signalées dans Search Console lorsqu’un rapport existe pour le type utilisé. Comparez plusieurs URL et dates de crawl ; l’absence de résultat enrichi n’est pas à elle seule la preuve d’un défaut de balisage. Les fonctionnalités et critères peuvent évoluer.

Intégrez ce contrôle à la recette éditoriale : lorsqu’un contenu, une image, un prix ou un gabarit change, vérifiez la donnée structurée correspondante. Le guide de recette place cette vérification dans le parcours de publication.

• Un exemple de chaque gabarit contrôlé.
• Erreurs suivies et datées.
• Recontrôle après modification de contenu ou de code.

Aligner JSON et contenu visible

Cas proposé : le texte d’un service a été corrigé, mais une ancienne condition demeure dans le JSON de la page. Un document valide peut néanmoins décrire une autre offre.

Comparez les champs avec leur source et leur affichage. Gardez type, valeur, origine et page concernée ; séparez erreur de syntaxe, incohérence de contenu et admissibilité à une fonctionnalité de recherche.

• Identifier la source de chaque champ
• Comparer JSON et page affichée
• Conserver le résultat du contrôle

• Qualifier une donnée manquante

  Auditer et enrichir les données d’un annuaire ou d’un catalogue