Pourquoi Google refuse-t-il d'indexer les URLs avec hash ?

Quelle est la différence technique entre hash et pushState ?

Les URLs avec hash utilisent le symbole # pour définir des ancres ou des routes côté client (ex: example.com/#/produit). Historiquement, les navigateurs ne transmettent pas la partie après le # au serveur — c'est un mécanisme purement client-side. Google ignore cette portion lors du crawl, car il la considère comme un identifiant de fragment, pas comme une ressource distincte.

La méthode pushState, introduite avec l'API HTML5 History, permet de modifier l'URL affichée sans recharger la page (ex: example.com/produit). Le serveur reçoit cette URL complète lors d'un accès direct, et Google peut la crawler comme n'importe quelle page classique. C'est le standard pour les applications JavaScript modernes qui veulent rester crawlables.

Pourquoi cette distinction pose-t-elle problème aux SPA ?

Les single-page applications (React, Vue, Angular) ont longtemps utilisé les hashes pour gérer la navigation sans rafraîchir la page. C'était simple à implémenter et ne nécessitait aucune configuration serveur. Mais cette facilité a un prix : Google voit une seule URL, celle sans le hash.

Résultat ? Un site avec 50 pages produits différentes, toutes accessibles via example.com/#/produit-1, #/produit-2, etc., n'apparaît dans l'index que comme une unique page : example.com. Le contenu dynamique chargé via JavaScript après le hash reste invisible pour le moteur. C'est un problème critique pour les sites e-commerce ou médias qui dépendent du trafic organique.

Google a-t-il déjà tenté de crawler les hashes ?

Oui, et c'est là que ça devient historiquement intéressant. Google a introduit un schéma temporaire avec #! (hashbang) pour permettre l'indexation des contenus AJAX. Ce système exigeait que le serveur fournisse une version HTML statique de la page lors d'une requête spéciale (_escaped_fragment_). C'était bancal, lourd à maintenir, et Google l'a officiellement abandonné.

Depuis, la position est claire : pas d'indexation des hashes. Google pousse les développeurs vers pushState et le rendu côté serveur (SSR) ou l'hydratation. La déclaration de Splitt ne fait que confirmer une règle en vigueur depuis des années, mais que beaucoup de sites ignorent encore.

• Les URLs avec hash (#) ne sont pas transmises au serveur et restent invisibles pour Google
• pushState permet de créer des URLs crawlables sans rechargement de page
• L'ancien système hashbang (#!) a été abandonné par Google
• Les SPA doivent utiliser le routage côté client avec pushState ou implémenter du SSR
• Sans pushState, un site avec 100 routes n'apparaît dans l'index que comme une seule page

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

Absolument. Les audits SEO révèlent régulièrement des sites SPA avec zéro pages indexées malgré un contenu riche, uniquement parce qu'ils utilisent des hashes. Google Search Console affiche alors une seule URL dans l'index, et les développeurs sont perplexes devant l'absence de trafic organique. Ce n'est pas un bug, c'est le comportement documenté du crawler.

Cependant, il faut nuancer : certains sites hybrides utilisent des hashes pour des éléments de navigation secondaires (onglets, modales, filtres) sans impact SEO négatif. Le problème apparaît quand le hash définit le contenu principal. Si votre article de blog est accessible uniquement via example.com/#article-123, il n'existe pas aux yeux de Google.

Quelles sont les exceptions ou cas limites à surveiller ?

Google indexe les ancres classiques (liens vers #section-2 d'une même page) pour les featured snippets et la navigation interne, mais il ne les traite pas comme des pages distinctes. Si vous utilisez des hashes pour du scroll vers une section, pas de souci. Le problème concerne uniquement les routes applicatives.

Autre point rarement mentionné : certains frameworks JavaScript modernes (Next.js, Nuxt) gèrent automatiquement pushState et le SSR, rendant ce problème invisible pour le développeur. Mais si vous construisez une SPA custom ou utilisez une ancienne version de React Router en mode hash, vous êtes directement concerné. [A vérifier] : Google pourrait-il un jour crawler les hashes dans un contexte d'applications web progressives ? Rien ne l'indique aujourd'hui.

Faut-il migrer un site existant en hash vers pushState ?

Si votre site génère du trafic SEO significatif, oui, c'est une priorité technique. Mais attention : migrer vers pushState exige une configuration serveur correcte. Toutes les routes doivent renvoyer la même application JavaScript avec un code 200, sinon les accès directs (via un lien externe ou un bookmark) génèrent des 404.

Concrètement, si un utilisateur accède à example.com/produit/chaussures, le serveur doit servir l'application, puis JavaScript charge le contenu correspondant. Sans cette config (redirections Apache/Nginx vers index.html), la migration casse le site. C'est un chantier technique qui nécessite tests et coordination entre dev et SEO.

Que faut-il faire concrètement pour migrer vers pushState ?

Première étape : auditer votre architecture. Si vous utilisez un framework moderne (Next.js, Nuxt, Angular en mode HTML5), pushState est probablement déjà actif. Vérifiez la configuration du routeur : cherchez des options comme mode: 'history' (Vue Router) ou useHash: false (Angular). Si vous trouvez mode: 'hash', c'est là qu'il faut agir.

Deuxième étape : configurer le serveur. Toutes les routes doivent pointer vers votre fichier HTML principal. Avec Apache, ajoutez une règle de réécriture dans .htaccess. Avec Nginx, utilisez try_files pour renvoyer index.html sur toute route inconnue. Sans ça, un accès direct à /produit/123 génère un 404 côté serveur, même si JavaScript sait gérer cette route.

Comment vérifier que Google crawle correctement après la migration ?

Utilisez l'outil d'inspection d'URL dans Search Console. Testez une route spécifique (ex: /categorie/seo) et vérifiez que Google voit le contenu attendu dans le rendu HTML. Si le rendu affiche une erreur 404 ou reste vide, votre config serveur est incorrecte. Le test d'URL en direct simule le crawl réel.

Surveillez aussi les rapports de couverture. Après migration, vous devriez voir apparaître progressivement les nouvelles URLs dans l'index. Si le nombre de pages indexées stagne ou chute, c'est un signal d'alerte. Google ne doit jamais rencontrer d'erreur 404 sur vos routes pushState. Un monitoring Log File Analysis permet de repérer les codes HTTP renvoyés au bot.

Quelles erreurs éviter lors de l'implémentation ?

L'erreur classique : oublier la balise base href ou mal gérer les chemins relatifs. Quand l'URL change côté client, les ressources CSS/JS peuvent se charger depuis un chemin incorrect. Testez chaque route en accès direct (F5 ou nouvel onglet) pour vérifier que tout charge correctement, pas seulement en navigation interne.

Autre piège : les liens internes en dur avec hash. Si votre ancien code contient des <a href="#/produit">, remplacez-les par des composants de routeur qui génèrent des URLs pushState. Sinon, vous mélangez les deux systèmes, créant des incohérences. Pensez aussi aux sitemaps : générez-les avec les nouvelles URLs sans hash.

• Auditer la configuration actuelle du routeur JavaScript (hash ou history)
• Configurer le serveur pour renvoyer index.html sur toutes les routes applicatives
• Tester chaque route en accès direct pour détecter les 404 serveur
• Valider le rendu HTML avec l'outil d'inspection Search Console
• Mettre à jour les sitemaps et les liens internes
• Monitorer les logs de crawl pour repérer les erreurs post-migration