Faut-il vraiment utiliser des ancres (#) plutôt que des paramètres (?) pour tracker vos URLs ?

Pourquoi Google fait-il cette distinction entre ancres et paramètres ?

Le moteur traite les URLs de manière très différente selon qu'elles contiennent un fragment d'ancre (#) ou un paramètre de requête (?). Tout ce qui suit le dièse est ignoré par le crawler : Google considère exemple.com/page#tracking123 et exemple.com/page#tracking456 comme une seule et même URL.

À l'inverse, les paramètres génèrent des URLs distinctes. Résultat : exemple.com/page?utm_source=fb et exemple.com/page?utm_source=tw risquent d'être indexées séparément, fragmentant le signal de ranking et diluant l'autorité de la page.

Quel est le risque concret d'utiliser des paramètres pour tracker ?

Chaque variante d'URL peut être crawlée, indexée et évaluée indépendamment. Sur un site de 10 000 pages avec 5 variantes de tracking par page, vous exposez Googlebot à 50 000 URLs — un gaspillage massif de crawl budget.

Pire encore : Google peut interpréter ces variantes comme du contenu dupliqué. Même si vous utilisez des canoniques, vous forcez le moteur à un travail de consolidation qui n'aurait pas lieu d'être. Les ancres, elles, court-circuitent ce problème à la source.

Les ancres fonctionnent-elles vraiment pour tous les usages de tracking ?

Non. Et c'est là que la recommandation de Mueller montre ses limites. Les ancres sont invisibles côté serveur : elles ne sont jamais envoyées dans la requête HTTP. Si votre analytics ou votre système d'attribution repose sur du server-side tracking, les ancres ne remonteront rien.

Googlebot ne les voit pas, certes — mais vos outils non plus. Seuls les scripts JavaScript côté client peuvent les capturer, ce qui impose une dépendance forte au JS et complique les architectures de mesure avancées.

• Les ancres (#) sont ignorées par Google : elles n'influencent pas l'indexation ni le crawl.
• Les paramètres (?) créent des URLs distinctes susceptibles d'être indexées séparément et de fragmenter l'autorité.
• Le tracking par ancre est invisible côté serveur : il nécessite du JavaScript pour être exploitable.
• Un site utilisant massivement des paramètres de tracking peut gaspiller son crawl budget et générer du contenu dupliqué.
• Les canoniques ne sont pas une solution miracle : mieux vaut éviter la prolifération d'URLs dès la conception.

Cette recommandation est-elle cohérente avec ce qu'on observe sur le terrain ?

Oui, largement. Les audits montrent qu'un tracking agressif par paramètres pollue régulièrement l'index : pages duplicatas, URLs orphelines dans la Search Console, signaux de ranking dilués. Les sites qui migrent vers du tracking par ancre constatent souvent une réduction du crawl budget gaspillé et une meilleure consolidation des signaux.

Mais il faut nuancer : Google sait identifier certains paramètres courants (utm_*, fbclid, etc.) et les ignorer automatiquement. La Search Console permet même de déclarer des paramètres à ignorer. Donc si vous avez bien configuré votre compte GSC, le risque est atténué — sans être nul. [A verifier] : Google n'a jamais publié de liste exhaustive des paramètres ignorés par défaut, et les comportements varient selon les CMS et les configurations.

Dans quels cas cette règle ne s'applique-t-elle pas ou devient-elle contre-productive ?

Premier cas : les applications monopage (SPA) qui utilisent le fragment d'ancre pour gérer la navigation interne. Si vous utilisez déjà # pour router les vues, ajouter du tracking dans la même ancre peut créer des conflits ou rendre le code ingérable.

Deuxième cas : les architectures server-side où le tracking doit être traité avant la réponse HTTP (redirections conditionnelles, A/B testing côté serveur, attribution multi-touch). Les ancres ne remontent jamais au serveur — elles sont donc inutilisables pour ces usages. Résultat : vous êtes coincé avec des paramètres, et il faut alors gérer proprement la canonicalisation.

Quelles nuances faut-il apporter pour éviter les faux pas ?

Mueller dit que Google ignore tout après le #, mais attention aux SPAs et au JavaScript indexable. Si votre site charge du contenu dynamique via des ancres (type #article-123), Google peut tenter de rendre le JS et indexer ces variations — surtout si vous utilisez l'ancien schéma #! (hashbang). Dans ce cas, les ancres ne sont plus neutres.

Autre point : le tracking par ancre impose une dépendance totale au JavaScript côté client. Si votre stack analytics repose sur du tag management complexe, des conversions server-side ou des intégrations avec des CRM, vous perdez en flexibilité. Le conseil de Mueller est valide pour du tracking interne léger, pas pour des architectures de mesure avancées.

Que faut-il faire concrètement pour migrer vers du tracking par ancres ?

Première étape : identifier tous les paramètres de tracking actuels sur votre site. Logs serveur, Search Console (rapport Couverture et URLs indexées), crawl Screaming Frog avec filtres sur ?. Listez les paramètres internes (ref, source, campaign) et les paramètres tiers (fbclid, gclid, etc.).

Ensuite, modifiez vos générateurs de liens internes : CMS, templates, scripts de maillage automatique, boutons de partage. Remplacez ?tracking=xxx par #tracking=xxx. Assurez-vous que vos outils analytics (Google Analytics 4, Matomo, etc.) sont configurés pour capturer les fragments d'ancre via le dataLayer ou des événements JS personnalisés.

Quelles erreurs faut-il absolument éviter lors de cette transition ?

Ne supprimez pas brutalement les paramètres sans vérifier l'impact sur vos chaînes d'attribution marketing. Si vos campagnes Google Ads, Facebook ou emailing reposent sur des paramètres UTM classiques, vous risquez de casser tout le reporting. Testez en parallèle avant de basculer.

Autre piège : ne laissez pas coexister ancres et paramètres sur les mêmes URLs. exemple.com/page?utm_source=fb#tracking=123 cumule les inconvénients : Google voit la variante avec paramètre, et votre JS doit parser à la fois query string et fragment. Choisissez un système unique et tenez-vous-y.

Comment vérifier que l'implémentation est correcte et n'impacte pas l'indexation ?

Crawlez votre site avec un outil configuré pour ignorer les ancres (Screaming Frog, Oncrawl, Botify) : vous ne devez voir qu'une seule URL par page réelle. Parallèlement, vérifiez dans la Search Console que le nombre d'URLs indexées diminue ou reste stable — pas d'explosion de variantes.

Côté analytics, créez des rapports de validation comparant le volume de tracking avant/après. Si vous perdez plus de 5 % de données, c'est que la capture côté client dysfonctionne. Corrigez le code GTM ou le dataLayer avant de généraliser.

• Auditer les paramètres de tracking actuels (Search Console, logs, crawl)
• Configurer les outils analytics pour capturer les fragments d'ancre via JavaScript
• Modifier les générateurs de liens internes (CMS, templates, scripts)
• Tester en parallèle ancres et paramètres sur un échantillon avant migration globale
• Vérifier l'impact sur l'indexation via Search Console (nombre d'URLs indexées)
• Monitorer les données analytics pour détecter toute perte de tracking