Pourquoi les URLs avec hashbangs (#!) sont-elles un boulet pour votre référencement ?

Qu'est-ce qu'un hashbang et pourquoi était-ce utilisé ?

Le hashbang (#!) était une technique populaire dans les années 2010 pour créer des applications web monopage (SPA) avec du contenu dynamique. L'idée était simple : utiliser le fragment d'URL après le dièse pour charger différentes vues via JavaScript, sans recharger la page.

Google avait même proposé un système de traduction où example.com/#!/article devenait example.com/?_escaped_fragment_=/article pour les robots. Ce système a été abandonné depuis, rendant les hashbangs encore plus problématiques pour l'indexation.

En quoi les hashbangs posent-ils un problème technique pour l'indexation ?

Les fragments d'URL (tout ce qui suit le #) ne sont jamais envoyés au serveur lors d'une requête HTTP. Seul le JavaScript côté client peut les lire et agir en conséquence. Pour Googlebot, cela signifie un travail supplémentaire : exécuter le JS, attendre que le contenu se charge, espérer que tout fonctionne.

La réalité du terrain ? Le budget de crawl est gaspillé, le temps de rendu explose, et l'indexation devient aléatoire selon la complexité de votre code JavaScript. Sans parler des autres moteurs comme Bing ou Yandex, historiquement moins performants sur le rendu JS.

Que signifie concrètement une "structure d'URL propre" selon Google ?

Google parle d'URLs qui fonctionnent sans scripts côté client. Cela veut dire qu'une requête HTTP classique vers l'URL doit retourner le contenu complet, ou au minimum une version HTML exploitable par les robots.

Les solutions techniques actuelles incluent le Server-Side Rendering (SSR), le Static Site Generation (SSG), ou l'hydratation progressive. L'objectif : que chaque URL corresponde à une ressource serveur identifiable, avec un code HTTP 200 et du contenu dans le HTML initial.

• Évitez les URLs du type site.com/#!page/article ou site.com/#/produit/123
• Préférez des URLs comme site.com/page/article ou site.com/produit/123
• Assurez-vous que le contenu principal est présent dans le HTML source, pas uniquement injecté par JavaScript après coup
• Testez vos URLs avec un simple curl ou en désactivant JavaScript : le contenu essentiel doit être visible
• Vérifiez dans la Search Console que vos pages sont indexées avec le bon contenu, pas juste une coquille vide

Cette directive est-elle encore d'actualité avec les progrès de Googlebot sur le JavaScript ?

Googlebot a effectivement progressé dans le rendu JavaScript depuis 2015, mais affirmer qu'il gère parfaitement tous les frameworks modernes est un mythe. Les observations terrain montrent des comportements erratiques : timeout sur les ressources lourdes, problèmes avec les requêtes API asynchrones, indexation partielle sur les sites avec beaucoup de JS.

La position de Müller reste donc pertinente. Même si Googlebot peut techniquement indexer du contenu chargé en JS, cela reste coûteux en ressources et moins fiable qu'une URL serveur classique. Sur des sites avec des milliers de pages, cette différence devient critique pour votre visibilité.

Quelles sont les nuances à apporter selon le type de site ?

Un site vitrine de 20 pages peut se permettre du JavaScript intensif si le budget de crawl n'est pas un souci. Mais un e-commerce avec 10 000 fiches produits ? Là, chaque milliseconde de rendu compte, et les hashbangs deviennent un handicap structurel.

Les applications web complexes (SaaS, plateformes) ont souvent une partie publique qui doit être référencée et une partie privée (dashboard) qui ne l'est pas. Pour la partie publique, l'usage de SSR ou SSG devient non négociable. Pour la partie privée derrière authentification, peu importe : les hashbangs n'ont aucun impact SEO puisque ces pages ne doivent pas être indexées.

Que faire si votre site utilise encore des hashbangs aujourd'hui ?

Soyons honnêtes : migrer une architecture complète n'est pas trivial. Cela implique souvent de refondre le routage de votre application, de mettre en place un SSR, et de gérer les redirections 301 depuis les anciennes URLs. Le risque de perte de trafic temporaire existe.

Deux approches pragmatiques : soit une migration progressive par sections du site (commencez par les pages prioritaires), soit l'implémentation d'un système hybride où les URLs propres coexistent temporarement avec les anciennes. Dans tous les cas, un audit technique préalable est indispensable pour identifier les dépendances. [A vérifier] : aucune donnée Google ne quantifie précisément l'impact SEO négatif des hashbangs versus des URLs propres, mais les études de cas montrent des gains d'indexation de 30 à 50% après migration.

Comment vérifier si votre site est impacté par ce problème ?

Première étape : ouvrez votre site et regardez la barre d'adresse. Voyez-vous des #! ou #/ dans vos URLs de navigation ? Si oui, vous êtes concerné. Deuxième test : désactivez JavaScript dans votre navigateur (DevTools > Settings > Disable JavaScript) et naviguez sur votre site.

Si le contenu principal disparaît ou si la navigation casse complètement, c'est un signal d'alarme. Utilisez aussi l'outil d'inspection d'URL de la Search Console pour comparer le HTML brut et le HTML rendu : un écart important indique une dépendance excessive au JavaScript.

Quelles actions concrètes mettre en place pour corriger l'architecture ?

La solution dépend de votre stack technique. Avec React, optez pour Next.js qui offre SSR et SSG nativement. Avec Vue, Nuxt.js remplit le même rôle. Angular propose Angular Universal pour le server-side rendering.

Si vous partez de zéro ou refondez, privilégiez le Static Site Generation quand c'est possible : vous générez toutes vos pages en HTML statique au build, et le SEO devient trivial. Pour du contenu très dynamique (prix changeants, stocks), combinez SSG avec des requêtes API côté client pour les données volatiles uniquement.

Quels pièges éviter lors de la migration ?

Le piège classique : oublier les redirections 301 depuis les anciennes URLs avec hashbang. Problème : les hashbangs ne sont pas envoyés au serveur, donc une redirection serveur classique ne peut pas les intercepter. Solution : gérer les redirections en JavaScript côté client pour les anciennes URLs, puis rediriger vers les nouvelles URLs propres.

Autre erreur fréquente : implémenter du SSR mais oublier les balises meta essentielles (title, description, canonical) dans le rendu initial. Vérifiez que votre SSR génère un HTML complet avec toutes les métadonnées SEO dès la première réponse serveur, pas juste une structure vide complétée après par le JS.

• Auditez toutes vos URLs pour identifier celles contenant des fragments #! ou #/
• Testez le contenu visible avec JavaScript désactivé sur un échantillon représentatif de pages
• Comparez le HTML source (View Source) au HTML rendu dans l'inspecteur pour mesurer la dépendance JS
• Planifiez une stratégie de migration adaptée à votre framework (SSR, SSG, ou hybride)
• Mettez en place un mapping complet ancien/nouveau format d'URL avec redirections 301 gérées côté client si nécessaire
• Surveillez l'indexation dans la Search Console après migration et corrigez rapidement toute chute anormale