Comment valider les données structurées sans les outils Google

La validation des données structurées est devenue étrangement dépendante des outils orientés Google. C’est compréhensible : de nombreuses équipes ajoutent du JSON-LD parce qu’elles veulent des résultats enrichis, et les outils de test de Google sont familiers. Mais les données structurées ne sont pas un format Google. Il s’agit généralement de JSON-LD utilisant le vocabulaire Schema.org, intégré dans du HTML, interprété par de nombreux consommateurs et maintenu par votre propre flux de publication.

Si vous validez uniquement à travers le prisme d’un moteur de recherche, vous pouvez manquer des problèmes fondamentaux : JSON invalide, données qui disparaissent après le rendu, prix de produits obsolètes, URL canoniques contradictoires ou balisage techniquement valide mais sémantiquement absurde.

Un meilleur flux de travail commence par les standards. Validez les données en tant que données, puis validez le vocabulaire, puis validez la page telle qu’elle existe en production.

Que validez-vous réellement ?

Les « données structurées » ne sont pas une seule chose. Sur la plupart des sites web, elles comportent quatre couches :

1. Syntaxe JSON — le code peut-il être analysé ?
2. Modèle JSON-LD — se développe-t-il en données liées significatives ?
3. Vocabulaire Schema.org — les types et propriétés sont-ils plausibles ?
4. Vérité au niveau de la page — le balisage correspond-il à ce que les utilisateurs et les robots d’exploration peuvent voir ?

Les outils Google se concentrent surtout sur la quatrième couche, ainsi que sur l’éligibilité aux résultats enrichis propres à Google. Utile, oui. Complet, non.

Par exemple, ceci peut être du JSON-LD valide tout en restant de mauvaises données structurées :

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Best winter jackets",
  "datePublished": "2026-01-12",
  "author": {
    "@type": "Organization",
    "name": "Editorial Team"
  }
}

Rien n’est cassé ici. Mais si la page visible présente un titre différent, aucune attribution d’auteur et une date de dernière modification qui contredit le balisage, vous avez un problème de qualité plutôt qu’un problème de syntaxe.

Étape 1 : analysez le JSON avant de penser au SEO

Commencez par le contrôle ennuyeux : le JSON peut-il être analysé ?

Le JSON-LD intégré dans le HTML casse souvent à cause de petites erreurs de modèle :

• virgules finales
• guillemets non échappés dans les noms de produits
• retours à la ligne invalides à l’intérieur de chaînes
• accolades manquantes après des champs conditionnels
• blocs script dupliqués à cause de l’héritage de mise en page
• plugins CMS produisant des objets partiels

Pour les vérifications locales, vous n’avez pas besoin d’une plateforme SEO. Utilisez les outils déjà présents dans votre pile de développement.

En JavaScript :

const blocks = [...document.querySelectorAll('script[type="application/ld+json"]')];

for (const block of blocks) {
  try {
    JSON.parse(block.textContent);
  } catch (error) {
    console.error('Invalid JSON-LD:', error.message, block);
  }
}

Dans la CI, extrayez le contenu des scripts depuis le HTML rendu et analysez-le comme du JSON. Cela permet de détecter de nombreux problèmes avant qu’ils n’atteignent la production.

Le point important : faites-le avant toute validation Schema.org. Un validateur de vocabulaire ne peut pas aider si les données ne sont pas du JSON valide.

Étape 2 : vérifiez le comportement JSON-LD, pas seulement la syntaxe JSON

Un JSON valide n’est pas automatiquement du JSON-LD valide. JSON-LD utilise des concepts comme @context, @type, @id et les relations de graphe. S’ils sont mal formés, les analyseurs peuvent interpréter vos données différemment de ce que vous aviez prévu.

Au minimum, confirmez que :

• chaque bloc possède un @context approprié
• les entités principales ont des valeurs @type claires
• les entités répétées utilisent des valeurs @id stables lorsque c’est utile
• les entités imbriquées sont reliées logiquement
• les tableaux sont utilisés lorsque plusieurs valeurs sont possibles

