Pourquoi vos URLs avec hash (#) ne seront jamais indexées par Google ?

Les URLs avec hash sont-elles vraiment invisibles pour Googlebot ?

Oui, et c'est un principe fondamental du fonctionnement du web. Le hash (#) sert historiquement à la navigation intra-page côté client : le navigateur ne l'envoie jamais au serveur lors d'une requête HTTP. Googlebot, qui fonctionne comme un client HTTP classique, ne voit donc jamais ce qui suit le hash.

Concrètement, pour Google, example.com/match#live123 et example.com/match sont strictement identiques. Le moteur crawle l'URL sans le fragment, rend la page, mais ne peut pas distinguer les différents états d'une application JavaScript qui repose sur des hash pour créer des "routes" distinctes.

Pourquoi tant de sites utilisent-ils encore des hash pour router du contenu ?

Parce que c'est simple, rapide à implémenter, et que les frameworks JavaScript historiques (Angular.js en mode hashbang, React Router en mode hash) l'ont popularisé. Pas besoin de configuration serveur, pas de gestion des rewrites : tout se passe côté client.

Le problème ? Cette facilité technique se paie cash en visibilité SEO. Un site qui génère des milliers d'URLs avec hash pour des fiches produit, des articles ou des événements temporaires crée du contenu invisible pour les moteurs. C'est un angle mort complet.

Que se passe-t-il vraiment avec un contenu temporaire après l'événement ?

Martin Splitt précise un point crucial : retourner un 404 après l'événement est normal et acceptable. Google retire alors l'URL de l'index sans considérer cela comme une erreur ou un signal négatif. C'est cohérent avec la nature éphémère du contenu.

Cette approche est saine : elle évite d'accumuler des pages mortes dans l'index et clarifie l'intention. Un match du 15 mars n'a plus de raison d'être indexé le 20 mars. Le 404 est une réponse honnête, pas un défaut technique.

• Les URLs avec hash (#) ne sont jamais transmises au serveur donc Googlebot ne peut pas les crawler ni les indexer
• Pour du contenu temporaire indexable, il faut utiliser des routes propres sans hash (ex: /match/live-123)
• Un 404 après l'événement est une pratique saine : Google retire l'URL de l'index naturellement
• Les frameworks JavaScript modernes supportent le mode history (HTML5 pushState) qui génère des URLs propres
• Ne jamais confondre facilité de développement et compatibilité SEO : les hash sont un angle mort complet

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

Oui, totalement. C'est même l'un des rares points où Google est parfaitement clair et aligné avec la réalité technique du web. Les hash ne sont jamais envoyés dans les requêtes HTTP : c'est un standard W3C, pas une décision arbitraire de Google.

J'ai audité des centaines de sites en SPA (Single Page Application) et le pattern est toujours le même : les clients qui ont laissé des hash dans leurs routes génèrent du contenu invisible. Quand on bascule en mode history, l'indexation explose en quelques semaines. C'est reproductible, mesurable, systématique.

Quelles nuances faut-il apporter à cette affirmation ?

La seule nuance concerne les fragments de hash utilisés pour l'Ajax crawling (le système hashbang #! que Google avait proposé puis abandonné en 2015). Certains très vieux sites l'utilisent encore, mais c'est techniquement obsolète et Google ne le supporte plus officiellement.

Deuxième point : Google peut théoriquement exécuter du JavaScript qui manipule l'URL après le rendu initial. Mais dans la pratique, si votre contenu dépend d'un hash pour être affiché, la probabilité qu'il soit correctement indexé est proche de zéro. Ne comptez pas sur des heuristiques hypothétiques.

Dans quels cas cette règle pose-t-elle problème en production ?

Le cas classique : une appli React/Vue qui utilise le mode hash par défaut pour éviter de configurer le serveur. L'équipe dev livre rapidement, le contenu fonctionne parfaitement en navigation cliente, mais Google ne voit rien. Le SEO découvre le problème 3 mois après le launch.

Autre situation courante : les événements temporaires générés dynamiquement (webinaires, matchs, promos flash). Si l'équipe technique a pris le raccourci du hash pour ne pas toucher à l'infra backend, le contenu reste invisible. Résultat : zéro trafic organique pendant l'événement, exactement quand le pic de recherche est maximal.

Que faut-il faire concrètement pour rendre un contenu temporaire indexable ?

Première étape : auditer vos routes actuelles. Si vous utilisez un framework JavaScript, vérifiez le mode de routage configuré. React Router, Vue Router, Angular : tous proposent un mode history (HTML5 pushState) qui génère des URLs propres sans hash.

Ensuite, configurez votre serveur pour que toutes les routes retournent votre HTML principal (index.html ou équivalent). C'est le principe du fallback universel : Nginx, Apache, Netlify, Vercel ont tous des configs standard pour ça. Sans ce fallback, un refresh manuel sur /match/live-123 retourne un 404 serveur.

Comment gérer proprement la fin de vie d'un contenu temporaire ?

L'approche recommandée par Martin Splitt est simple : retournez un vrai 404 une fois l'événement terminé. Pas un soft 404, pas une redirection vers la homepage : un 404 HTTP franc.

Vous pouvez adoucir l'expérience utilisateur avec une page 404 personnalisée qui propose des événements similaires à venir, mais le code HTTP doit être 404. Google interprétera correctement le signal et retirera l'URL de l'index en quelques jours ou semaines, selon la fréquence de crawl de votre site.

Quelles erreurs éviter absolument dans ce contexte ?

Erreur numéro 1 : utiliser des hash pour du contenu que vous voulez indexer. C'est un angle mort complet, aucune heuristique ne viendra vous sauver. Ne comptez pas sur l'exécution JavaScript de Google pour contourner ce problème structurel.

Erreur numéro 2 : laisser des URLs de contenu temporaire retourner du 200 avec un message "événement terminé". C'est un soft 404, Google mettra plus de temps à désindexer, et vous polluez votre index avec des pages sans valeur. Le 404 est une réponse honnête et efficace.

• Vérifier le mode de routage de votre framework JavaScript (hash vs history)
• Configurer le fallback serveur pour que toutes les routes retournent l'HTML principal
• Tester la navigation directe (refresh manuel) sur une route profonde pour valider la config
• Retourner un 404 HTTP franc une fois le contenu temporaire expiré
• Monitorer la désindexation via Search Console pour valider que Google retire bien les URLs
• Documenter la logique de génération/expiration des URLs temporaires pour les équipes tech