Schema BreadcrumbList

Ce que BreadcrumbList encode vraiment

Le balisage ne décrit pas un composant graphique, il décrit une position dans un arbre. Un BreadcrumbList est une séquence ordonnée de ListItem, chacun portant une position entière, un name et un item qui pointe vers l’URL du niveau concerné. Ce que vous déclarez à Google, ce n’est pas « voici un joli chemin de navigation », c’est « cette page est un enfant de cette catégorie, elle-même enfant de cette rubrique ». La nuance n’est pas cosmétique : elle explique pourquoi un balisage impeccable posé sur un site sans arborescence réelle ne produit strictement rien. Le balisage ne crée pas la hiérarchie, il la déclare. Si elle n’existe pas dans le maillage, vous déclarez une fiction.

Le fil d’Ariane visible et le balisage sont deux artefacts distincts, et c’est là que se logent la plupart des défauts. Le premier est du HTML rendu pour l’utilisateur, le second du JSON-LD lu par les robots. Rien dans la chaîne technique n’oblige les deux à raconter la même histoire, et sur la majorité des sites qu’on ouvre en audit, ils divergent sur au moins un gabarit de page. Google demande explicitement que le balisage reflète le chemin affiché. Un décalage ne déclenche pas de pénalité, il produit un signal contradictoire que le moteur arbitre à sa façon, c’est-à-dire le plus souvent en l’ignorant.

Point technique que beaucoup d’implémentations ratent : une page peut légitimement porter plusieurs BreadcrumbList. Un article rangé à la fois sous « Fiscalité » et sous « Immobilier » déclare deux chemins, et la documentation Google le prévoit. C’est utile sur les taxonomies croisées, où forcer un chemin unique revient à mentir sur la structure réelle du site. À l’inverse, empiler des chemins artificiels pour multiplier les occurrences de mots-clés dans les name est un réflexe de 2016 qui ne rapporte plus rien et qui rend le diagnostic illisible pour vous-même six mois plus tard.

Le fil d’Ariane a quitté le mobile, le balisage est resté

Le 23 janvier 2025, Google a retiré les chemins de fil d’Ariane des résultats de recherche sur mobile, à l’échelle mondiale, en expliquant qu’ils étaient peu utiles et souvent tronqués ; seul le nom de domaine reste affiché sous le titre. Sur desktop, le chemin continue de s’afficher, et le rapport Breadcrumbs de la Search Console comme le test des résultats enrichis restent disponibles. La conséquence opérationnelle est rarement dite aux clients : la valeur d’affichage du BreadcrumbList est désormais desktop only, donc adossée à une part minoritaire du trafic sur la plupart des sites grand public. Ce qui reste, et qui n’a pas bougé, c’est la valeur structurelle.

Deuxième mouvement, plus large : Google a passé 2025 et 2026 à élaguer les types de données structurées, pas à les abandonner. Le 12 juin 2025, sept types de résultats enrichis ont été dépréciés, parmi lesquels Book Actions, Course Info, Claim Review, Estimated Salary, Learning Video, Special Announcement et Vehicle Listing ; le reporting Search Console associé s’est arrêté le 9 septembre 2025 et les champs concernés renvoient NULL dans les exports en masse depuis le 1er octobre 2025. Le 5 novembre 2025, Google a annoncé la fin du support de Practice Problem à partir de janvier 2026, et rappelé au passage que le balisage Dataset sert à Dataset Search, pas à la recherche classique. Breadcrumbs ne figure dans aucune de ces vagues. En juin 2026, les suivis tiers des rapports d’amélioration encore actifs listent Breadcrumbs aux côtés de Products, Review snippets et Video.

C’est une information de planification, et elle vaut mieux qu’une intuition : investir dans un balisage propre à l’échelle d’un site n’a pas le profil de risque d’un investissement sur un type exotique susceptible de disparaître à la vague suivante. Durable ne veut pas dire influent sur le classement, en revanche. Google traite les données structurées comme un mécanisme d’éligibilité et d’interprétation, jamais comme un facteur de positionnement, et son guide 2026 d’optimisation pour les fonctionnalités génératives précise noir sur blanc qu’aucun balisage n’est requis pour y figurer. Quiconque vous vend le BreadcrumbList comme un levier de ranking vous vend un rapport d’audit, pas un résultat.

