Pourquoi Google déconseille-t-il les fragments d'URL (#) pour l'indexation mobile ?

Qu'est-ce qu'un fragment d'URL et pourquoi pose-t-il problème ?

Un fragment d'URL est la partie après le symbole dièse (#) dans une adresse web, comme example.com/page#section2. Historiquement, les navigateurs utilisent ces fragments pour naviguer vers des ancres dans la page, sans déclencher de nouvelle requête HTTP.

Le problème ? Googlebot ignore traditionnellement ce qui suit le # car il considère que c'est une instruction côté client, pas une ressource distincte. Si votre site mobile charge du contenu dynamique via des fragments (technique populaire dans les single-page applications des années 2010-2015), Google ne voit probablement pas ce contenu.

Pourquoi cette recommandation vise-t-elle spécifiquement le mobile ?

Avec l'indexation mobile-first généralisée, Google crawle et indexe prioritairement la version mobile de votre site. Si cette version repose sur des fragments pour afficher du contenu, vous créez un angle mort dans l'index.

Les frameworks JavaScript anciens (Angular.js avec son routing #, certaines implémentations React mal configurées) utilisaient massivement cette approche. Sur desktop, ces sites pouvaient s'en sortir avec des workarounds (escaped fragments, prerendering). En mobile-first, ces béquilles ne suffisent plus : Google veut des URLs propres, point final.

Que signifie concrètement « URLs claires et accessibles » ?

Google parle d'URLs canoniques standards : example.com/produits/chaussures plutôt que example.com/#/produits/chaussures. Chaque ressource indexable doit avoir sa propre URL HTTP, accessible directement par GET, sans nécessiter d'exécution JavaScript côté client pour révéler le contenu.

Cela implique aussi que votre serveur doit répondre avec un 200 sur ces URLs, pas un 404 qui redirige ensuite via JS. Le HTML initial servi doit contenir le contenu principal, ou au minimum un squelette suffisant pour que Googlebot comprenne la page avant même d'exécuter le JavaScript.

• Évitez les fragments (#) pour router des contenus distincts — chaque page indexable doit avoir son URL propre
• Privilégiez le History API (pushState) pour les single-page applications modernes, qui permet des URLs propres sans rechargement
• Vérifiez le rendu mobile dans Search Console pour confirmer que Googlebot voit bien votre contenu principal
• Testez vos URLs en navigation privée JavaScript désactivé : si vous ne voyez rien, Google ne voit probablement rien non plus
• Configurez un prerendering SSR ou SSG si votre stack impose des compromis (Next.js, Nuxt, Gatsby pour éviter ce problème dès la conception)

Cette directive est-elle cohérente avec ce qu'on observe sur le terrain ?

Oui, et c'est même un problème récurrent en audit. Les sites qui ont migré vers des frameworks JS sans revoir leur architecture URL se retrouvent avec des pages fantômes : elles existent pour l'utilisateur, mais pas pour Google. J'ai vu des e-commerces perdre 40% de leur trafic organique après une refonte React mal calibrée, précisément à cause de ce genre d'erreur.

Ce qui est intéressant, c'est que Google ne parle plus des escaped fragments (le hack #!/ des années 2012-2015). Cette technique est morte et enterrée. Si vous en avez encore dans votre code legacy, c'est le moment de refondre [À vérifier] si vous n'avez pas déjà constaté une érosion de positions.

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

Les ancres de navigation interne classiques ne posent aucun problème : example.com/guide-seo#chapitre-3 fonctionne parfaitement. Google indexe l'URL de base et ignore le fragment pour l'indexation, mais l'utilisateur arrive bien au bon endroit. C'est l'usage prévu des fragments, et ça marche.

Deuxième exception : les paramètres de tracking ou d'UI (modales, onglets, filtres légers) passés en fragment. Exemple : example.com/produits#filtre-couleur-rouge. Tant que le contenu principal existe dans le DOM initial et que le fragment ne change que l'affichage, Google s'en fiche. Le risque apparaît quand le fragment charge du contenu distinct qui n'existe nulle part ailleurs.

Quelles nuances faut-il apporter à cette recommandation ?

John Mueller reste vague sur un point : quid du JavaScript rendering et des budgets crawl ? Google affirme exécuter le JS, mais on sait que ce rendering coûte cher et n'est pas systématique. Un site qui force Google à exécuter du JS pour révéler des URLs cachées derrière des fragments consomme son crawl budget pour rien.

Autre nuance : cette recommandation vise surtout les sites à fort volume de pages. Si vous avez 10 pages statiques avec quelques ancres, personne ne va vous pénaliser. Mais pour un site de 10 000 fiches produits routées en #, c'est un carnage assuré.

Que faut-il vérifier en priorité sur votre site mobile ?

Première étape : auditer vos URLs en navigation mobile. Ouvrez votre site sur mobile, naviguez, et observez la barre d'adresse. Si vous voyez des # qui changent à chaque clic sans que l'URL de base ne bouge, vous avez un problème. Complétez avec un crawl Screaming Frog ou Oncrawl en user-agent mobile pour lister toutes les URLs réellement accessibles.

Deuxième vérification : Search Console, onglet Couverture. Regardez les pages « Détectées, actuellement non indexées ». Si vous voyez des patterns d'URLs qui devraient être indexés mais ne le sont pas, croisez avec votre liste de fragments. Utilisez aussi l'outil d'inspection d'URL pour tester le rendu mobile de pages suspectes.

Comment corriger une architecture reposant sur des fragments ?

La solution technique dépend de votre stack. Pour les single-page applications modernes, passez au History API (pushState/replaceState) qui permet des URLs propres sans fragments. Frameworks comme React Router, Vue Router, Angular (versions récentes) le supportent nativement. Configurez-les en mode « history » plutôt que « hash ».

Pour les sites legacy ou les stacks complexes, envisagez le server-side rendering (SSR) ou le static site generation (SSG). Next.js, Nuxt, Gatsby résolvent ce problème à la racine en générant des pages HTML complètes avec URLs canoniques. Cela demande une refonte, mais c'est l'occasion de moderniser toute votre architecture.

Quelles erreurs éviter lors de la migration ?

Erreur classique : oublier les redirections 301. Si vos anciennes URLs avec fragments étaient référencées (backlinks, partages sociaux), vous devez rediriger proprement. Problème : on ne peut pas rediriger un fragment côté serveur (il n'est jamais envoyé au serveur). Solution : JavaScript côté client qui détecte les anciens patterns et redirige vers les nouvelles URLs propres.

Autre piège : casser le crawl budget en dupliquant tout. Si vous gardez à la fois les anciennes URLs fragmentées ET les nouvelles URLs propres accessibles, vous créez du duplicate content massif. Choisissez une seule structure canonique et forcez-la partout (rel=canonical, redirections, liens internes cohérents).

• Crawler votre site mobile et lister toutes les URLs contenant des # qui servent du contenu distinct
• Configurer votre framework JS en mode « history » pour générer des URLs propres sans fragments
• Implémenter des redirections JavaScript pour les anciens fragments si nécessaire (et documenter cette dette technique)
• Mettre à jour tous les liens internes et le sitemap XML pour pointer vers les nouvelles URLs canoniques
• Vérifier le rendu mobile dans Search Console après migration et surveiller les erreurs 404 pendant 3 mois minimum
• Tester en conditions réelles : navigation privée, JS désactivé, connexion 3G lente — si ça marche, Google verra votre contenu