Faut-il absolument dupliquer les breadcrumbs en version mobile pour rester indexé ?

Pourquoi Google indexe-t-il uniquement la version mobile maintenant ?

Depuis le passage au mobile-first indexing, Google utilise exclusivement la version mobile d'une page pour l'analyser, l'indexer et la classer. Ce n'est plus un complément — c'est la seule source de vérité. Si un élément structurel comme les breadcrumbs n'existe que sur desktop, il devient invisible pour le moteur.

Cette bascule répond à une logique d'usage : la majorité des recherches s'effectuent sur mobile. Google a donc fait le choix de se caler sur l'expérience réelle des utilisateurs. Les sites qui négligent leur version mobile se retrouvent pénalisés, même si leur desktop est impeccable.

Qu'est-ce que cela change pour le SEO technique ?

Les breadcrumbs jouent un rôle crucial dans la compréhension de l'architecture d'un site. Ils aident Google à établir la hiérarchie des pages, à identifier les catégories principales et à distribuer le PageRank de manière cohérente. Sans eux, le moteur peut mal interpréter la structure du site.

Soyons honnêtes : beaucoup de sites responsive masquent les breadcrumbs sur mobile pour gagner de l'espace. C'est un choix UX défendable, mais qui devient problématique côté indexation. Si le balisage Schema.org BreadcrumbList est présent uniquement dans le DOM desktop, il ne sert plus à rien.

Comment vérifier si mes breadcrumbs sont pris en compte ?

Il faut tester avec le Mobile-Friendly Test de Google ou la Search Console en mode inspection d'URL. Regarde le HTML rendu : les breadcrumbs doivent être visibles dans le code source mobile, pas seulement affichés via CSS pour les écrans larges.

Attention aux pièges classiques : un fil d'Ariane injecté en JavaScript côté client peut ne pas être crawlé correctement si le rendu nécessite plusieurs secondes. Et un breadcrumb masqué en display:none uniquement sur mobile risque d'être ignoré, même si le balisage JSON-LD est présent.

• Google indexe uniquement le contenu présent sur la version mobile depuis le passage au mobile-first indexing.
• Les breadcrumbs absents de cette version mobile ne sont plus utilisés pour comprendre la structure du site.
• Il est impératif de vérifier que le balisage BreadcrumbList Schema.org est présent dans le HTML mobile, pas seulement desktop.
• Un masquage CSS trop agressif ou un rendu JavaScript trop lent peuvent annuler l'effet des breadcrumbs.
• L'inspection d'URL dans la Search Console permet de valider ce que Google voit réellement sur mobile.

Cette déclaration est-elle cohérente avec les observations terrain ?

Oui, totalement. On observe depuis plusieurs années que les sites qui maintiennent des différences structurelles entre desktop et mobile subissent des incohérences d'indexation. Les breadcrumbs en sont un cas typique : masqués sur mobile pour des raisons d'UX, ils disparaissent de l'index.

Le problème, c'est que beaucoup de développeurs pensent encore en termes de responsive design classique — c'est-à-dire un même HTML pour tous les écrans, avec des variations CSS. Mais si le CSS masque un élément crucial, Google ne le voit pas. Et c'est là que ça coince.

Quelles nuances faut-il apporter à cette règle ?

John Mueller ne précise pas si Google tolère les breadcrumbs visuellement masqués mais présents dans le DOM. En théorie, un fil d'Ariane en aria-hidden ou en position:absolute hors écran pourrait être crawlé. Mais c'est risqué — Google a déjà sanctionné du contenu jugé manipulateur dans des contextes similaires.

[A vérifier] : Google n'a jamais clarifié si un breadcrumb présent uniquement dans le JSON-LD Schema.org, sans équivalent HTML visible, suffit. Les tests terrain suggèrent que oui, à condition que le JSON-LD soit bien injecté côté serveur ou lors du premier rendu. Mais prudence : si le script JSON-LD est chargé en différé, il peut être ignoré.

Dans quels cas cette règle ne s'applique-t-elle pas ?

Pour les sites en responsive design strict — c'est-à-dire un unique HTML servi à tous les devices, sans variation côté serveur — la question ne se pose pas. Les breadcrumbs sont présents partout, même si CSS les affiche différemment.

En revanche, pour les sites en adaptive design ou avec des templates mobiles distincts (de moins en moins courant, mais ça existe encore), c'est un risque majeur. Si le template mobile ne génère pas les breadcrumbs, ils sont perdus. Et c'est exactement ce que Mueller pointe du doigt.

Que faut-il faire concrètement pour se conformer ?

Première étape : auditer votre site en mode mobile. Utilise la Search Console, section « Inspection d'URL », et vérifie que le HTML rendu contient bien les breadcrumbs — à la fois dans le balisage sémantique (balises HTML type <nav> ou <ol>) et dans le JSON-LD Schema.org BreadcrumbList.

Si ton site est en responsive et que les breadcrumbs sont masqués uniquement via CSS sur mobile, assure-toi qu'ils restent dans le DOM. Évite les display:none qui peuvent être interprétés comme du cloaking si Google juge le contenu trompeur. Préfère un masquage visuel via visibility:hidden ou clip-path, ou mieux : affiche-les vraiment.

Quelles erreurs éviter absolument ?

Ne laisse pas un développeur supprimer les breadcrumbs du HTML mobile sous prétexte que « ça prend de la place ». C'est une erreur stratégique qui impacte directement la compréhension de ton architecture par Google. Si l'UX impose de les masquer, garde-les dans le code et ajoute le JSON-LD en doublon.

Autre piège classique : les frameworks JavaScript modernes (Next.js, Nuxt, Gatsby) qui génèrent les breadcrumbs côté client après le premier paint. Google peut crawler la page avant que le JavaScript ne s'exécute complètement. Résultat : pas de breadcrumbs vus, pas de structure comprise. Il faut impérativement du SSR ou du SSG pour ces éléments critiques.

Comment vérifier que mon site est conforme ?

Lance un test Mobile-Friendly sur une page type (par exemple, une fiche produit en e-commerce ou un article de blog). Inspecte le HTML généré et cherche la présence du balisage itemtype="http://schema.org/BreadcrumbList" ou du JSON-LD équivalent. Si tu ne le trouves pas, c'est que Google ne le voit pas non plus.

Utilise aussi Screaming Frog en mode « Mobile Googlebot » pour crawler ton site et extraire les breadcrumbs détectés. Compare avec un crawl en user-agent desktop. Toute différence est un signal d'alerte. Et c'est là que beaucoup de sites découvrent qu'ils ont un problème.

• Vérifie que les breadcrumbs sont présents dans le HTML mobile via l'Inspection d'URL de la Search Console.
• Assure-toi que le balisage Schema.org BreadcrumbList est généré côté serveur ou lors du premier rendu (SSR/SSG).
• Évite les display:none sur mobile pour masquer les breadcrumbs — préfère un affichage réduit ou une solution UX alternative.
• Crawle ton site avec Screaming Frog en user-agent mobile et compare avec desktop pour détecter les écarts.
• Teste systématiquement chaque template important (homepage, catégorie, produit, article) pour valider la présence des breadcrumbs.
• Documente tes choix techniques : si tu masques les breadcrumbs visuellement mais les gardes dans le DOM, note-le pour éviter qu'un développeur futur ne les supprime.