Implémenter proprement, mesurer honnêtement

La règle d’ingénierie qui règle l’essentiel des cas tient en une phrase : le fil d’Ariane visible et le JSON-LD doivent être produits à partir de la même source de données, dans le même passage de rendu. Dès qu’un thème génère l’affichage et qu’une extension génère le balisage, la divergence n’est plus une hypothèse, c’est une question de calendrier. Sur un CMS, cela veut dire choisir qui est propriétaire du fil d’Ariane et désactiver l’autre, pas arbitrer au cas par cas.

Les contraintes de forme qui font échouer la validation sont toujours les mêmes. Les position doivent démarrer à 1 et se suivre sans trou. Les item doivent être des URL absolues, dans leur forme canonique : bon protocole, bon hôte, slash final cohérent avec la balise canonical de la page. Le dernier élément peut se passer d’URL puisqu’il désigne la page courante. Les name doivent reprendre le libellé affiché, pas une variante optimisée pour la requête. Et aucun maillon ne doit pointer vers une URL en noindex, vers une page de pagination ou vers une redirection : un fil d’Ariane qui traverse une chaîne de redirections transforme votre couche de liens internes la plus régulière en couche la plus coûteuse à crawler.

Pour mesurer, le test des résultats enrichis suffit sur un gabarit, jamais sur un site. À l’échelle, on crawle avec une extraction personnalisée du JSON-LD, Screaming Frog reste l’outil de référence pour ça, autour de 259 dollars par an en 2026, et on compare la chaîne extraite à l’arborescence réelle des URL. L’indicateur utile n’est pas le nombre de pages valides, c’est le nombre de gabarits qui produisent une chaîne valide : sur un gros site, une poignée de gabarits produit l’essentiel des URL, et un seul gabarit cassé fait basculer des dizaines de milliers de pages d’un coup sans que la moyenne du rapport Search Console vous alerte.

Une précaution de mesure qui invalide beaucoup de comparaisons avant/après : Google a reconnu que les impressions ont été rapportées de façon inexacte dans la Search Console du 13 mai 2025 au 27 avril 2026, incident déclaré résolu mais sans reconstruction des données historiques, les clics n’étant pas concernés. Toute analyse en glissement annuel qui traverse cette fenêtre et qui s’appuie sur les impressions demande une réserve explicite. Si vous devez démontrer l’effet d’un chantier de balisage sur cette période, raisonnez en clics.

Côté IA, la prudence s’impose aussi. Le 3 juin 2026, Google a lancé dans la Search Console des rapports de performance dédiés aux fonctionnalités génératives, couvrant les AI Overviews, l’AI Mode et les surfaces génératives de Discover, avec impressions et dimensions par page, pays, appareil et date. C’est un vrai progrès de mesure, mais ce n’est pas une preuve de causalité. Un audit éditeur portant sur 5 000 sites en production, publié le 26 avril 2026, rapporte un BreadcrumbList présent sur 38 % des sites, seulement 8 % des sites déployant correctement cinq types de balisage ou plus, un écart de 49 points entre déploiement et validation, une corrélation de +0,34 entre balisage valide et taux de citation en recherche générative, et une fréquence de citation en AI Overviews supérieure de 47 % pour les sites éditoriaux combinant balisage Article et BreadcrumbList valides. Ces chiffres sont observationnels et proviennent d’un éditeur d’outils : ils mélangent deux types de balisage et le statut de validation, ils ne démontrent pas que le BreadcrumbList produit seul la hausse de citations. À citer comme tel devant un client, jamais comme un ratio de performance garanti.

Ce que ça change dans une opération de netlinking

