Tester son balisage Schema.org : outils, méthode et erreurs

Tester un balisage Schema.org consiste à vérifier trois choses : la syntaxe est correcte, les types et propriétés existent dans le vocabulaire, et les valeurs correspondent au contenu visible de la page. Aucun outil ne couvre les trois seul.

La méthode la plus sûre enchaîne trois contrôles. Le validateur de Schema.org vérifie la syntaxe et le vocabulaire. Le test des résultats enrichis de Google vérifie l’éligibilité aux affichages spéciaux. La Search Console surveille ensuite l’ensemble du site.

Ce test vient après la mise en place du balisage, décrite dans notre guide Schema.org pour le GEO. Il fait aussi partie de tout audit SEO / GEO sérieux, car un balisage cassé prive la page d’un signal utile.

• Étape 1 : Schema Markup Validator pour la syntaxe et le vocabulaire
• Étape 2 : test des résultats enrichis de Google pour l’éligibilité
• Étape 3 : rapports de la Search Console pour le suivi à l’échelle du site
• Étape 4 : relecture humaine de la cohérence avec le texte visible

Un bon outil de test doit lire les trois formats, montrer le graphe extrait, pointer la ligne en erreur et distinguer une erreur bloquante d’un simple avertissement. Deux outils officiels remplissent ces critères, et ils se complètent plutôt qu’ils ne se remplacent.

Le Schema Markup Validator est maintenu pour la communauté Schema.org. Selon sa documentation, il extrait le JSON-LD 1.0, le RDFa 1.1 et les Microdata, affiche un résumé du graphe et identifie les fautes de syntaxe, y compris le balisage injecté par JavaScript.

Le test des résultats enrichis se concentre sur ce que Google sait afficher. D’après l’aide de la Search Console, il accepte une URL ou un extrait de code, lit le JSON-LD, le RDFa et les microdonnées, et teste par défaut avec un user-agent smartphone.

Vous ne savez pas si votre balisage est lu par Google et par les moteurs IA ? Demandez un audit SEO / GEO : nous testons chaque page, listons les erreurs et vous livrons le balisage corrigé.

Ouvrez le test des résultats enrichis, choisissez « URL » pour une page en ligne ou « Code » pour un extrait, puis lancez le test. L’outil liste les types de résultats enrichis détectés, avec pour chacun les erreurs et les avertissements, et ouvre le code à la ligne concernée.

L’aide de l’outil rappelle deux contraintes. Toutes les ressources de la page doivent être accessibles sans identifiant, car une page protégée par mot de passe ou pare-feu n’est pas testée. Les commentaires dans un bloc JSON-LD sont ignorés par l’outil, mais pas par la norme : supprimez-les avant publication.

Lisez le résultat en trois temps. Une erreur rend l’élément inéligible et doit être corrigée. Un avertissement signale une propriété recommandée absente, qui limite l’affichage sans le bloquer. L’état de l’URL indique enfin si Google a pu charger la page et ses ressources.

• Testez la version mobile en priorité : c’est le user-agent par défaut de l’outil
• Corrigez dans le mode « Code », relancez, puis vérifiez l’URL réelle après déploiement
• Conservez une capture du résultat : elle servira de référence lors du prochain changement de gabarit

Les données structurées sont un balisage ajouté au code d’une page pour décrire son contenu de façon normalisée : cette page parle d’une entreprise, située à cette adresse, ouverte à ces horaires, notée ainsi. Le vocabulaire commun est Schema.org.

Ce vocabulaire est vaste. La documentation de Schema.org compte 826 types et 1 540 propriétés, organisés en hiérarchie. Une entreprise n’en utilise qu’une poignée : Organization ou LocalBusiness, Service, Article, FAQPage, BreadcrumbList.

Trois formats existent pour l’écrire. Google recommande le JSON-LD, un bloc de script séparé du texte visible, plus simple à gérer à grande échelle que les Microdata ou le RDFa intégrés dans les balises HTML.

L’adoption suit cette recommandation. D’après le Web Almanac 2024 de HTTP Archive, le JSON-LD est présent sur 41 % des pages analysées, contre 34 % en 2022, tandis que les Microdata restent stables à 26 % des pages.

La plupart des balisages échouent pour des raisons simples, que les outils de test repèrent en quelques secondes. D’autres erreurs passent le test mais trahissent les consignes de Google, et celles-là se paient plus tard, par une absence d’affichage ou une action manuelle.

Les consignes de Google sur les données structurées sont claires sur un point : le contenu référencé par le balisage doit être visible par l’utilisateur. Une note d’avis, une FAQ ou un prix présents dans le JSON-LD mais absents de la page constituent une infraction.

Google précise aussi, dans son introduction aux données structurées, qu’il vaut mieux fournir moins de propriétés recommandées, mais complètes et exactes, que d’en remplir beaucoup avec des données incomplètes ou imprécises.

