Les URL avec hash (#) sont-elles vraiment ignorées par Google lors de l'indexation ?

Declaration officielle

Google n'indexe pas les URL avec des hashes séparément. Si le contenu que vous souhaitez indexer est chargé lorsque vous chargez l'URL sans le hash, alors c'est acceptable.

1:05

🎥 Vidéo source

Extrait d'une vidéo Google Search Central

⏱ 1h00 💬 EN 📅 01/05/2018 ✂ 12 déclarations

Voir sur YouTube (1:05) →

✂ Autres déclarations de cette vidéo 11 ▾

2:10 Faut-il vraiment un fallback statique pour les URLs générées en JavaScript ?
3:10 Googlebot attend-il vraiment le JavaScript avant d'indexer vos pages ?
5:50 Pourquoi vos nouvelles pages dansent-elles dans les SERPs pendant des semaines ?
13:08 Faut-il vraiment optimiser la longueur des méta-descriptions pour Google ?
16:45 Faut-il vraiment utiliser rel="next" et rel="prev" pour la pagination ?
21:30 Le contenu masqué derrière des onglets pénalise-t-il vraiment le SEO mobile ?
28:46 Faut-il vraiment inclure Googlebot dans vos tests A/B ou risquez-vous une pénalité SEO ?
29:22 Googlebot rate-t-il des pages entières à cause de la géolocalisation ?
33:34 Faut-il vraiment séparer contenu familial et non-familial par URL pour SafeSearch ?
35:05 Quelle métrique de vitesse Google privilégie-t-il vraiment pour le ranking ?
56:58 Les redirections 301 suffisent-elles vraiment à protéger votre visibilité après un changement d'URL ?

Ce qu'il faut comprendre

Que signifie concrètement 'Google n'indexe pas les URL avec hash séparément' ?

Dans la syntaxe des URL, le hash (ou ancre) représente tout ce qui suit le symbole # dans une adresse. Exemple : https://example.com/page#section1. Historiquement, ce fragment servait à la navigation interne côté client, sans impliquer de requête serveur.

Mueller affirme ici que Google ignore la partie hash lors de l'indexation. Autrement dit, example.com/page et example.com/page#section1 sont considérées comme une seule et même URL par le moteur. Cette règle découle du fonctionnement HTTP : le hash n'est jamais transmis au serveur, il reste côté navigateur.

Pourquoi cette précision de Mueller pose-t-elle question aux praticiens SEO ?

Beaucoup de sites modernes utilisent des frameworks JavaScript (React, Angular, Vue) qui s'appuient sur le hash pour gérer le routing côté client. Dans ces architectures, un changement de hash peut charger du contenu totalement différent sans rafraîchir la page.

Le problème : si ce contenu n'existe pas dans le HTML initial, Googlebot ne le verra peut-être jamais. Mueller le dit sans détour : le contenu doit être chargé avec l'URL sans hash. Si votre SPA charge une page produit uniquement via #produit-123, et que l'URL racine affiche un écran vide, vous avez un souci d'indexation.

Quelle différence avec le pushState et les URL modernes ?

Les développeurs avisés ont migré depuis longtemps vers l'API History (pushState), qui permet de changer l'URL visible sans hash et sans recharger la page. Cette approche génère de vraies URL distinctes, que Google indexe normalement.

La déclaration de Mueller sous-entend que si vous utilisez encore du hash routing en production, vous êtes technologiquement en retard. Le hash était un hack pratique avant HTML5, mais aujourd'hui il n'a plus sa place dans une architecture SEO-friendly moderne.

Google ignore complètement la partie après # lors de l'indexation
Le contenu à indexer doit être présent dans la réponse HTML initiale de l'URL sans hash
Le hash routing (navigation JavaScript basée sur #) crée des problèmes d'indexation structurels
Les frameworks modernes doivent utiliser l'API History plutôt que les hash URLs
Cette règle découle du protocole HTTP : le hash n'est jamais envoyé au serveur

Avis d'un expert SEO

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

Oui, et c'est même une des rares affirmations de Google où la théorie rejoint parfaitement la pratique. Tous les tests que j'ai menés ou observés dans la communauté SEO confirment ce comportement : Googlebot traite example.com/page#anchor exactement comme example.com/page.

La nuance importante : Google peut suivre les liens avec hash pour découvrir du contenu sur la même page, mais il n'indexera jamais ces variations comme des URLs distinctes. Si vous avez 50 produits chargés via des hash différents sur une seule page, Google verra une seule page avec un seul contenu : celui du chargement initial.

Où se cachent les pièges que Mueller ne mentionne pas ?

Mueller reste flou sur un point crucial : comment Google détermine-t-il que le contenu est 'chargé' ? Parle-t-on du HTML brut ou de ce que le moteur de rendu JavaScript détecte après exécution ? [A vérifier]

Dans mes observations, Google exécute bien JavaScript, mais avec des limitations temporelles et de ressources. Si votre contenu met 3 secondes à apparaître via JS après le chargement initial, il peut être indexé... ou pas. Cette incertitude crée une zone grise que Mueller balaye d'un revers de main.

Faut-il vraiment s'inquiéter du hash en SEO moderne ?

Franchement, si vous construisez un site neuf et que vous envisagez le hash routing, vous prenez la mauvaise décision. C'est une architecture obsolète pour le SEO. Point.

Cependant, beaucoup de sites legacy ont encore du hash routing en production. Pour ceux-là, la solution n'est pas cosmétique : il faut migrer vers du server-side rendering (SSR) ou au minimum du pre-rendering, avec des URLs propres. Tout autre approche est un pansement sur une jambe de bois.

Attention : Si vous utilisez des hash URLs pour du tracking (UTM parameters en #), sachez que Google les ignore complètement. Pour le tracking, utilisez des paramètres query string (?) ou des solutions côté serveur.

Impact pratique et recommandations

Comment auditer rapidement si votre site a un problème de hash ?

Ouvrez votre navigateur en mode incognito, désactivez JavaScript (dans DevTools : Cmd+Shift+P > 'Disable JavaScript'), puis naviguez sur votre site. Tout ce qui disparaît ou ne charge pas représente un risque d'indexation.

Vérifiez ensuite vos URLs dans la Search Console. Si vous voyez des variations avec # dans les rapports de couverture, c'est un signal d'alarme : soit vous avez des liens internes mal formés, soit votre architecture routing crée des URLs polluées.

Quelles actions correctives appliquer selon votre situation ?

Si vous êtes sur un site moderne (React, Vue, Angular), migrez immédiatement vers le React Router en mode browser ou équivalent, qui génère de vraies URLs. Configurez votre serveur pour renvoyer la bonne page HTML selon l'URL demandée, via SSR ou pre-rendering.

Pour les sites legacy impossibles à refondre rapidement, implémentez du dynamic rendering : servez du HTML pré-rendu à Googlebot tout en gardant votre SPA pour les utilisateurs humains. C'est acceptable selon Google, mais ce n'est qu'une solution temporaire.

Peut-on encore utiliser les ancres # pour la navigation interne ?

Absolument, et c'est même recommandé pour l'UX. Les ancres vers des sections de page (exemple : #section-tarifs) restent parfaitement valides. Google les comprend et peut même les afficher dans les résultats riches.

La différence : ces ancres pointent vers du contenu déjà présent dans le HTML, pas du contenu chargé dynamiquement. C'est l'usage historique et légitime du hash, celui pour lequel il a été conçu. Utilisez-les sans crainte pour la table des matières, les FAQ accordéons, ou les scrolls vers sections.

Auditez votre site JavaScript désactivé pour identifier le contenu invisible à Googlebot
Migrez du hash routing vers l'API History (pushState) dans vos frameworks JS
Implémentez du SSR ou pre-rendering pour servir du HTML complet à Googlebot
Nettoyez vos liens internes pour supprimer les hash URLs inutiles
Gardez les ancres # uniquement pour la navigation vers sections existantes dans le HTML
Vérifiez dans Search Console qu'aucune URL avec hash n'apparaît dans vos pages indexées

Ces optimisations techniques touchent au cœur de votre architecture front-end et demandent une expertise poussée en JavaScript moderne, rendu serveur et configuration serveur. Si votre équipe interne manque de compétences sur ces aspects critiques, faire appel à une agence SEO technique spécialisée peut vous éviter des erreurs coûteuses et accélérer significativement la mise en conformité de votre indexation.

❓ Questions frequentes

Google peut-il indexer du contenu qui n'apparaît que lorsqu'on clique sur un lien avec hash ?

Non. Google indexe l'URL sans tenir compte du hash, donc seul le contenu présent au chargement initial de cette URL sera pris en compte. Le contenu qui apparaît après interaction utilisateur sur une ancre hash ne sera pas indexé séparément.

Les paramètres UTM en hash (#utm_source=...) sont-ils trackés par Google Analytics mais ignorés par le SEO ?

Exact. Google Analytics côté client peut lire ces paramètres en JavaScript, mais Googlebot les ignore complètement pour l'indexation. Utilisez plutôt des paramètres query string (?) pour un tracking compatible SEO.

Quelle différence entre une URL avec hash et une URL avec paramètre query string pour Google ?

Fondamentale. Le hash (#) n'est jamais envoyé au serveur et est ignoré par Google pour l'indexation. Le query string (?) est transmis au serveur et Google peut indexer ces URLs comme distinctes, selon votre configuration de paramètres dans Search Console.

Si je migre de hash routing vers des vraies URLs, dois-je faire des redirections 301 ?

Techniquement impossible : vous ne pouvez pas rediriger côté serveur quelque chose qui n'est jamais envoyé au serveur. Implémentez plutôt une détection JavaScript côté client qui redirige les anciennes hash URLs vers les nouvelles URLs propres.

Les ancres de page (#section-2) nuisent-elles au SEO si utilisées dans les liens internes ?

Non, tant que le contenu de la section est présent dans le HTML initial. Ces ancres améliorent même l'UX et peuvent générer des sitelinks Google si bien structurées. C'est l'usage légitime du hash.

🎥 De la même vidéo 11

Autres enseignements SEO extraits de cette même vidéo Google Search Central · durée 1h00 · publiée le 01/05/2018

🎥 Voir la vidéo complète sur YouTube →