Should you really use anchors (#) instead of parameters (?) to track your URLs?

Why does Google make a distinction between anchors and parameters?

The engine treats URLs very differently depending on whether they contain an anchor fragment (#) or a query parameter (?). Everything following the hash is ignored by the crawler: Google sees example.com/page#tracking123 and example.com/page#tracking456 as the same URL.

Conversely, parameters generate distinct URLs. As a result, example.com/page?utm_source=fb and example.com/page?utm_source=tw are likely to be indexed separately, fragmenting the ranking signal and diluting the page’s authority.

What is the concrete risk of using parameters for tracking?

Each URL variant can be crawled, indexed, and evaluated independently. On a site with 10,000 pages and 5 tracking variants per page, you expose Googlebot to 50,000 URLs — a massive waste of crawl budget.

Even worse: Google may interpret these variants as duplicate content. Even if you're using canonicals, you force the engine into a consolidation effort that wouldn't be necessary. Anchors, by contrast, circumvent this problem at the source.

Do anchors really work for all tracking uses?

No. And this is where Mueller's recommendation shows its limits. Anchors are invisible on the server side: they are never sent in the HTTP request. If your analytics or attribution system relies on server-side tracking, the anchors won't provide any data.

Googlebot doesn’t see them, certainly — but neither do your tools. Only client-side JavaScript scripts can capture them, which imposes a strong dependency on JS and complicates advanced measurement architectures.

• Anchors (#) are ignored by Google: they do not influence indexing or crawling.
• Parameters (?) create distinct URLs likely to be indexed separately and fragment authority.
• Anchor tracking is invisible on the server side: it requires JavaScript to be usable.
• A site heavily using tracking parameters can waste its crawl budget and generate duplicate content.
• Canonicals are not a miraculous solution: it's better to avoid the proliferation of URLs from the design stage.

Is this recommendation consistent with what we observe on the ground?

Yes, largely. Audits show that aggressive parameter tracking regularly pollutes the index: duplicate pages, orphaned URLs in Search Console, diluted ranking signals. Sites migrating to anchor tracking often see a reduction in wasted crawl budget and better consolidation of signals.

However, it needs nuance: Google can identify certain common parameters (utm_*, fbclid, etc.) and ignore them automatically. Search Console even allows you to declare parameters to be ignored. So if your GSC account is well configured, the risk is mitigated — though not eliminated. [To be checked]: Google has never published a comprehensive list of parameters ignored by default, and behaviors vary depending on CMS and configurations.

When does this rule not apply or become counterproductive?

First case: single-page applications (SPAs) that use the anchor fragment to manage internal navigation. If you are already using # to route views, adding tracking in the same anchor can create conflicts or make the code unmanageable.

Second case: server-side architectures where tracking needs to be processed before the HTTP response (conditional redirects, server-side A/B testing, multi-touch attribution). Anchors never reach the server — making them unusable for these purposes. As a result, you are stuck with parameters, and proper canonicalization must then be managed.

What nuances should be applied to avoid missteps?

Mueller says that Google ignores everything after the #, but please be cautious with SPAs and indexable JavaScript. If your site loads dynamic content via anchors (like #article-123), Google may attempt to render the JS and index these variations — especially if you use the old #! (hashbang) scheme. In this case, anchors are no longer neutral.

Another point: anchor tracking imposes a total dependency on client-side JavaScript. If your analytics stack relies on complex tag management, server-side conversions, or integrations with CRMs, you lose flexibility. Mueller's advice is valid for light internal tracking, not for advanced measurement architectures.

What should you do concretely to migrate to anchor tracking?

First step: identify all current tracking parameters on your site. Server logs, Search Console (Coverage report and indexed URLs), Screaming Frog crawl with filters on ?. List internal parameters (ref, source, campaign) and third-party parameters (fbclid, gclid, etc.).

Next, modify your internal link generators: CMS, templates, automatic linking scripts, share buttons. Replace ?tracking=xxx with #tracking=xxx. Ensure that your analytics tools (Google Analytics 4, Matomo, etc.) are configured to capture anchor fragments via the dataLayer or custom JS events.

What mistakes should be absolutely avoided during this transition?

Do not abruptly remove parameters without checking the impact on your marketing attribution chains. If your Google Ads, Facebook, or email campaigns rely on classic UTM parameters, you risk breaking all reporting. Test in parallel before switching.

Another trap: do not allow anchors and parameters to coexist on the same URLs. example.com/page?utm_source=fb#tracking=123 combines the disadvantages: Google sees the variant with the parameter, and your JS must parse both the query string and the fragment. Choose a single system and stick to it.

How to verify that the implementation is correct and does not impact indexing?

Crawl your site with a tool configured to ignore anchors (Screaming Frog, Oncrawl, Botify): you should see only one URL per actual page. Meanwhile, check in Search Console that the number of indexed URLs decreases or remains stable — no explosion of variants.

On the analytics side, create validation reports comparing the tracking volume before/after. If you lose more than 5% of data, it indicates that client-side capture is malfunctioning. Correct the GTM code or the dataLayer before generalizing.

• Audit current tracking parameters (Search Console, logs, crawl)
• Configure analytics tools to capture anchor fragments via JavaScript
• Modify internal link generators (CMS, templates, scripts)
• Test anchors and parameters in parallel on a sample before global migration
• Check the impact on indexing via Search Console (number of indexed URLs)
• Monitor analytics data to detect any loss of tracking