Sites still serving #! (hashbang) URLs are relying on a convention Google formally stopped supporting in 2015. The immediate consequence is straightforward: Google no longer sends the special _escaped_fragment_ requests that made the old AJAX crawling scheme work, which means any content that only exists behind a hash fragment on one of these legacy URLs is effectively invisible to modern Googlebot. The longer-tail consequences are messier and show up in ways that are easy to misdiagnose years later: orphaned hashbang URLs still sitting in the index, canonical confusion between old fragment-based URLs and whatever clean-URL structure eventually replaced them, and permanently lost link equity where the migration to real URLs happened but the 301 redirects from the old hashbang paths were never actually implemented.
Why hashbang URLs still cause indexing problems today
The AJAX crawling scheme, which Google introduced around 2009 and deprecated in 2015, was a workaround for a genuine technical limitation of that era: crawlers couldn’t execute JavaScript at scale, so single-page applications using hash-based routing (example.com/#!/product/123) were otherwise unreadable. The scheme asked site owners to detect the _escaped_fragment_ parameter, then serve a pre-rendered HTML snapshot of the equivalent state. When Google deprecated this in favor of directly rendering JavaScript through what’s now the Web Rendering Service, that entire request-and-snapshot handshake stopped happening. Googlebot doesn’t ask for _escaped_fragment_ versions anymore, and it doesn’t treat the fragment portion of a URL (anything after #) as a distinct crawlable path at all, because fragments are a browser-side convention, not a server-side one. A URL like example.com/#!/product/123 and example.com/ are, from a crawling and indexing standpoint, the same URL.
That’s the root of the problem for sites that never migrated off hashbang routing. Any unique “page” that only existed as a fragment state is not a unique indexable entity anymore. If the site is still actively serving hashbang URLs as its primary structure, none of that content can be discovered or indexed on a per-page basis today, no matter how good the content is.
For sites that did migrate to real URLs at some point, the residual problem is different and often worse from a diagnostic standpoint, because it looks like it should be fine. Old hashbang URLs frequently remain indexed as artifacts from when the AJAX crawling scheme was still active and Google had crawled and stored escaped-fragment snapshots. Those index entries don’t disappear automatically just because the site moved on. If those legacy URLs were never 301-redirected to their real-URL equivalents, you end up with two separate problems running simultaneously: stale, un-updatable content sitting in the index under URLs nobody maintains anymore, and a permanent loss of whatever links, mentions, or historical ranking signals had accumulated on those old paths, because a fragment-based URL can’t pass link equity forward without an explicit redirect target that Google can process. Since fragments aren’t sent to the server, a “redirect” can’t even be implemented server-side for a pure hashbang path; the fix has to happen at the point where old inbound links resolve, typically by having the server recognize the pattern in the full URL before the fragment (where feasible) or by ensuring canonical, indexable equivalents exist and are the versions being linked to going forward.
There’s also a subtler indexing consequence worth naming directly: canonical ambiguity. If a site partially migrated, say the URL structure changed for new content but old hashbang URLs are still technically reachable and unblocked, Google may have conflicting signals about which version represents the “real” page. This shows up as split signals in Search Console, inconsistent indexing status for what should be the same logical page, or the newer clean URL failing to fully inherit the authority the content had accumulated under its old identity.
How to migrate off hashbang URLs correctly
The correct migration path has three non-negotiable components, and skipping any one of them leaves part of the problem unsolved.
First, every distinct piece of content needs a real, unique URL that returns full content on a direct server request, not a URL that depends on client-side JavaScript reading a hash fragment to decide what to display. This means moving from hash-based routing to the History API (pushState/replaceState) so that navigating within the app changes an actual path segment (example.com/product/123), not a fragment. A URL fragment is never sent to the server as part of the HTTP request, so no server-side logic, redirect, or rendering decision can ever be based on it; that’s a hard technical ceiling, not a configuration choice.
Second, that real URL needs to independently return the actual content, either through server-side rendering, static generation, or hybrid rendering that provides the meaningful markup at request time rather than relying entirely on client-side JavaScript to construct it after the fact. This matters independent of the hashbang issue, but it’s the natural point to address it during a routing migration, since the whole reason hashbang existed was to work around client-only rendering.
Third, and this is the step most commonly skipped or done incompletely: implement server-side 301 redirects from every legacy hashbang URL pattern to its corresponding new clean URL. Because the fragment itself isn’t visible to the server, this typically means redirecting the base path (everything before the #) to a landing experience that can, via client-side JavaScript on load, parse the old fragment value and route the user (and ideally emit the correct canonical new URL) to the specific equivalent piece of content. It’s not elegant, but it’s the only mechanism available given that fragments never reach the server. Where old hashbang URLs are known and enumerable (from server logs, an XML sitemap history, or Search Console’s indexed-URL data), building an explicit mapping table from old fragment values to new paths is far more reliable than a generic pattern-based redirect, especially at any meaningful content scale.
After the migration, monitor the transition in Search Console’s Page Indexing report, watching specifically for old hashbang URLs to drop out of the index over time as Google recrawls the redirect and for the new clean URLs to pick up indexing status and, gradually, the ranking signals the content previously held. This isn’t instantaneous; recrawling and reprocessing legacy URLs takes time proportional to how frequently Google was already visiting them, and there’s no fixed, published timeline for how long full signal consolidation takes.
Hypothetically, imagine an e-commerce single-page app, call it “Example Shop,” that migrated off hash-based routing back in 2016, moving from example.com/#!/product/123 to example.com/product/123, but the developer at the time never implemented server-side redirects for the old hashbang paths, assuming the migration itself was enough. Years later, in this hypothetical, old hashbang URLs from 2015-era backlinks and directory listings would still resolve to the homepage rather than the intended product page, meaning any link equity those old links carried would have nowhere to go. Building an explicit mapping table today, old fragment value to new product path, sourced from server logs and historical sitemap data, would be the only realistic way to recover that stranded equity at this point.
