Les URLs avec fragments (#) sont-elles vraiment invisibles pour Google ?

Pourquoi Google ignore-t-il les fragments dans les URLs ?

Le caractère # dans une URL est traditionnellement un marqueur côté client qui indique au navigateur un point d'ancrage dans la page. Historiquement, ce fragment n'est jamais transmis au serveur lors d'une requête HTTP. Google a toujours considéré que les variations d'une même URL séparées uniquement par un fragment représentent une seule et même ressource.

Cette approche pose un problème majeur pour les Single Page Applications (SPA) qui utilisent des frameworks JavaScript modernes. Ces applications chargent souvent du contenu dynamique en modifiant uniquement le fragment, créant ainsi des « pseudo-pages » que l'utilisateur perçoit comme distinctes mais que Google voit comme identiques.

Quelle est la différence entre une ancre classique et du contenu Ajax ?

Une ancre classique (page.html#section2) sert à scroller vers une partie visible d'une page déjà chargée. Le contenu existe déjà dans le HTML source. Google peut donc l'indexer sans problème car tout est présent dès le chargement initial.

Avec du contenu Ajax chargé dynamiquement, le fragment déclenche une requête JavaScript asynchrone qui récupère et affiche du nouveau contenu. Ce contenu n'existe pas dans le HTML initial que Googlebot crawle. Même si Googlebot exécute du JavaScript, il ne comprend pas que #produit1 et #produit2 sont censés afficher des contenus différents s'ils reposent uniquement sur le fragment.

Quelles sont les alternatives techniques recommandées ?

La solution moderne consiste à utiliser l'API History pushState/replaceState. Cette API HTML5 permet de modifier l'URL complète dans la barre d'adresse sans recharger la page, tout en conservant l'expérience fluide d'une SPA. Google traite ces URLs comme des pages distinctes et crawlables.

L'autre option, désormais obsolète mais mentionnée par Mueller, est le schéma de crawling Ajax avec le fragment #! (hashbang). Google a officiellement déprécié cette méthode mais elle reste techniquement fonctionnelle. Elle nécessite que le serveur serve une version HTML statique de chaque état de l'application via un paramètre _escaped_fragment_.

• Fragments simples (#) : ignorés par Google, pas d'indexation séparée
• URLs propres avec pushState : solution moderne recommandée, crawl et indexation normaux
• Schéma hashbang (#!) : obsolète mais fonctionnel, complexe à maintenir
• Rendu côté serveur (SSR) : garantit que le contenu existe dans le HTML initial
• Prerendering : génère des snapshots HTML pour les crawlers

Cette déclaration est-elle cohérente avec les pratiques observées sur le terrain ?

Absolument. Les tests empiriques confirment que Google normalise systématiquement les URLs en supprimant le fragment avant de les traiter. Si vous soumettez exemple.com/page#section1 et exemple.com/page#section2 dans la Search Console, Google les traite comme la même URL canonique : exemple.com/page.

Les crawls de logs serveur montrent que Googlebot ne transmet jamais le fragment dans ses requêtes HTTP. C'est techniquement impossible puisque le fragment est géré uniquement par le navigateur. Les SPAs mal configurées souffrent régulièrement de problèmes d'indexation pour exactement cette raison, avec des sections entières de contenu invisibles pour Google.

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

Mueller parle d'URLs « ne contenant que le caractère # », ce qui laisse une zone grise. En réalité, Google ignore complètement tout ce qui suit le #, quelle que soit sa longueur ou sa complexité. L'expression « ne contenant que » peut prêter à confusion : même #tres-long-fragment-complexe est ignoré.

La déclaration ne précise pas le comportement pour les ancres vers des éléments dynamiquement injectés. Si du JavaScript charge du contenu puis ajoute des ID aux éléments, Google pourrait théoriquement scroller vers ces ancres lors du rendu JavaScript. [A verifier] en conditions réelles, car le timing d'exécution JavaScript peut varier.

Dans quels cas cette limitation pose-t-elle des problèmes critiques ?

Les applications e-commerce en SPA qui gèrent les filtres produits via fragments sont particulièrement vulnérables. Si chaque combinaison de filtres génère une URL comme /produits#couleur=rouge&taille=M, Google ne voit qu'une seule page /produits avec un seul jeu de produits. Le reste du catalogue devient orphelin du point de vue SEO.

Les dashboards et interfaces d'administration utilisent souvent des fragments pour la navigation entre onglets. Ce n'est pas problématique si ces contenus n'ont pas besoin d'être indexés. Mais attention aux sites de documentation technique ou aux portails clients qui mélangent contenu public et privé : le contenu accessible uniquement via fragments reste invisible dans les SERP.

Que faut-il faire concrètement pour résoudre ce problème ?

Commencez par un audit technique complet pour identifier toutes les URLs contenant des fragments sur votre site. Utilisez des outils comme Screaming Frog en mode JavaScript, ou analysez les logs analytics pour repérer les patterns de navigation utilisateur qui ne correspondent à aucune URL crawlée par Google.

Si vous gérez une SPA, implémentez l'API History pushState pour remplacer la navigation par fragments. Cette modification nécessite généralement des ajustements dans votre framework JavaScript (React Router, Vue Router, Angular Router supportent tous pushState nativement). Assurez-vous que votre serveur est configuré pour renvoyer la bonne page HTML quelle que soit l'URL demandée, avec éventuellement un fallback sur index.html.

Comment vérifier que Google crawle correctement vos contenus dynamiques ?

Utilisez l'outil d'inspection d'URL de la Search Console pour tester le rendu de vos pages critiques. Comparez la version crawlée avec ce que voient vos utilisateurs. Si du contenu manque dans la version crawlée, c'est que votre implémentation JavaScript pose problème.

Surveillez les rapports de couverture d'index après toute modification d'architecture. Une baisse soudaine du nombre de pages indexées peut indiquer que Google ne suit plus correctement vos liens internes. Croisez avec les données de trafic organique par landing page pour identifier les contenus qui ont perdu leur visibilité.

Quelles erreurs critiques faut-il absolument éviter ?

Ne supposez jamais que parce que votre site « fonctionne » en JavaScript, Google indexera tout automatiquement. Le rendu JavaScript de Google a des limites : timeout d'exécution, ressources bloquées, erreurs silencieuses. Testez systématiquement avec des crawlers et la Search Console.

Évitez de mélanger plusieurs approches (fragments, pushState, hashbang) sur le même site. Cette incohérence architecturale crée de la confusion pour les crawlers et complique le suivi analytics. Choisissez une stratégie unique et appliquez-la uniformément.

• Auditer toutes les URLs contenant des fragments (#) sur votre site
• Remplacer la navigation par fragments par pushState dans les SPAs
• Configurer le serveur pour gérer correctement les URLs rewritées
• Tester le rendu Google via l'outil d'inspection d'URL de la Search Console
• Mettre en place des redirections 301 si vous migrez d'anciennes URLs avec fragments
• Surveiller les rapports de couverture d'index après chaque modification