Are URLs with a hash (#) truly ignored by Google during indexing?

What does it really mean when we say 'Google does not index URLs with hashes separately'?

In URL syntax, the hash (or anchor) represents everything that follows the # symbol in a address. For example: https://example.com/page#section1. Historically, this fragment served for internal client-side navigation, without involving a server request.

Mueller states here that Google ignores the hash part during indexing. In other words, example.com/page and example.com/page#section1 are considered to be the same URL by the engine. This rule comes from how HTTP works: the hash is never sent to the server; it remains on the client side.

Why does Mueller's clarification raise questions among SEO practitioners?

Many modern sites use JavaScript frameworks (React, Angular, Vue) that rely on the hash for client-side routing. In these architectures, a hash change can load completely different content without refreshing the page.

The problem is: if this content does not exist in the initial HTML, Googlebot may never see it. Mueller bluntly states: content must be loaded with the URL without the hash. If your SPA loads a product page solely via #product-123, and the root URL displays a blank screen, you're facing an indexing issue.

What distinguishes this from pushState and modern URLs?

Smart developers have long migrated to the History API (pushState), which allows changing the visible URL without a hash and without reloading the page. This approach generates real distinct URLs, which Google normally indexes.

Mueller's statement implies that if you're still using hash routing in production, you're technologically behind. The hash was a practical hack before HTML5, but today it has no place in a modern SEO-friendly architecture.

• Google completely ignores the part after # during indexing
• The content to be indexed must be present in the initial HTML response of the URL without the hash
• Hash routing (JavaScript navigation based on #) creates structural indexing issues
• Modern frameworks should use the History API instead of hash URLs
• This rule stems from the HTTP protocol: the hash is never sent to the server

Is this position consistent with real-world observations?

Yes, and it is one of the few assertions by Google where theory perfectly aligns with practice. All the tests I've conducted or witnessed within the SEO community confirm this behavior: Googlebot treats example.com/page#anchor exactly as example.com/page.

The important nuance is: Google can follow hash links to discover content on the same page, but it will never index these variations as distinct URLs. If you have 50 products loaded via different hashes on a single page, Google will see just one page with one set of content: that of the initial load.

Where are the pitfalls that Mueller doesn't mention?

Mueller is vague on a crucial point: how does Google determine that content is 'loaded'? Are we talking about raw HTML or what the JavaScript rendering engine detects after execution? [To be verified]

In my observations, Google does execute JavaScript, but with time and resource limitations. If your content takes 3 seconds to appear via JS after the initial load, it might be indexed... or not. This uncertainty creates a gray area that Mueller brushes aside.

Should we really worry about hash in modern SEO?

Honestly, if you're building a new site and considering hash routing, you're making the wrong decision. It is an outdated architecture for SEO. Period.

However, many legacy sites still have hash routing in production. For these, the solution is not cosmetic; you need to migrate to server-side rendering (SSR) or at minimum pre-rendering, with clean URLs. Any other approach is just a band-aid on a wooden leg.

How can you quickly audit if your site has a hash problem?

Open your browser in incognito mode, disable JavaScript (in DevTools: Cmd+Shift+P > 'Disable JavaScript'), and then navigate your site. Anything that disappears or fails to load presents an indexing risk.

Next, check your URLs in the Search Console. If you see variations with # in the coverage reports, it's an alarm signal: either you have poorly formed internal links, or your routing architecture creates polluted URLs.

What corrective actions should you take based on your situation?

If you're on a modern site (React, Vue, Angular), immediately migrate to React Router in browser mode or its equivalent, which generates real URLs. Configure your server to return the correct HTML page based on the requested URL, via SSR or pre-rendering.

For legacy sites that cannot be quickly revamped, implement dynamic rendering: serve pre-rendered HTML to Googlebot while keeping your SPA for human users. Google accepts this, but it is only a temporary solution.

Can we still use anchors # for internal navigation?

Absolutely, and it's even recommended for UX. The anchors to sections of a page (for example: #pricing-section) remain perfectly valid. Google understands them and can even display them in rich results.

The difference is: these anchors point to content already present in the HTML, not content loaded dynamically. This is the historical and legitimate use of the hash, for which it was designed. Use them freely for tables of contents, accordion FAQs, or scrolls to sections.

• Audit your site with JavaScript disabled to identify content invisible to Googlebot
• Migrate from hash routing to the History API (pushState) in your JS frameworks
• Implement SSR or pre-rendering to serve complete HTML to Googlebot
• Clean your internal links to remove unnecessary hash URLs
• Keep the anchors # only for navigation to sections that exist in the HTML
• Check in Search Console that no URL with a hash appears in your indexed pages