Pourquoi les URL avec dièse (#) bloquent-elles l'indexation de vos pages Angular ?

Quelle est l'origine technique de ce problème avec le dièse ?

Le fragment d'URL (tout ce qui suit le #) était historiquement conçu pour la navigation côté client uniquement. Les navigateurs ne l'envoient jamais au serveur lors d'une requête HTTP. Lorsque vous accédez à exemple.com/#/produits, le serveur reçoit uniquement exemple.com.

Pour Googlebot, cette logique s'applique aussi : il considère que tout après le # ne fait pas partie de l'URL canonique. Deux URL comme exemple.com/#/produits et exemple.com/#/contact sont traitées comme la même ressource : exemple.com. C'est un héritage du web statique où le fragment servait uniquement aux ancres de navigation interne.

Pourquoi Angular utilisait-il ce système par défaut ?

Angular (et beaucoup de frameworks SPA avant lui) a longtemps utilisé le HashLocationStrategy comme mode de routing par défaut. L'avantage ? Aucune configuration serveur requise. Peu importe l'URL demandée, le serveur renvoie toujours index.html, et JavaScript gère ensuite le routing côté client.

Cette approche était pratique pour le développement et les environnements ne permettant pas de configurer facilement les redirections serveur. Mais elle créait un cauchemar SEO : toutes les pages de l'application partageaient la même URL aux yeux des moteurs de recherche.

Qu'est-ce que cela implique pour le crawl et l'indexation ?

Si votre site Angular conserve des URL avec dièse, Google n'indexera qu'une seule page : votre racine. Toutes vos sous-pages, fiches produits, articles de blog générés par le framework resteront invisibles dans les SERP. Le crawl s'arrête net à la racine puisque Googlebot ne considère pas les liens internes avec # comme des pages distinctes.

Même si Google exécute JavaScript, il applique cette règle en amont. Le rendu côté client ne change rien : le fragment est ignoré dès l'analyse de l'URL. C'est une décision architecturale du web, pas une limitation technique de Googlebot.

• HashLocationStrategy produit des URL non-indexables (exemple.com/#/page)
• PathLocationStrategy génère des URL propres (exemple.com/page) mais nécessite une configuration serveur
• Le pré-rendu côté serveur (SSR) peut contourner le problème en générant du HTML statique pour chaque route
• Google ne fait aucune exception : même avec un sitemap XML listant les URL avec #, elles ne seront pas indexées
• Les autres moteurs appliquent la même règle : Bing, Yandex ignorent également les fragments d'URL

Cette déclaration est-elle cohérente avec les observations terrain ?

Oui, sans ambiguïté. Des centaines de migrations Angular l'ont confirmé : le passage de HashLocationStrategy à PathLocationStrategy débloque l'indexation quasi instantanément. Les tests sont reproductibles et les résultats unanimes. Ce n'est pas une zone grise du SEO.

Ce qui surprend encore certains clients, c'est la radicalité de l'impact. On ne parle pas d'un léger handicap de ranking, mais d'une invisibilité totale. Google n'indexe littéralement qu'une page. Les logs serveur le confirment : Googlebot ne fait qu'une seule requête vers la racine, peu importe le nombre de liens internes.

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

La seule exception historique concernait les schémas d'URL AJAX crawlables avec #! (hashbang), que Google supportait entre 2009 et 2015. Ce système est obsolète depuis des années et ne doit plus être utilisé. Si vous tombez sur du legacy code avec des #!, migrez immédiatement.

Attention aussi aux hybrides mal configurés. Certains sites utilisent PathLocationStrategy mais génèrent quand même des liens avec # dans le HTML rendu, souvent à cause de composants tiers ou de mauvaises pratiques de routage. Un audit des liens internes s'impose : si vous voyez des href="#/quelque-chose", c'est un bug qui handicape votre crawl.

Faut-il toujours privilégier le SSR pour Angular ?

Le SSR (Server-Side Rendering) avec Angular Universal n'est pas obligatoire si vous basculez sur PathLocationStrategy et configurez correctement votre serveur pour servir index.html sur toutes les routes. Googlebot exécute JavaScript de manière fiable aujourd'hui. Le SSR apporte surtout un gain de vitesse perçue et de compatibilité avec les bots moins évolués.

Cela dit, pour un site e-commerce ou éditorial avec des milliers de pages, le SSR améliore significativement le crawl budget et la réactivité de l'indexation. Google préfère recevoir du HTML déjà hydraté plutôt que d'attendre l'exécution JavaScript. Sur les gros volumes, cette différence se chiffre en semaines de délai d'indexation. [À vérifier] : Google n'a jamais publié de métriques officielles sur l'impact du SSR sur le crawl budget pour les SPA, mais les observations terrain plaident fortement en sa faveur.

Comment vérifier si votre site Angular utilise des URL avec dièse ?

Ouvrez votre navigateur et naviguez sur plusieurs pages de votre application. Regardez la barre d'adresse : si vous voyez des # suivis de chemins (/produits, /contact, etc.), vous êtes en HashLocationStrategy. Vérifiez aussi le code source de votre composant AppRoutingModule : la présence de {useHash: true} dans RouterModule.forRoot() confirme le problème.

Testez ensuite l'indexation réelle : faites un site:votredomaine.com dans Google. Si seule la homepage apparaît alors que vous avez des dizaines de pages, c'est un indicateur fort. Utilisez aussi Google Search Console pour analyser les pages découvertes versus indexées : un écart massif suggère un souci de routing.

Que faut-il modifier concrètement dans votre application Angular ?

Dans votre fichier de routing principal (app-routing.module.ts), assurez-vous que RouterModule.forRoot() n'inclut PAS l'option {useHash: true}. Par défaut, Angular utilise PathLocationStrategy depuis les versions récentes, mais vérifiez si un développeur n'a pas forcé le mode hash.

Côté serveur, configurez un fallback vers index.html pour toutes les routes non-fichiers. Sur Nginx : try_files $uri $uri/ /index.html; Sur Apache : FallbackResource /index.html dans .htaccess. Sans cette config, un refresh sur exemple.com/produits renverra une 404 car le serveur cherche un fichier produits.html inexistant.

Quelles erreurs éviter lors de la migration ?

Ne migrez pas sans mettre en place des redirections 301 si votre ancien site avec # était partiellement indexé ou linkait par d'autres sites. Même si Google ignorait les fragments, des utilisateurs ont peut-être bookmarké des URL avec #. Redirigez proprement exemple.com/#/produits vers exemple.com/produits côté client avec un script de détection.

Ne négligez pas le sitemap XML après migration. Générez-le avec vos nouvelles URL propres et soumettez-le dans Search Console pour accélérer la découverte. Surveillez les erreurs 404 dans les semaines suivantes : elles révèlent souvent des liens internes mal migrés ou des routes manquantes dans votre configuration serveur.

• Vérifier l'absence de {useHash: true} dans RouterModule.forRoot()
• Configurer le fallback serveur vers index.html sur toutes les routes
• Tester le refresh navigateur sur plusieurs URL internes pour confirmer l'absence de 404
• Mettre à jour le sitemap XML avec les nouvelles URL sans dièse
• Implémenter des redirections 301 côté client pour les anciennes URL avec # si nécessaire
• Monitorer Google Search Console pour détecter les erreurs d'indexation post-migration