Les fragments d'URL cassent-ils vraiment l'indexation des sites JavaScript ?

Pourquoi Google supprime-t-il les fragments d'URL lors de l'indexation ?

Les fragments d'URL (la partie après le #) ont été conçus historiquement pour la navigation interne côté client, pas pour identifier des ressources distinctes côté serveur. Le navigateur ne les envoie jamais au serveur lors d'une requête HTTP — seul le JavaScript côté client peut les lire.

Google a décidé de normaliser cette logique dans son système d'indexation : lorsque Googlebot rencontre une URL avec un fragment, il le retire avant de la traiter. Résultat : https://exemple.com/page#section-A et https://exemple.com/page#section-B sont considérées comme une seule et même URL pour l'index de Google. Cette règle s'applique à la quasi-totalité des sites web actuels.

Qu'est-ce que l'exception pour les « sites historiques » mentionnée par Mueller ?

Il existe un mécanisme d'indexation archaïque appelé « hash-bang » (#!), introduit par Google en 2009 puis officiellement déprécié en 2015. Quelques très vieux sites — on parle de vestiges du web pré-HTML5 — utilisent encore ce système obsolète. Google maintient un support minimal pour eux, mais c'est une exception quasi fossile qui ne concerne pratiquement plus personne.

Si ton site a été mis en ligne après 2015 et que tu te demandes si tu es concerné par cette exception, la réponse est non. Cette mention de Mueller sert surtout à préciser qu'il existe une infime minorité de cas où les fragments sont encore traités, mais elle ne doit pas créer de faux espoir.

Pourquoi les frameworks JavaScript modernes posent-ils problème avec cette règle ?

De nombreuses Single Page Applications (SPA) construites avec React, Vue ou Angular utilisent le routing côté client basé sur les fragments. Quand un utilisateur clique sur un lien interne, le framework charge du nouveau contenu via JavaScript sans recharger la page — et change souvent l'URL en ajoutant ou modifiant un fragment.

Le piège : si ton contenu n'est rendu que lorsque le fragment est présent, et que Googlebot supprime ce fragment avant d'indexer, alors ton contenu n'existe tout simplement pas pour Google. Le bot voit une coquille vide. C'est exactement ce que Mueller pointe ici : une configuration technique qui rend ton contenu invisible par design.