Le vrai intérêt du fil d’Ariane pour un consultant qui pilote des liens n’est pas dans le SERP, il est dans le graphe interne. Sur un site éditorial, le fil d’Ariane est la couche de liens internes la plus dense et la plus régulière : chaque article envoie mécaniquement un lien vers sa catégorie et vers la racine, avec une ancre stable. C’est ce qui donne aux pages de catégorie la masse de liens entrants internes qu’elles n’obtiendraient jamais autrement, et c’est très souvent la raison pour laquelle une page de rubrique se positionne alors que personne ne lui a jamais pointé un lien externe.

Cela a une conséquence directe sur l’arbitrage d’une campagne. Un backlink qui arrive sur un article isolé, sans chemin remontant, alimente une page terminale et s’arrête là. Le même lien sur un article correctement rattaché irrigue la catégorie, puis les articles voisins de cette catégorie. Autrement dit, l’architecture décide du rendement des liens que vous achetez. Avant de discuter ce que coûte réellement un lien éditorial, il vaut mieux vérifier que la structure du site saura en faire quelque chose : c’est le seul chantier SEO dont le retour se calcule en multiplicateur sur tout le budget de liens à venir, pas en gain propre.

Sur les médias éditoriaux que nous opérons en propre chez Nautilinks, le fil d’Ariane est produit par le gabarit et non par une extension, ce qui règle la question de la divergence par construction : un seul objet de données alimente l’affichage et le JSON-LD, et un défaut se corrige sur un gabarit plutôt qu’article par article. C’est aussi ce qui rend une page de catégorie exploitable comme destination de lien, un point à regarder quand vous parcourez un catalogue de médias consultable sans inscription : un site dont les rubriques ne captent rien du maillage interne rendra moins qu’un site à profondeur équivalente mais correctement structuré.

Ce qu’il ne faut pas faire, c’est vendre le balisage comme un substitut d’acquisition. Le BreadcrumbList n’apporte pas d’autorité, il redistribue celle que vous avez déjà. Sur un site sans liens entrants, un fil d’Ariane parfait redistribue zéro.

Les défauts qu’on retrouve le plus souvent

Le classique absolu reste le double balisage : une extension SEO et le thème produisent chacun leur BreadcrumbList, avec des chemins différents, et personne ne s’en aperçoit parce que les deux passent le test des résultats enrichis individuellement. Le symptôme se voit dans le code source, pas dans les outils : deux blocs JSON-LD au lieu d’un. La correction n’est jamais de bricoler le second, c’est d’en couper un.

Vient ensuite le fil d’Ariane déduit du chemin d’URL sur un site à URL plates. Le gabarit reconstruit un chemin à partir des segments, mais les niveaux intermédiaires n’existent pas en tant que pages : vous déclarez des maillons qui renvoient des 404 ou des redirections. Sur les sites en URL racine, très courants sur les magazines, il faut alimenter le fil d’Ariane depuis la taxonomie éditoriale et pas depuis l’URL.

Troisième défaut fréquent, le fil d’Ariane injecté en JavaScript après le chargement alors que le HTML servi n’en contient rien. Google finit souvent par le voir, mais vous introduisez une dépendance au rendu pour un signal qui coûte trois lignes en statique. Même logique pour les item en URL relatives, tolérées par certains validateurs et invisibles pour d’autres consommateurs du balisage.

Enfin, le défaut qui ne se voit qu’en croisant les données : le fil d’Ariane pointe vers des catégories désindexées. On rencontre régulièrement des sites où les pages de rubrique ont été passées en noindex lors d’un chantier de qualité, sans que le balisage soit mis à jour. Le maillage continue d’envoyer l’essentiel de sa force vers des pages que Google a instruction d’oublier. Cherchez cette configuration en premier sur un site qui a subi un chantier de réorganisation en silos dans les douze derniers mois, c’est là qu’elle se cache.

Une dernière remarque sur les chiffres qui circulent. Les gains de taux de clic attribués au fil d’Ariane, 2 à 3 points, 5 % de trafic organique, 5 à 10 % de CTR selon les sources, viennent d’études de cas d’agences et de guides d’éditeurs, pas d’une expérimentation indépendante récemment répliquée. Depuis le retrait de l’affichage mobile en janvier 2025, ils sont de toute façon caducs sur le trafic mobile. Utilisez-les comme anecdote, jamais comme prévision dans une proposition commerciale.