Commencez par comparer le balisage au fil d’Ariane réellement utile
BreadcrumbList décrit une succession d’éléments qui représente le chemin d’une page dans une hiérarchie ou une navigation pertinente. Avant de corriger le JSON-LD, regardez le fil d’Ariane visible et demandez-vous s’il reflète vraiment le parcours que vous voulez montrer. Une erreur de propriété peut être technique, mais un balisage parfaitement valide qui décrit une hiérarchie artificielle reste peu utile. Google documente les propriétés attendues pour le breadcrumb et les règles générales des données structurées. La correction doit donc réunir validité syntaxique, cohérence des éléments et correspondance avec la page, sans promettre qu’un balisage valide garantit un résultat enrichi.
Vérifiez chaque ListItem et sa position
Chaque niveau du fil doit être représenté de manière ordonnée. Contrôlez la présence des ListItem, leurs positions et les noms associés. Une position dupliquée, manquante ou non séquentielle peut rendre le balisage incohérent. Vérifiez aussi que la liste ne saute pas arbitrairement d’un niveau à l’autre. Si votre fil visible est « Accueil > Catégorie > Produit », le balisage doit décrire cette logique plutôt qu’une structure différente générée par une taxonomie cachée. Corrigez le composant qui produit la liste afin que toutes les pages similaires bénéficient de la même règle.
Contrôlez les URL des étapes qui doivent être liées
Les éléments intermédiaires doivent mener vers des destinations pertinentes lorsque votre implémentation les expose. Vérifiez les redirections, 404, URL avec paramètres inutiles et variantes non canoniques. Une étape du breadcrumb qui pointe vers une ancienne catégorie redirigée peut rester compréhensible pour l’utilisateur mais compliquer la maintenance. Préférez les URL actuelles que vous utilisez déjà dans votre navigation. Ne créez cependant pas une page de catégorie uniquement pour « satisfaire » le schéma : le balisage doit décrire une architecture réelle, pas inventer une structure inexistante.
Séparez validation structurée et qualité de la navigation visible
Le test de données structurées analyse le balisage, mais il ne remplace pas l’évaluation du fil d’Ariane visible. Un composant peut être accessible seulement sur desktop, mal nommé, dupliqué ou placé dans un ordre incompréhensible tout en générant un JSON-LD syntaxiquement valide. Vérifiez donc la navigation avec un navigateur et les technologies d’assistance pertinentes. L’objectif de BreadcrumbList est de décrire un contexte de navigation significatif ; il ne doit pas devenir une couche indépendante conçue uniquement pour les robots.
Ne mélangez pas BreadcrumbList avec les autres types Schema.org
Une page produit peut utiliser Product et BreadcrumbList, une page article peut avoir Article et BreadcrumbList. Les erreurs de l’un ne sont pas automatiquement celles de l’autre. Si votre outil signale Product, utilisez le guide des erreurs Product. Si le problème concerne les positions et étapes du chemin, restez sur BreadcrumbList. Cette séparation aide à corriger la bonne entité et évite d’ajouter des propriétés non pertinentes à un type simplement parce qu’un autre type les utilise.
Validez le HTML final généré, pas uniquement votre configuration CMS
Un CMS peut afficher des champs corrects dans l’administration mais produire un JSON-LD différent après passage dans le thème ou une extension. Inspectez la page finale et utilisez les outils de validation adaptés. Testez plusieurs niveaux : page de premier niveau, sous-catégorie, produit profond et page sans fil d’Ariane. Les erreurs qui n’apparaissent que sur certaines profondeurs révèlent souvent un problème de boucle, d’index de position ou de données manquantes. Corrigez la logique de génération plutôt que des sorties individuelles.
Évitez les promesses de ranking ou de résultat enrichi
Corriger BreadcrumbList améliore la cohérence des données que vous publiez et peut être nécessaire pour l’éligibilité aux présentations concernées, mais cela ne garantit pas un résultat enrichi. Google précise que des données structurées correctes ne garantissent pas leur affichage. Il n’existe pas non plus de bénéfice de classement garanti à annoncer après correction. Présentez la validation comme un contrôle de qualité et d’éligibilité, pas comme une recette pour gagner des positions.
Validez le fil complet après la correction
Après modification, contrôlez les pages représentatives, les URL d’étapes, l’ordre des positions et la correspondance avec le fil d’Ariane visible. Vérifiez aussi qu’aucune correction BreadcrumbList n’a modifié Product ou d’autres blocs JSON-LD. Un audit Limpi peut aider à inventorier les données structurées ; notre approche distingue erreurs techniques, contenu visible et résultats externes. Un BreadcrumbList valide ne garantit pas un résultat enrichi, et aucun bénéfice de classement garanti ne doit être déduit de sa correction. Pour éviter les régressions, créez des cas de test correspondant aux principales profondeurs de votre site et comparez à la fois le fil visible et le JSON-LD généré. Un changement de taxonomie peut modifier les deux sans provoquer d’erreur de syntaxe. Vérifiez alors que les noms restent compréhensibles, que les URL existent et que les positions suivent toujours l’ordre voulu. Si votre site masque volontairement certaines étapes visuelles, documentez la logique au lieu de laisser le balisage diverger silencieusement. Cette validation de contenu est aussi importante que la validation technique, car un schéma peut être formellement correct tout en décrivant une hiérarchie que l’utilisateur ne reconnaît pas. Pensez enfin aux pages atypiques : résultats filtrés, landing pages sans catégorie, articles appartenant à plusieurs rubriques ou produits accessibles depuis plusieurs chemins. Le breadcrumb visible doit faire un choix compréhensible et le balisage doit refléter ce choix plutôt qu’agréger toutes les taxonomies disponibles. Lorsque plusieurs parcours sont possibles, documentez la règle de sélection. Vous éviterez ainsi des listes incohérentes produites automatiquement par la profondeur technique du CMS. Incluez ces cas dans vos tests automatisés lorsque le CMS évolue. Une régression du breadcrumb peut venir d’un changement de taxonomie sans toucher directement au module Schema.org. En contrôlant simultanément le nom, l’URL et la position de chaque étape, vous détectez plus tôt les divergences entre navigation et balisage.
Références utilisées pour cette page
Continuer à comprendre votre visibilité
À lire ensuite