• Googlebot supprime les fragments (#hash) avant l'indexation — c'est une règle quasi universelle
• Les sites JavaScript qui chargent du contenu conditionné par un fragment créent du contenu invisible pour Google
• L'exception « sites historiques » est un cas limite archaïque (hash-bang pré-2015) qui ne concerne pratiquement plus personne
• Les SPA modernes doivent utiliser le HTML5 History API (pushState/replaceState) pour un routing compatible SEO
• Si ton URL contient un #, demande-toi si le contenu affiché dépend de ce fragment — si oui, c'est un signal d'alarme

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

Oui, totalement. Les audits techniques sur des milliers de sites JavaScript confirment que les fragments sont un angle mort récurrent. On voit régulièrement des SPA avec des sections entières de contenu — FAQ, descriptions produits, articles de blog — rendues uniquement quand un fragment spécifique est présent dans l'URL. Google ne voit rien.

La confusion vient souvent d'une incompréhension entre navigation client et indexation serveur. Les développeurs testent leur site dans un navigateur moderne, voient le contenu se charger correctement, et pensent que tout va bien. Sauf que Googlebot fonctionne différemment : il supprime le fragment avant même de commencer le rendu. Ce que le bot indexe, c'est l'état initial de la page sans fragment — souvent un shell vide.

Quelles nuances faut-il apporter à cette affirmation de Mueller ?

La déclaration est juste mais manque de précision sur un point clé : le moment où Google supprime le fragment. Certains praticiens pensent que le bot exécute d'abord le JavaScript, voit le contenu se charger, puis normalise l'URL. C'est faux. [À vérifier] Google retire le fragment avant le rendu, ce qui signifie que ton code JavaScript ne reçoit jamais l'information du fragment lors de l'exécution par Googlebot.

Autre nuance : les fragments peuvent être utiles pour l'expérience utilisateur (ancres de navigation interne, scroll vers une section) tant qu'ils ne conditionnent pas l'affichage du contenu. Si ton contenu est déjà présent dans le DOM initial et que le fragment sert juste à scroller, aucun problème. Le piège, c'est quand le fragment déclenche un chargement différé ou un rendu conditionnel.

Dans quels cas cette règle ne s'applique-t-elle pas ou pose-t-elle des problèmes inattendus ?

Cas limite intéressant : les PWA (Progressive Web Apps) qui utilisent des fragments pour gérer l'état de l'application sans recharger la page. Si tu construis une PWA complexe avec plusieurs vues, chaque vue devrait idéalement avoir sa propre URL propre (sans fragment) pour être indexable. Mais dans la pratique, certaines parties de l'application n'ont pas besoin d'être indexées — un dashboard utilisateur privé, par exemple.

Là où ça coince vraiment : les sites qui ont migré d'un ancien système hash-bang vers une SPA moderne sans changer leur structure d'URL. Ils pensent avoir résolu le problème en passant à React ou Vue, mais continuent d'utiliser des fragments parce que « ça a toujours marché comme ça ». Résultat : une régression SEO invisible pendant des mois. La migration technique ne suffit pas si l'architecture d'URL reste cassée.

Que faut-il faire concrètement pour éviter ce piège d'indexation ?

Première étape : auditer ton routing JavaScript. Ouvre les DevTools de ton navigateur, active le throttling réseau pour simuler un bot lent, et vérifie si ton contenu principal se charge même sans fragment dans l'URL. Si tu charges /page et que des sections entières sont vides, c'est que tu as un problème de dépendance aux fragments.

Ensuite, migre vers le HTML5 History API (pushState/replaceState). Tous les frameworks modernes le supportent nativement : React Router, Vue Router, Angular Router. Configure ton routing pour utiliser des URLs « propres » sans fragments. Au lieu de /page#section-A, utilise /page/section-A. Le serveur doit être configuré pour servir la même application sur toutes ces routes, puis le JavaScript prend le relais côté client.

Comment vérifier que le contenu est bien indexable par Google ?

Utilise l'outil d'inspection d'URL dans Search Console pour tester tes pages critiques. Compare la version « rendue » (ce que Google voit après exécution du JavaScript) avec ton HTML source. Si des blocs de contenu manquent dans la version rendue, c'est un signal d'alarme. Teste spécifiquement les URLs qui contenaient des fragments avant ta migration.

Autre vérification : lance un crawl avec Screaming Frog en mode JavaScript et compare-le à un crawl classique. Si le nombre de mots par page ou les éléments structurels (titres, listes, tableaux) diffèrent drastiquement, tu as probablement du contenu qui ne charge que conditionnellement. Prête attention aux pages avec un faible ratio texte/code : elles sont souvent symptomatiques d'un rendu JavaScript incomplet.

Quelles erreurs éviter lors de la refonte d'un site JavaScript ?

Erreur classique : garder les anciennes URLs avec fragments en place « au cas où ». Ça crée de la duplication et de la confusion. Si tu migres vers des URLs propres, redirige les anciennes URLs avec fragments vers leurs équivalents sans fragments côté serveur. Le serveur doit ignorer le fragment (il ne le reçoit jamais de toute façon) et servir la bonne page.

Autre piège : tester uniquement en tant qu'utilisateur connecté ou sur un environnement de dev. Google crawle en tant que visiteur anonyme. Si ton contenu se charge différemment selon l'état de session ou nécessite une interaction utilisateur (clic, scroll infini) pour apparaître, il ne sera pas indexé. Le contenu critique doit être présent dans le HTML initial ou chargé automatiquement au premier rendu, sans action utilisateur requise.

• Auditer toutes les URLs contenant des fragments (#) dans Search Console et Analytics
• Migrer le routing JavaScript vers HTML5 History API (pushState/replaceState)
• Configurer le serveur pour servir l'application sur toutes les routes propres
• Tester l'indexation avec l'outil d'inspection d'URL de Search Console sur les pages critiques
• Mettre en place des redirections 301 côté serveur pour les anciennes URLs si nécessaire (même si le serveur ignore les fragments, anticipe les liens externes)
• Vérifier que le contenu principal est présent dans le DOM initial ou chargé automatiquement sans interaction utilisateur