Why doesn't Google canonicalize URLs with fragments in sitelinks and rich results?

What is a URL fragment and how does Google typically handle it?

A URL fragment is the part after the hash symbol (#), traditionally used to create internal anchors within an HTML page. Example: example.com/page#section-2. Historically, Google ignores these fragments during indexing — the indexed page is example.com/page, period.

The engine considers the fragment to be a client-side navigation element, not a distinct resource. In standard SERPs, if multiple variants with different fragments point to the same page, Google automatically consolidates them. This is the canonicalization of fragments: only a single version appears, the one without #.

What happens in sitelinks and rich results?

Let’s be honest: this is where it gets tricky. In sitelinks (the secondary links that appear under certain results) and structured rich results like FAQs or HowTos, Google changes its behavior. The URL with its fragment is fully preserved and transmitted as is.

Specifically? If your FAQ markup points to example.com/help#question-3, it’s that exact URL that will be recorded in the performance report of Search Console. No merging, no canonicalization. Each variant becomes a distinct line in your data.

Why does this exception cause problems in practice?

This divergence complicates performance analysis. You end up with dozens of different lines in GSC for one single page, each showing a few scattered clicks. It's hard to measure the actual performance of your content when metrics are fragmented.

And it’s all the more treacherous since the behavior is context-dependent: same URL, different treatment depending on whether it appears in a standard result or a rich snippet. No apparent logic for the practitioner — just one more technical nuance to master.

• Fragments are ignored in standard search results (automatic canonicalization)
• Fragments are preserved in sitelinks and rich results (FAQ, HowTo, etc.)
• Search Console records each URL with fragment as a distinct entry in these contexts
• This difference in treatment complicates aggregated performance analysis of a page
• No impact on indexing itself, but on the granularity of reporting

Is this statement consistent with real-world observations?

Yes, and that’s precisely what’s frustrating. SEOs who meticulously mark up their structured FAQs with distinct anchors have been dealing with fragmented GSC data for a long time. This isn't new, but the official confirmation puts an end to hopes of Google correcting this behavior.

The problem is that this logic contradicts the very philosophy of canonicalization. If Google considers that fragments do not create unique content, why treat them as distinct URLs in some contexts? The likely answer: to preserve the UX of rich snippets, where a direct link to a specific section makes sense. But it's still shaky from an analytical perspective.

What gray areas remain in this statement?

Google does not specify all types of rich results involved. FAQs and HowTos are mentioned, but what about tables of contents, jump links in featured snippets, or anchors in the People Also Ask section? No exhaustive list. [To be checked] on a case-by-case basis on your own GSC data.

Another ambiguity: the impact on crawl budget. If Google keeps these fragmented URLs in its index of rich results, does it mean that it crawls them separately? Or are they simply extracted from the HTML rendering during the crawling of the parent page? The statement does not clarify this. For large sites, this is a question worth clarifying.

When does this rule really not apply?

Single Page Applications (SPA) that use fragments to manage client-side application states are out of scope. Google has long struggled with these architectures, and the recommendation remains to migrate to the History API to create true distinct URLs.

Similarly, fragments used for parameter tracking (example.com#utm_source=x) are never considered by Google, regardless of the display context. The engine simply ignores them — and that’s a good thing, otherwise chaos would reign in GSC.

What actions should you take in your markup strategy?

If you use structured FAQ data or HowTo, anticipate that each anchor will create a distinct line in Search Console. Adapt your naming accordingly: clear and consistent fragment IDs (example.com/guide#step-1, not example.com/guide#a1x9z) facilitate later analysis.

For sites generating hundreds of FAQs with anchors automatically, you will end up with an unmanageable GSC report. In this case, two options: either manually consolidate the data via the API, or forego the anchors in your structured tags and point to the entire page instead. Less precise for the user, but cleaner analytically.

How can you leverage this specificity to your advantage?

Let’s be pragmatic: this behavior offers you unprecedented measurement granularity. You can now pinpoint exactly which questions in your FAQ are driving clicks from rich results. It’s a goldmine for optimizing your content: keep the performing questions, rephrase or remove the others.

Create a dedicated dashboard that aggregates URLs by prefix (all variants example.com/page# grouped together). This requires some scripting — Google Sheets with regex or a tool like Looker Studio — but it's doable. You thus get a consolidated view while retaining detail when necessary.

What mistakes should you absolutely avoid in this configuration?

Never create duplicate content by making sections accessible via both example.com/page#section and example.com/page/section. You unnecessarily fragment your link equity and further complicate analysis. Choose one architecture and stick to it.

Avoid dynamically generated or random fragments. If your CMS produces IDs like #faq-3a7b9c on each rebuild, your GSC data becomes unusable. Impose stable and predictable anchors in your setup.

• Audit your current structured data to identify all fragments used in FAQs, HowTos, etc.
• Standardize the naming of anchors (#question-1, #step-2, etc.) for future analysis
• Set up a specific GSC report that aggregates URLs by root (excluding fragment)
• Ensure that your fragments point to actual existing and visible sections in the HTML
• Document for the dev team that anchor IDs must remain stable in production
• Test the effective appearance of your rich results with fragments using the rich results testing tool