Que faire si Google Schema Testing Tool ne détecte pas les données ?

La page contient déjà du code JSON-LD, mais lorsque vous ouvrez google schema testing tool, le message « Aucune donnée structurée détectée » s'affiche. Ne vous précipitez pas pour réécrire l'ensemble du balisage. Ce résultat ne signifie généralement pas que le Schema est nécessairement invalide ; il est plus fréquent que le contenu de la page obtenu par l'outil de test diffère de celui affiché dans le navigateur, ou que le positionnement du balisage, la syntaxe du code ou l'état d'accès à la page pose problème.

En pratique, les situations les plus susceptibles de conduire à un mauvais diagnostic sont les suivantes : les développeurs constatent que le code fonctionne correctement dans l'environnement de test, mais l'outil ne peut pas l'explorer après publication ; ou bien les champs produit, fil d'Ariane, article et autres ont déjà été enregistrés dans l'administration du site, mais la page côté visiteur ne génère pas réellement de données structurées. Il convient d'abord de confirmer si le HTML récupéré par l'outil contient le balisage, puis de vérifier si celui-ci peut être analysé, et enfin seulement de déterminer si les types et propriétés répondent aux exigences.

Distinguez d'abord : aucune donnée détectée ou données détectées mais non conformes aux exigences des résultats enrichis

« Aucune donnée détectée » et « Données détectées mais avec avertissements » sont deux problèmes différents. Le premier indique que l'outil n'a pas analysé de Microdata, RDFa ou JSON-LD identifiable sur la page actuelle ; le second indique que le balisage existe, mais qu'il manque certains champs recommandés, ce qui n'affecte pas nécessairement l'identification de base.

L'ancien Structured Data Testing Tool de Google n'est plus maintenu. Pour les vérifications actuelles, utilisez l'outil de test des résultats enrichis afin de contrôler si la page remplit les conditions d'affichage des résultats enrichis pris en charge par Google, ou utilisez Schema Markup Validator pour vérifier la syntaxe et la hiérarchie de Schema.org. Ne concluez pas directement que toutes les données structurées de la page sont invalides parce qu'un outil n'affiche aucun résultat ; les différents outils n'accordent pas exactement la même importance aux types pris en charge, au rendu JavaScript et aux règles de validation.

Première étape : confirmez que vous soumettez la version finale accessible de la page

Ouvrez d'abord l'URL à tester dans une fenêtre de navigation privée, puis vérifiez qu'elle est directement accessible, qu'elle renvoie une page normale et qu'elle ne requiert ni connexion, ni code de vérification, ni restriction géographique, ni Cookie particulier. Les outils de test ne peuvent pas lire les contenus bloqués, soumis à des redirections anormales ou dont l'accès est restreint.

• Vérifiez si l'URL redirige automatiquement de http vers https, ou de la version sans www vers la version avec www ; testez l'adresse finale de destination.
• Confirmez que la page n'est pas un brouillon, un lien d'aperçu, une page d'édition dans l'administration ou une adresse de test visible uniquement sur l'intranet.
• Vérifiez si plusieurs redirections se produisent. Si la chaîne de redirection est trop longue ou mène vers une page de sélection de langue ou une page d'erreur, l'outil ne détectera pas la page de contenu visée.
• Vérifiez si le serveur renvoie un contenu différent aux robots, par exemple en raison d'une protection de sécurité, d'une limitation de fréquence, d'une erreur 403, 503 ou d'une page blanche.

Certains sites renvoient différentes versions selon la langue, l'IP ou le User-Agent du visiteur. Le fait que la page soit accessible normalement dans le navigateur ne signifie pas que l'outil d'exploration obtient un HTML normal. Dans ce cas, vérifiez dans les journaux du serveur, les règles de protection CDN ou les résultats d'exploration de la page si la requête a été bloquée.

Deuxième étape : recherchez les données structurées dans le code source de la page

Ne les recherchez pas uniquement dans « Inspecter l'élément » du navigateur. Les outils de développement affichent le DOM après l'exécution du JavaScript de la page, tandis que l'outil de test n'exécute pas nécessairement les scripts de la même manière. Utilisez « Afficher le code source de la page » et recherchez application/ld+json, schema.org, itemtype ou itemscope.

Pour JSON-LD, la syntaxe courante consiste à placer le contenu dans une balise <script type="application/ld+json">. Si cette partie n'apparaît pas dans le code source et ne se trouve que dans le DOM dynamique, le problème provient probablement d'une injection asynchrone côté front-end. En particulier sur les applications monopages, les pages de filtrage et les fenêtres contextuelles de détails produit, les données structurées peuvent n'être générées qu'après le retour d'une API ; un moment d'exploration différent peut alors empêcher google schema testing tool de les détecter.

