Why does Google discourage the use of URL fragments (#) for mobile indexing?

What is a URL fragment and why is it problematic?

A URL fragment is the part after the hash symbol (#) in a web address, such as example.com/page#section2. Historically, browsers have used these fragments to navigate to anchors on the page without triggering a new HTTP request.

The issue? Googlebot traditionally ignores everything after the # because it sees it as a client-side instruction, not a separate resource. If your mobile site loads dynamic content via fragments (a popular technique in single-page applications from 2010 to 2015), Google likely doesn't see that content.

Why is this recommendation specifically for mobile?

With the widespread mobile-first indexing, Google crawls and indexes the mobile version of your site first. If that version relies on fragments to display content, you create a blind spot in the index.

Older JavaScript frameworks (like Angular.js with its # routing, some poorly configured React implementations) have heavily employed this approach. On desktop, these sites could manage with workarounds (escaped fragments, prerendering). In mobile-first indexing, these crutches are no longer sufficient: Google wants clean URLs, period.

What does “clear and accessible URLs” mean in practice?

Google refers to standard canonical URLs: example.com/products/shoes rather than example.com/#/products/shoes. Each indexable resource must have its own HTTP URL, directly accessible via GET, without requiring client-side JavaScript to reveal the content.

This also means that your server must respond with a 200 on these URLs, not a 404 that then redirects via JS. The initial served HTML must contain the main content or at least a sufficient skeleton for Googlebot to understand the page even before executing JavaScript.

• Avoid fragments (#) for routing distinct content — every indexable page should have its own URL
• Favor the History API (pushState) for modern single-page applications, which allows clean URLs without reloading
• Check mobile rendering in Search Console to confirm that Googlebot can see your main content
• Test your URLs in private browsing with JavaScript disabled: if you see nothing, Google likely sees nothing either
• Set up SSR or SSG prerendering if your stack demands compromises (Next.js, Nuxt, Gatsby to avoid this issue from the start)

Is this directive consistent with what is observed in practice?

Yes, and it's even a recurring problem in audits. Sites that have migrated to JS frameworks without reviewing their URL architecture end up with ghost pages: they exist for users but not for Google. I've seen e-commerce sites lose 40% of their organic traffic after a poorly calibrated React overhaul, precisely because of this kind of mistake.

What's interesting is that Google no longer talks about escaped fragments (the #!/ hack from 2012-2015). This technique is dead and buried. If you still have it in your legacy code, now is the time to refactor [To verify] if you haven't already seen a decline in rankings.

In which cases does this rule not really apply?

Traditional internal navigation anchors pose no issue: example.com/seo-guide#chapter-3 works perfectly. Google indexes the base URL and ignores the fragment for indexing, but the user lands at the right spot. This is the intended use of fragments, and it works.

Second exception: tracking or UI parameters (modals, tabs, light filters) passed in fragments. Example: example.com/products#color-filter-red. As long as the main content exists in the initial DOM and the fragment only changes the display, Google doesn’t care. The risk arises when the fragment loads distinct content that doesn’t exist elsewhere.

What nuances should be added to this recommendation?

John Mueller remains vague on one point: what about JavaScript rendering and crawl budgets? Google claims it executes JS, but we know that this rendering is costly and not systematic. A site that forces Google to execute JS to reveal URLs hidden behind fragments is wasting its crawl budget.

Another nuance: this recommendation mostly targets high page volume sites. If you have 10 static pages with a few anchors, no one is going to penalize you. But for a site with 10,000 product entries routed with #, it’s sure to be a disaster.

What should you check first on your mobile site?

First step: audit your URLs in mobile navigation. Open your site on mobile, navigate, and observe the address bar. If you see # changing with every click without the base URL moving, you have a problem. Supplement this with a crawl using Screaming Frog or Oncrawl in mobile user-agent to list all actually accessible URLs.

Second check: Search Console, Coverage tab. Look at the pages marked “Detected, currently not indexed.” If you see URL patterns that should be indexed but are not, cross-reference with your fragment list. Also, use the URL inspection tool to test the mobile rendering of suspicious pages.

How to correct an architecture relying on fragments?

The technical solution depends on your stack. For modern single-page applications, switch to the History API (pushState/replaceState), which allows clean URLs without fragments. Frameworks like React Router, Vue Router, Angular (recent versions) support this natively. Set them up in “history” mode rather than “hash.”

For legacy sites or complex stacks, consider server-side rendering (SSR) or static site generation (SSG). Next.js, Nuxt, Gatsby resolve this issue at the source by generating complete HTML pages with canonical URLs. This requires a refactor, but it’s an opportunity to modernize your entire architecture.

What mistakes should be avoided during migration?

A classic error: forgetting 301 redirects. If your old URLs with fragments were referenced (backlinks, social shares), you must properly redirect. The problem is that you cannot redirect a fragment server-side (it’s never sent to the server). Solution: client-side JavaScript that detects old patterns and redirects to the new clean URLs.

Another pitfall: breaking the crawl budget by duplicating everything. If you keep both old fragmented URLs AND new clean URLs accessible, you create massive duplicate content. Choose a single canonical structure and enforce it everywhere (rel=canonical, redirects, consistent internal links).

• Crawl your mobile site and list all URLs containing # that serve distinct content
• Configure your JS framework in “history” mode to generate clean URLs without fragments
• Implement JavaScript redirects for old fragments if necessary (and document this technical debt)
• Update all internal links and the XML sitemap to point to the new canonical URLs
• Check mobile rendering in Search Console after migration and monitor 404 errors for at least 3 months
• Test in real conditions: private browsing, JS disabled, slow 3G connection — if it works, Google will see your content