Pour les sites plus volumineux, les identifiants stables sont particulièrement utiles. Si votre organisation apparaît dans les données Article, Product, BreadcrumbList et FAQPage, utiliser le même @id aide les consommateurs à comprendre qu’il s’agit de références à la même entité, et non de quatre organisations sans lien portant le même nom.

Un modèle courant ressemble à ceci :

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Example Ltd",
  "url": "https://example.com/"
}

Vous n’essayez pas ici d’impressionner un validateur. Vous rendez vos données moins ambiguës.

Étape 3 : validez par rapport au vocabulaire Schema.org

Une fois que le JSON et la structure JSON-LD sont solides, vérifiez le vocabulaire.

Le validateur Schema.org est utile parce qu’il teste les termes Schema.org plutôt que les règles de résultats enrichis d’un seul moteur de recherche. Il peut montrer si les propriétés sont reconnues, si les types sont interprétés comme prévu et si vos structures imbriquées ont du sens.

C’est ici que vous repérez des erreurs comme :

• publishingDate au lieu de datePublished
• imageUrl là où image est attendu
• un balisage Product sur une page de catégorie qui n’est pas un produit
• AggregateRating sans élément évalué significatif
• Person utilisé pour un compte de marque

Soyez prudent avec les avertissements. Schema.org est volontairement flexible. Un validateur peut autoriser une propriété qui n’est pas utile pour votre cas d’usage, ou signaler quelque chose qui est facultatif. Traitez la validation comme un indice, pas comme un verdict.

Règle pratique : si une propriété aide une machine à comprendre la page plus précisément, gardez-la. Si elle existe seulement parce que quelqu’un l’a copiée depuis un générateur d’extraits, remettez-la en question.

Étape 4 : comparez le balisage au contenu visible

Les moteurs de recherche et autres consommateurs de données ont tendance à se méfier d’un balisage qui ne correspond pas à la page. Plus important encore, les utilisateurs méritent de la cohérence.

Pour chaque type de données structurées, comparez le balisage avec la page visible :

Article et BlogPosting

Vérifiez que le titre, l’auteur, la date de publication, la date de modification, l’image et l’éditeur sont visibles ou raisonnablement déductibles. Si vous publiez du contenu assisté par IA, vos données structurées ne doivent pas servir à blanchir une attribution d’auteur floue. Nous avons écrit séparément sur la divulgation honnête de l’IA sur un petit site web, et le même principe s’applique ici : les métadonnées doivent clarifier, non obscurcir.

Product

Vérifiez le nom, le prix, la disponibilité, la devise, les variantes, les notes et le nombre d’avis. Les données structurées de produits sont particulièrement susceptibles de devenir obsolètes, car les prix et l’état des stocks changent en dehors du CMS.

LocalBusiness

Vérifiez le nom, l’adresse, le numéro de téléphone, les heures d’ouverture et la zone de service. Si votre pied de page dit une chose et votre JSON-LD en dit une autre, le JSON-LD n’est pas « meilleur ». Il est contradictoire.

BreadcrumbList

Vérifiez que les positions du fil d’Ariane correspondent au fil visible et que les URL sont canoniques, explorables et non redirigées inutilement.

Ce n’est pas un travail glamour. C’est aussi là que de nombreux problèmes de données structurées sont trouvés.

Étape 5 : validez la page rendue, pas votre modèle

De nombreux sites génèrent le JSON-LD au moyen de JavaScript, de gestionnaires de balises, de couches de personnalisation ou de l’hydratation de composants. Cela signifie que le fichier de modèle peut ne pas représenter ce qu’un robot d’exploration ou un navigateur voit réellement.

Validez le HTML rendu dans au moins trois états :

• build de développement local
• URL de préproduction ou d’aperçu
• URL de production

Utilisez les DevTools du navigateur pour inspecter le DOM final. Recherchez application/ld+json et copiez le contenu exact du script qui existe après le rendu. Si le balisage rendu côté serveur diffère du balisage hydraté, décidez quelle version vous attendez que les consommateurs lisent.