Une solution plus fiable consiste à générer le JSON-LD des pages essentielles avec le HTML initial, ou à adopter une solution fiable de rendu côté serveur ou de prérendu. Les informations principales des pages de détail produit, des articles et des pages de catégorie doivent de préférence être lisibles dans la réponse initiale, au lieu de dépendre entièrement d'un chargement après interaction de l'utilisateur.

Troisième étape : vérifiez la syntaxe JSON-LD, et pas seulement le contenu des champs

Lors de la copie du code, il est facile d'introduire des guillemets pleine chasse, des virgules finales, des guillemets doubles non échappés ou des parenthèses incomplètes. Dès que l'analyse JSON échoue, l'outil ignore généralement tout le bloc de données. Un code qui ressemble à du Schema ne signifie pas qu'il s'agit d'un JSON valide.

Vérifiez également que @context est défini sur https://schema.org et que @type est correctement orthographié. Les valeurs des propriétés doivent correspondre au contenu visible sur la page. Par exemple, le prix, le stock, la note et la date de publication d'un produit ne doivent pas rester durablement dans le balisage s'ils sont obsolètes ou absents de la page. Le fait que l'outil puisse analyser ces informations ne signifie pas que le moteur de recherche les utilisera pour l'affichage.

Les problèmes liés aux modèles, plugins et caches sont plus discrets

Lors de l'utilisation d'un système de création de site ou d'un CMS, il arrive que les données structurées ne soient toujours pas détectées après avoir coché « Activer les données structurées » dans l'administration. La cause n'est souvent pas un mauvais choix de type Schema, mais le fait que le modèle n'appelle pas le composant correspondant. Par exemple, le modèle d'article affiche le titre et le corps du texte, mais omet le module Schema de l'article ; les données produit sont saisies dans le système de gestion des produits, mais la page de détail actuelle utilise un modèle personnalisé et les champs concernés ne sont pas transmis.

Un autre problème fréquent est le cache. Après une mise à jour de la page, la configuration dans l'administration a changé, mais le CDN, le cache de page ou le cache d'objets renvoie toujours l'ancienne version du HTML. L'ordre de vérification doit être le suivant : enregistrez les paramètres et publiez la page, videz le cache du site et le cache CDN, consultez le code source à l'aide de l'URL publique finale, puis soumettez à nouveau le test. Voir le nouveau code uniquement sur la page d'aperçu de l'administration ne prouve pas que la page en ligne a été mise à jour.

N'affichez pas à plusieurs reprises des données contradictoires sur une même page

Certains sites activent simultanément le balisage SEO intégré au thème, le balisage d'un plugin e-commerce et un plugin SEO tiers. Une page produit contient alors deux Product et deux Offer, avec parfois des prix ou des stocks incohérents. Ces pages n'affichent pas nécessairement « Aucune donnée détectée », mais elles compliquent les diagnostics ultérieurs et peuvent également réduire la fiabilité du balisage.

Il est recommandé de conserver l'entité principale selon le rôle de la page : Article ou BlogPosting pour une page de détail d'article, Product pour une page de détail produit, et BreadcrumbList peut compléter la zone de navigation. Supprimez ou désactivez d'abord les sources redondantes, puis effectuez un nouveau test. Pour les entités globales telles que Organization et WebSite, les informations comme le nom, l'URL et le Logo doivent également rester cohérentes ; ne laissez pas différents plugins générer chacun une version différente.

Ordre de validation après correction

1. Ouvrez le code source de la page publique et confirmez que les données structurées sont effectivement générées.
2. Validez séparément l'extrait de code JSON-LD afin d'écarter les erreurs de virgule, de guillemets, de parenthèses et d'encodage.
3. Utilisez un outil de validation Schema pour confirmer que le type d'entité, la hiérarchie des propriétés et les relations de référence peuvent être analysés.
4. Utilisez ensuite l'outil de test des résultats enrichis pour vérifier les types d'affichage spécifiques pris en charge par Google ainsi que les champs manquants.
5. Après avoir vidé le cache, testez à nouveau l'URL ; si la page est déjà indexée, vous pouvez demander une nouvelle exploration dans l'outil de gestion des ressources de recherche.

Enfin, il faut conserver une limite claire dans l'interprétation : la validation des données structurées indique seulement que les machines peuvent comprendre certaines informations de la page, sans garantir l'obtention d'un affichage en résultats enrichis ; inversement, le fait qu'un type de Schema ne soit pas affiché par l'outil des résultats enrichis ne signifie pas nécessairement que le balisage n'a aucune valeur. Pour le problème « données non détectées », il est généralement plus efficace de cibler en priorité l'accessibilité de la page, la génération du HTML initial, la syntaxe JSON et la version du cache que d'ajouter des champs à répétition.