Indexation des fragments d'URL

Indexation des fragments d’URL est surtout un problème hérité, mais on la retrouve encore chaque mois dans les audits des applications monopage (SPA). Si le contenu important n’apparaît qu’à /page#state ou /page#!/view, Google le considère généralement comme la même URL que /page, et non comme un document distinct.

L’impact pour l’activité est simple. Les URL masquées ne se positionnent pas. Les états produit, les articles d’aide, les vues de catégories filtrées et les routes de l’application peuvent disparaître des résultats de recherche, même si les utilisateurs y accèdent parfaitement depuis le navigateur.

Ce que Google fait réellement des fragments

Pour l’indexation “classique”, les moteurs de recherche suppriment le fragment. Google a abandonné l’ancien schéma d’exploration AJAX depuis des années, ce qui a fait disparaître l’ancien contournement #!. En pratique, Googlebot demande l’URL de base, et non pas chaque variante de hash empilée dessus.

Cela signifie que example.com/docs#setup n’est pas une deuxième page. C’est le plus souvent example.com/docs avec un saut à l’intérieur de la page. Si votre routeur React ou Vue dépend encore d’états basés sur le hash pour du contenu unique, vous avez un problème d’indexation, pas une simple particularité technique.

Un point de vigilance honnête : les fragments sont très bien pour les ancres, les onglets et les liens de saut sur une page déjà indexable. Le problème commence quand les équipes attendent qu’ils créent des entrées de recherche autonomes.

Où cela casse la performance SEO

• SPAs avec routage par hash : des routes comme /#/pricing ou /#!/features se retrouvent souvent regroupées en une seule URL explorable.
• Navigation à facettes : les filtres chargés uniquement via des fragments ne peuvent pas obtenir des positions sur les combinaisons longue traîne.
• Centres de documentation : les états d’articles rendus derrière des fragments échouent souvent à être indexés individuellement.
• Confusion autour de l’équité des liens : les backlinks vers des variantes de fragments créent rarement des signaux de classement distincts pour ces états.

Dans Screaming Frog, cela se manifeste généralement comme une seule URL HTML avec énormément de changements d’état JavaScript, mais sans chemins de crawl distincts. Dans Google Search Console, vous voyez des impressions concentrées sur l’URL de base, tandis que les vues “enfant” supposées ne reçoivent rien. Ensuite, Ahrefs et Semrush indiquent moins d’URLs qui se positionnent que ce que l’équipe produit pense exister.

Que faire à la place

1. Déplacer les états importants vers de vraies URL via un routage basé sur le chemin (path-based) ou des paramètres de requête (query parameters).
2. Rendre le contenu indexable côté serveur, ou le pré-rendre avec des frameworks comme Next.js, Nuxt ou Astro.
3. Définir des canonicals sur les nouvelles URL, pas sur les versions par fragments.
4. Mettre à jour les liens internes, les sitemaps XML et la navigation pour permettre à Google de découvrir les nouveaux chemins.
5. Valider avec l’inspection d’URL dans GSC, des crawls rendus dans Screaming Frog, et les fichiers de logs si vous en disposez.

S’il s’agit d’une migration, associez autant que possible les anciennes destinations utilisateurs basées sur des fragments à des URL équivalentes explorables. Stricto sensu, vous ne pouvez pas faire un 301 d’un fragment, car le fragment est géré côté client et n’est pas envoyé dans la requête HTTP. C’est le point que beaucoup de glossaires omettent. Vous avez besoin d’une gestion JavaScript, de mises à jour des liens internes et d’une récupération des liens externes dans Ahrefs ou Moz, et pas d’une simple règle de redirection côté serveur.

En résumé : les fragments servent à la position dans une page, pas à créer des documents indexables. Si la page compte pour le trafic organique, donnez-lui une vraie URL.