Vérifiez aussi si les données structurées sont dupliquées. Les blocs Article ou Product dupliqués sont fréquents lorsqu’un plugin CMS et un composant personnalisé émettent tous deux du schéma. La duplication n’est pas toujours fatale, mais la duplication contradictoire pose problème : deux prix, deux auteurs, deux dates de publication ou deux URL canoniques.

C’est similaire à la lecture de rapports de performance et de diagnostics : la première tâche n’est pas de paniquer, mais de séparer le signal du bruit. La même habitude aide lorsque vous lisez un rapport Lighthouse sans paniquer — même si les données structurées elles-mêmes ne doivent pas être réduites à un score unique.

Étape 6 : vérifiez les détails de transport en production

Les données structurées peuvent être parfaites dans votre source et tout de même échouer en production parce que la page n’est pas accessible de la manière que vous supposez.

Vérifiez que :

• le code de statut final est 200, et non un soft 404
• l’URL canonique correspond à la page que vous validez
• les redirections sont intentionnelles et stables
• les directives robots ne bloquent pas l’indexation là où elle est attendue
• le HTML n’est pas remplacé par une page d’erreur pour certains agents utilisateurs
• les pages mises en cache ne servent pas de JSON-LD obsolète

C’est ici que l’inspection HTTP compte. Si une page produit passe par trois URL avant d’atteindre une destination canonique, validez la page finale, pas la première URL copiée depuis le CMS. Pour la mécanique brute, notre guide sur le débogage des redirections et des en-têtes HTTP en production est un compagnon utile.

Les données structurées ne vivent pas dans le vide. Elles voyagent avec les en-têtes, les redirections, la mise en cache, les balises canoniques et les directives robots.

Étape 7 : ajoutez des tests de données structurées à votre processus de publication

La validation manuelle convient pour une page. Elle ne passe pas à l’échelle sur des centaines ou des milliers d’URL.

Une suite de tests automatisés simple peut détecter les erreurs les plus coûteuses :

• récupérer des URL représentatives de chaque type de modèle
• extraire tous les blocs JSON-LD
• les analyser avec JSON.parse
• vérifier les champs requis pour chaque type de page
• vérifier que les dates sont des chaînes ISO 8601 valides
• vérifier que les URL sont absolues et canoniques
• vérifier que les prix et la disponibilité existent pour les pages produit
• vérifier que les entités dupliquées n’entrent pas en conflit

Vous pouvez l’exécuter dans la CI pour les modèles et selon un calendrier pour les URL de production. Le but n’est pas de prouver que chaque fonctionnalité de résultat enrichi apparaîtra. Personne en dehors du moteur de recherche ne peut le promettre. Le but est de garder vos propres données exactes, analysables et cohérentes.

<!-- tool-cta:start -->

💡 Essayez ceci : Avant de valider la logique du schéma, passez votre JSON-LD dans le JSON Formatter afin de détecter les erreurs de syntaxe qui, sinon, feraient échouer chaque vérification en aval.

<!-- tool-cta:end -->

Une checklist de validation axée sur les standards

Utilisez cette courte checklist avant de demander si un moteur de recherche aime la page :

• Chaque bloc JSON-LD est-il du JSON valide ?
• Chaque bloc inclut-il le bon @context et le bon @type ?
• Les propriétés Schema.org sont-elles correctement orthographiées ?
• Le balisage correspond-il au contenu visible ?
• Les dates, prix, notes et disponibilités sont-ils à jour ?
• Les URL sont-elles absolues, canoniques et accessibles ?
• La page de production rendue est-elle la même que celle que vous avez testée ?
• Les entités dupliquées sont-elles intentionnelles et non conflictuelles ?

Si vous pouvez répondre oui à ces questions, vous avez accompli la partie durable du travail sur les données structurées. Les tests propres aux moteurs de recherche peuvent encore être utiles ensuite, mais ils doivent être le contrôle de compatibilité final, pas le fondement de votre processus de validation.