Are URLs with fragments (#) really invisible to Google?

Why does Google ignore fragments in URLs?

The # character in a URL is traditionally a client-side marker that indicates to the browser an anchor point on the page. Historically, this fragment is never transmitted to the server during an HTTP request. Google has always viewed variations of the same URL separated only by a fragment as one single resource.

This approach poses a major problem for Single Page Applications (SPAs) that utilize modern JavaScript frameworks. These applications often load dynamic content by only modifying the fragment, thereby creating “pseudo-pages” that users perceive as distinct but which Google sees as identical.

What distinguishes a classic anchor from Ajax content?

A classic anchor (page.html#section2) serves to scroll to a visible part of an already loaded page. The content already exists in the source HTML. Google can index it without issue since everything is present from the initial load.

With dynamically loaded Ajax content, the fragment triggers an asynchronous JavaScript request that fetches and displays new content. This content does not exist in the initial HTML that Googlebot crawls. Even if Googlebot executes JavaScript, it does not understand that #product1 and #product2 are supposed to display different contents if they rely solely on the fragment.

What are the recommended technical alternatives?

The modern solution is to use the History API pushState/replaceState. This HTML5 API allows you to modify the full URL in the address bar without reloading the page, while maintaining the smooth experience of a SPA. Google treats these URLs as distinct and crawlable pages.

The other option, now outdated but mentioned by Mueller, is the Ajax crawling scheme with the fragment #! (hashbang). Google has officially deprecated this method, but it remains technically functional. It requires the server to serve a static HTML version of each application state via an _escaped_fragment_ parameter.

• Simple fragments (#): ignored by Google, no separate indexing
• Clean URLs with pushState: recommended modern solution, normal crawling and indexing
• Hashbang scheme (#!): outdated but functional, complex to maintain
• Server-side rendering (SSR): ensures content exists in the initial HTML
• Prerendering: generates HTML snapshots for crawlers

Does this statement align with observed practices in the field?

Absolutely. Empirical tests confirm that Google systematically normalizes URLs by removing the fragment before processing them. If you submit example.com/page#section1 and example.com/page#section2 in the Search Console, Google treats them as the same canonical URL: example.com/page.

Server log crawls show that Googlebot never transmits the fragment in its HTTP requests. This is technically impossible since the fragment is managed only by the browser. Poorly configured SPAs regularly face indexing issues for exactly this reason, with entire sections of content invisible to Google.

What nuances should be added to this rule?

Mueller refers to URLs “containing only the # character,” which leaves a grey area. In reality, Google completely ignores everything that follows the #, regardless of its length or complexity. The phrase “containing only” can be misleading: even #very-long-complex-fragment is ignored.

The statement does not clarify the behavior for anchors pointing to dynamically injected elements. If JavaScript loads content and then adds IDs to elements, Google could theoretically scroll to these anchors during JavaScript rendering. [To be verified] in real-world conditions since the timing of JavaScript execution may vary.

In what cases does this limitation pose critical issues?

E-commerce SPAs managing product filters via fragments are particularly vulnerable. If each filter combination generates a URL like /products#color=red&size=M, Google only sees one page /products with a single set of products. The rest of the catalog becomes orphaned from an SEO perspective.

Dashboards and administration interfaces often use fragments for navigation between tabs. This is not problematic if this content does not need to be indexed. However, watch out for technical documentation sites or client portals that mix public and private content: content accessible only via fragments remains invisible in the SERPs.

What concrete steps should be taken to resolve this issue?

Start with a comprehensive technical audit to identify all URLs containing fragments on your site. Use tools like Screaming Frog in JavaScript mode, or analyze analytics logs to spot user navigation patterns that do not match any URLs crawled by Google.

If you manage a SPA, implement the History pushState API to replace fragment navigation. This change usually requires adjustments in your JavaScript framework (React Router, Vue Router, Angular Router all natively support pushState). Ensure your server is configured to return the correct HTML page regardless of the requested URL, possibly falling back to index.html.

How can you verify that Google is correctly crawling your dynamic content?

Use the URL inspection tool in the Search Console to test the rendering of your critical pages. Compare the crawled version with what your users see. If content is missing in the crawled version, your JavaScript implementation is likely causing an issue.

Monitor the index coverage reports after any architecture modification. A sudden drop in the number of indexed pages may indicate that Google is no longer correctly following your internal links. Cross-reference with organic traffic data by landing page to identify content that has lost visibility.

What critical mistakes must absolutely be avoided?

Never assume that just because your site “works” in JavaScript, Google will automatically index everything. Google’s JavaScript rendering has limitations: execution timeouts, blocked resources, silent errors. Always test systematically with crawlers and the Search Console.

Avoid mixing multiple approaches (fragments, pushState, hashbang) on the same site. This architectural inconsistency creates confusion for crawlers and complicates analytics tracking. Choose a single strategy and apply it uniformly.

• Audit all URLs containing fragments (#) on your site
• Replace fragment navigation with pushState in SPAs
• Configure the server to properly handle rewritten URLs
• Test Google rendering via the URL inspection tool in the Search Console
• Implement 301 redirects if migrating from old URLs with fragments
• Monitor index coverage reports after each modification