• Erreur de syntaxe JSON : virgule en trop, guillemet manquant, accolade non fermée
• Type ou propriété inexistants dans le vocabulaire, souvent une faute de casse
• Propriété obligatoire absente pour le type visé, par exemple le nom ou l’image
• Valeur qui ne correspond pas au texte visible : horaires, prix, note, auteur
• Deux blocs contradictoires sur la même page, laissés par deux extensions SEO
• Balisage présent sur la version ordinateur mais absent de la version mobile
• Page de test inaccessible au robot : environnement de préproduction protégé

Les tests page par page ne suffisent pas sur un site de plusieurs centaines d’URL. La Search Console propose, dans sa rubrique « Améliorations », un rapport par type de résultat enrichi détecté, avec le nombre d’éléments valides, valides avec avertissements et non valides.

D’après l’aide de ces rapports, un élément qui cumule plusieurs problèmes apparaît dans chaque tableau mais n’est compté qu’une fois dans le total des non valides. Si un problème réapparaît dans les 90 jours suivant sa correction, la date affichée reste celle de la première détection.

La même page rappelle qu’il n’existe pas de bouton « Résoudre ce problème » : les données structurées résident sur votre site, pas sur les serveurs de Google. Corrigez à la source, puis lancez la validation depuis le rapport pour que Google revérifie les URL concernées.

• Un rapport n’apparaît que si Google a détecté le type sur au moins une page indexée
• Un pic de pages non valides après une mise à jour signale presque toujours un changement de thème ou d’extension
• Le rapport de suivi de visibilité dans AI Mode ne remplace pas ces rapports, il les complète

Aucun des moteurs IA ne propose d’outil de test officiel. La bonne nouvelle est que les prérequis sont les mêmes que pour Google. La documentation de Google sur les fonctionnalités IA indique qu’aucune exigence supplémentaire n’est requise pour apparaître dans les Aperçus IA ou le Mode IA.

La même documentation demande de s’assurer que les données structurées correspondent au texte visible sur la page. C’est exactement ce que les deux outils de test ne vérifient pas, et ce qu’une relecture humaine doit contrôler : nom, adresse, offres, horaires et chiffres identiques dans le balisage et dans le texte.

Le test final est manuel. Posez à ChatGPT, Perplexity et Gemini les questions que vos clients posent, et comparez la réponse avec votre balisage : nom exact, zone d’intervention, services. Notre méthode pour suivre sa visibilité dans les IA détaille le jeu de questions à utiliser.

• Balisage et texte visible doivent dire la même chose, au chiffre près
• Un fichier llms.txt complète le balisage sans le remplacer
• Pour une entreprise locale, le balisage LocalBusiness doit coïncider avec la fiche Google, voir notre guide GEO local
• Les conditions pour être visible dans les Aperçus IA commencent par une page indexée avec un extrait affichable

Ce scénario est illustratif : il décrit une progression plausible, pas un résultat garanti. Un cabinet d’expertise comptable de trois associés dispose d’un site de 60 pages, balisé par une extension SEO jamais vérifiée depuis l’installation.

Semaine 1 : test du gabarit de page service dans le Schema Markup Validator. Deux blocs Organization contradictoires sont détectés, l’un avec l’ancienne adresse. Le test des résultats enrichis signale une propriété image manquante sur les articles.

Semaines 2 et 3 : suppression du bloc en double, passage de Organization à AccountingService, ajout des horaires, de la zone desservie et des images d’articles. Chaque correction est relancée dans le mode « Code » avant déploiement.

Semaines 4 à 8 : la Search Console fait passer les pages non valides de 38 à 0 après validation. Les tests manuels dans ChatGPT et Perplexity restituent la bonne adresse et la liste des services. Le trafic, lui, bouge peu sur cette période : le balisage corrige un signal, il ne crée pas la demande.

• Le premier gain est la cohérence des informations restituées, pas le trafic
• Les erreurs venaient d’un cumul d’extensions, pas d’un balisage mal écrit
• Le suivi dans la Search Console évite de refaire ce travail au prochain changement de thème

Tester son balisage Schema.org prend dix minutes par gabarit et évite des mois de signal perdu. Les outils sont gratuits, officiels et complémentaires.

• Le Schema Markup Validator vérifie la syntaxe et le vocabulaire, pour tous les types
• Le test des résultats enrichis vérifie ce que Google peut afficher, avec les propriétés obligatoires
• La Search Console surveille l’ensemble du site et date chaque problème
• Un balisage valide n’est pas forcément affiché : FAQ et HowTo en sont la preuve depuis 2023
• Pour les moteurs IA, le seul test est la cohérence entre balisage et texte visible, puis l’essai manuel
• Pour un contrôle complet de vos pages, découvrez notre offre d’audit SEO / GEO