Do hash fragments (#) in URLs really prevent Google from indexing them?

What exactly are hash fragments and why does Google ignore them?

Hash fragments (also known as hash fragments or anchors) are the part of a URL that follows the # symbol. Historically, they were used to point to a specific section of an HTML page through anchors. Their technical peculiarity: they are never sent to the server during an HTTP request.

This characteristic explains why Google does not consider them for indexing. When Googlebot requests example.com/page#section, the server only receives example.com/page. The fragment remains client-side, processed only by the browser. To Google, example.com/page#section1 and example.com/page#section2 refer to the same URL: example.com/page.

Why have JavaScript applications widely adopted this approach?

JavaScript frameworks like Angular, React, or Vue have long used hash routing by default. This method allows for changing the visible state of the application without reloading the page or querying the server. It's simple to implement and does not require any specific server configuration.

The issue arises when these applications generate distinct content for each fragment. An online store with shop.com/#/product/123 and shop.com/#/product/456 displays two different products, but Google will only index one URL: shop.com/. The unique content of each product remains invisible to search engines.

What is the difference with the HTML5 History API recommended by Google?

The HTML5 History API (pushState and replaceState methods) changes the URL shown in the address bar without reloading the page, but this time without using a hash fragment. The application can transform shop.com/#/product/123 into shop.com/product/123, a real URL that the server can receive and process.

This approach requires a proper server configuration. All application routes must redirect to the JavaScript entry point (usually index.html) for the application to take over client-side. It's technically more complex, but it's the only way to make the content crawlable and indexable correctly.

• Fragments (#) are never transmitted to the server, thus invisible to traditional crawlers
• A URL with a fragment = one single page in Google's eyes, regardless of the content displayed client-side
• The HTML5 History API generates real distinct URLs that Google can crawl and index separately
• Transitioning to History requires server configuration to manage the fallback to the application
• Modern applications overwhelmingly favor History, with hash routing becoming obsolete

Does this statement really reflect Google's observed behavior?

Mueller's stance is consistent with fifteen years of field observations. Google has always treated fragments as client-side markers, not as distinct URL segments. Empirical tests confirm this: creating unique content behind hashes without a prerendering system leads to a consistent lack of indexing of that content.

Important nuance: Mueller says "generally." In some very specific cases, Google can execute JavaScript and find that the content changes depending on the fragment. But this capability remains limited and unpredictable. Relying on it is a gamble, not a serious SEO strategy.

Which applications really risk losing visibility?

Old Single Page Applications (SPA) using hash routing are the first affected. Sites built with Angular 1.x or early versions of Backbone.js have massively adopted this approach. If these sites have not transitioned to History or implemented a prerendering system, they potentially lose 90% of their indexable content.

Blogs using client-side filtering systems with hashes (blog.com/#category/seo) face the same issue. Google indexes the homepage, ignores the categories. [To be verified]: some report that Google is beginning to better manage these cases in Search Console, but no official confirmation or quantitative data available.

Does the History API really solve all indexing issues?

History significantly improves the situation but does not automatically guarantee perfect indexing. Google still needs to execute JavaScript to see the final content, which introduces latency and consumes crawl budget. Sites with thousands of dynamic pages may still encounter difficulties.

The most reliable solution remains Server-Side Rendering (SSR) or static prerendering. Next.js, Nuxt.js, and prerendering solutions like Prerender.io send complete HTML to Googlebot, eliminating any dependency on JavaScript execution. This is technically heavier, but infinitely more reliable for ensuring indexing.

Another seldom mentioned point: even with History, poorly architected applications can generate content duplication issues if the server does not return the correct HTTP status codes. A nonexistent page should return a 404, not a 200 with a client-side error message.

How can I diagnose if my site suffers from this fragment issue?

First instinct: open your site and navigate. If the URL in the address bar contains # symbols followed by paths (/#/products, /#page/about), you are affected. Don’t panic if you see simple anchors (#contact) for internal scrolling, that’s not the concern here.

Second step: query Google with site:yourdomain.com in the search. Compare the number of indexed pages to the actual number of unique content pages your site generates. A significant gap (50 pages indexed while you have 500) suggests a structural indexing problem, potentially related to fragments or JavaScript execution.

What technical solution should I concretely adopt?

Transitioning to the History API requires two parallel efforts. On the JavaScript side, replace hash routing with History routing in your framework. Angular provides PathLocationStrategy, React Router uses BrowserRouter instead of HashRouter, Vue Router accepts history mode.

On the server side, configure a universal fallback. All application URLs should return the main HTML file for the JavaScript to take over. With Apache, use a .htaccess file with RewriteRule. Nginx requires a try_files directive in the configuration. Be careful: this configuration can hide real 404s if implemented poorly.

Should I consider more robust solutions than just History?

If your site heavily depends on organic traffic, History alone remains a fragile compromise. Dynamic prerendering detects crawler user agents and serves them static HTML while real users get the JavaScript application. Cloudflare Workers, Prerender.io, or Rendertron offer this capability.

SSR (Server-Side Rendering) represents the most sustainable solution. Next.js for React, Nuxt.js for Vue, or Angular Universal turn your SPA into a hybrid application generating server-side HTML. It's a heavy technical investment but eliminates 90% of the indexing problems related to JavaScript.

• Audit all URLs on your site to identify the use of hash fragments for navigation
• Check in Google Search Console the gap between discovered URLs and indexed URLs
• Test the "URL Inspection" tool on your pages with fragments to see what Google actually renders
• Migrate routing to the History API if you are still using hash routing
• Configure the server to redirect all routes to the application entry point
• Implement a prerendering or SSR system if crawl budget is critical for your business