Pourquoi les URLs avec symbole dièse ne peuvent-elles pas servir de canoniques ?

Que signifie exactement cette restriction technique ?

Le symbole dièse dans une URL indique un fragment d'identification — une ancre interne à une page. Techniquement, tout ce qui suit le # n'est jamais envoyé au serveur lors d'une requête HTTP. C'est le navigateur qui gère ces fragments côté client.

Google traite donc example.com/page et example.com/page#section comme la même ressource serveur. Déclarer une canonical vers une URL avec fragment n'a donc aucun sens du point de vue de l'indexation : le bot ne peut pas distinguer deux versions différentes d'une même page uniquement via leurs fragments.

Pourquoi Google a-t-il ressenti le besoin de clarifier ce point ?

Cette précision intervient probablement parce que des sites utilisent massivement des Single Page Applications (SPA) avec routing côté client. Dans ces architectures, le # servait historiquement à simuler des URLs différentes sans rechargement de page.

Résultat : certains développeurs tentaient de créer des canoniques vers des URLs fragmentées, pensant segmenter leur indexation. Google ferme cette porte et formalise ce qui était déjà une pratique observée sur le terrain depuis des années.

Quelles sont les implications concrètes pour l'indexation ?

• Toute balise canonical pointant vers une URL avec # sera ignorée par Googlebot
• Les fragments ne permettent pas de différencier des versions canoniques distinctes
• Les SPAs doivent utiliser le HTML5 History API (pushState) pour générer des URLs crawlables sans fragments
• Les ancres internes restent parfaitement valides pour la navigation utilisateur et les featured snippets, mais ne structurent pas l'indexation

Cette règle contredit-elle des pratiques observées sur le terrain ?

Non, elle formalise simplement ce que tout SEO technique sait depuis le passage des SPAs au mode History. Les fragments ont toujours été ignorés dans le traitement des canoniques — Google ne fait que documenter explicitement un comportement existant.

Ce qui est intéressant, c'est le timing. Cette clarification arrive alors que certains frameworks JS continuent de générer des URLs fragmentées par défaut dans leurs configurations initiales. Google pousse clairement vers des architectures crawl-friendly natives.

Quelles nuances faut-il apporter à cette déclaration ?

Premier point : les fragments restent utilisés par Google dans des contextes spécifiques. Les Text Fragments (#:~:text=) permettent de lier vers des passages précis et apparaissent dans les SERPs. Mais ce ne sont pas des canoniques — juste des deeplinks enrichis.

Deuxième nuance : dans les résultats mobiles, Google affiche parfois des liens d'ancrage sous certains snippets pour sauter directement à une section. Ces fragments sont générés dynamiquement par Google et ne dépendent pas de votre déclaration de canonique.

Dans quels cas cette règle pose-t-elle un problème réel ?

Essentiellement pour les vieux sites en Angular 1.x ou Backbone.js qui utilisent encore le mode hashbang (#!/). Ces architectures sont obsolètes, mais certains sites legacy tournent encore avec. Pour eux, pas d'alternative : migration vers History API ou refonte complète.

Autre cas limite : les sites qui utilisent des fragments pour afficher des variantes de contenu côté client (ex : filtres, onglets, modales). Ces variantes ne seront jamais indexées séparément — il faut générer des URLs serveur distinctes si chaque variante mérite une indexation propre.

Que faut-il auditer en priorité sur son site ?

Première étape : vérifier que vos balises canonical ne contiennent aucun fragment. Un simple crawl avec Screaming Frog ou Oncrawl suffit. Filtrez les canoniques contenant le caractère # — si vous en trouvez, corrigez-les immédiatement.

Ensuite, inspectez votre architecture SPA si vous en avez une. Vérifiez que votre routing utilise bien l'HTML5 History API et non le mode hash. Dans React Router, Angular ou Vue Router, c'est un simple paramètre de configuration — mais encore faut-il l'avoir activé.

Quelles erreurs éviter absolument ?

• Ne jamais déclarer une canonical vers une URL avec fragment, même pour "regrouper" des variations
• Ne pas confondre fragments utilisateur (navigation interne) et fragments techniques (routing SPA) — les premiers sont OK, les seconds doivent disparaître
• Ne pas tenter de contourner cette limitation avec des redirections 301 incluant des fragments — elles seront ignorées également
• Éviter de générer des sitemaps XML contenant des URLs fragmentées — Google les crawlera mais ne les distinguera pas de la version sans fragment

Comment vérifier la conformité technique de son site ?

Utilisez la Search Console et inspectez vos pages indexées. Si Google remonte des URLs avec fragments comme canoniques déclarées, c'est un signal d'alarme. Vous verrez probablement des avertissements de type "Canonical mal formée" ou "URL canonique ignorée".

Côté développement, testez vos SPAs avec le Mobile-Friendly Test de Google. Cet outil rend le JavaScript et vous montre exactement quelles URLs Googlebot voit après exécution. Si des fragments persistent dans les URLs finales, votre routing n'est pas correct.