Do URL fragments really disrupt the indexing of JavaScript sites?

Why does Google remove URL fragments during indexing?

URL fragments (the part after the #) were historically designed for client-side internal navigation, not for identifying distinct resources on the server side. The browser never sends them to the server during an HTTP request — only client-side JavaScript can read them.

Google decided to standardize this logic within its indexing system: when Googlebot encounters a URL with a fragment, it removes it before processing. As a result, https://example.com/page#section-A and https://example.com/page#section-B are treated as a single URL for Google's index. This rule applies to almost all current websites.

What is the exception for 'historical sites' mentioned by Mueller?

There is an archaic indexing mechanism called 'hash-bang' (#!), introduced by Google in 2009 and officially deprecated in 2015. A few very old sites — remnants from the pre-HTML5 web — still use this obsolete system. Google maintains minimal support for them, but it’s a fossil-like exception that practically no one benefits from anymore.

If your site was launched after 2015 and you wonder whether you are affected by this exception, the answer is no. Mueller's mention primarily serves to clarify that there is a minuscule minority of cases where fragments are still processed, but it should not create false hope.

Why do modern JavaScript frameworks create issues with this rule?

Many Single Page Applications (SPAs) built with React, Vue, or Angular use client-side routing based on fragments. When a user clicks on an internal link, the framework loads new content via JavaScript without reloading the page — often changing the URL by adding or modifying a fragment.

The catch: if your content is only rendered when the fragment is present, and Googlebot removes this fragment before indexing, then your content simply does not exist for Google. The bot sees an empty shell. This is precisely what Mueller points out: a technical setup that renders your content invisible by design.

• Googlebot removes fragments (#hash) before indexing — this is a nearly universal rule
• JavaScript sites that load content conditioned by a fragment create invisible content for Google
• The 'historical sites' exception is an outdated edge case (hash-bang pre-2015) that affects hardly anyone
• Modern SPAs must use the HTML5 History API (pushState/replaceState) for SEO-compatible routing
• If your URL contains a #, ask yourself whether the displayed content relies on this fragment — if yes, it's a red flag

Is this statement consistent with observed practices in the field?

Yes, absolutely. Technical audits on thousands of JavaScript sites confirm that fragments are a recurring blind spot. We often see SPAs with entire sections of content — FAQs, product descriptions, blog articles — rendered only when a specific fragment is present in the URL. Google sees nothing.

The confusion often arises from a misunderstanding between client navigation and server indexing. Developers test their site in a modern browser, see the content loading correctly, and think everything is fine. However, Googlebot operates differently: it removes the fragment before even starting the rendering. What the bot indexes is the initial state of the page without the fragment — often an empty shell.

What nuances should be added to this statement from Mueller?

The statement is accurate but lacks precision on a key point: the timing of when Google removes the fragment. Some practitioners believe that the bot runs the JavaScript first, sees the content load, and then normalizes the URL. This is false. [To be verified] Google removes the fragment before rendering, which means your JavaScript code never receives the fragment information when executed by Googlebot.

Another nuance: fragments can be useful for user experience (internal navigation anchors, scrolling to a section) as long as they do not condition the display of content. If your content is already present in the initial DOM and the fragment is just for scrolling, no problem. The trap is when the fragment triggers deferred loading or conditional rendering.

In what scenarios does this rule not apply or create unexpected issues?

An interesting edge case: PWAs (Progressive Web Apps) that use fragments to manage application state without reloading the page. If you build a complex PWA with multiple views, each view should ideally have its own clean URL (without fragment) to be indexable. But in practice, certain parts of the application may not need to be indexed — a private user dashboard, for example.

Where it really breaks down: sites that have migrated from an old hash-bang system to a modern SPA without changing their URL structure. They think they have solved the problem by switching to React or Vue, but continue to use fragments because “it has always worked this way.” Result: an invisible SEO regression for months. Technical migration is not enough if the URL architecture remains broken.

What concrete steps should be taken to avoid this indexing pitfall?

The first step: audit your JavaScript routing. Open your browser's DevTools, enable network throttling to simulate a slow bot, and check if your main content loads even without the fragment in the URL. If you load /page and entire sections are empty, you have a fragment dependency issue.

Next, migrate to the HTML5 History API (pushState/replaceState). All modern frameworks natively support it: React Router, Vue Router, Angular Router. Configure your routing to use ‘clean’ URLs without fragments. Instead of /page#section-A, use /page/section-A. The server must be configured to serve the same application on all these routes, then the JavaScript takes over on the client side.

How can you check that content is indeed indexable by Google?

Use the URL inspection tool in Search Console to test your critical pages. Compare the