Why will your hash (#) URLs never be indexed by Google?

Are hash URLs truly invisible to Googlebot?

Yes, and this is a fundamental principle of how the web operates. The hash (#) has historically been used for client-side intra-page navigation: the browser never sends it to the server during an HTTP request. Googlebot, which operates like a standard HTTP client, never sees what follows the hash.

In practical terms for Google, example.com/match#live123 and example.com/match are strictly identical. The engine crawls the URL without the fragment, renders the page, but cannot distinguish the different states of a JavaScript application that relies on hashes to create distinct "routes".

Why do so many sites still use hashes to route content?

Because it's simple, quick to implement, and historic JavaScript frameworks (Angular.js in hashbang mode, React Router in hash mode) have popularized it. There's no need for server configuration, no management of rewrites: everything happens on the client-side.

The problem? This technical convenience comes at a cost to SEO visibility. A site generating thousands of hash URLs for product pages, articles, or temporary events creates invisible content for search engines. It's a complete blind spot.

What really happens to temporary content after the event?

Martin Splitt points out a crucial point: returning a 404 after the event is normal and acceptable. Google then removes the URL from the index without viewing it as an error or a negative signal. This aligns with the ephemeral nature of the content.

This approach is healthy: it avoids accumulating dead pages in the index and clarifies the intent. A match on March 15 no longer needs to be indexed on March 20. The 404 is an honest response, not a technical flaw.

• Hash URLs (#) are never sent to the server so Googlebot cannot crawl or index them
• For indexable temporary content, you need to use clean routes without a hash (e.g., /match/live-123)
• A 404 after the event is a healthy practice: Google naturally removes the URL from the index
• Modern JavaScript frameworks support history mode (HTML5 pushState) which generates clean URLs
• Never confuse ease of development with SEO compatibility: hashes represent a complete blind spot

Is this statement consistent with field observations?

Yes, absolutely. This is one of the few points where Google is perfectly clear and aligned with the technical reality of the web. Hashes are never sent in HTTP requests: this is a W3C standard, not an arbitrary decision by Google.

I have audited hundreds of SPA (Single Page Application) sites, and the pattern is always the same: clients who have left hashes in their routes generate invisible content. When switching to history mode, indexing skyrockets within a few weeks. It is reproducible, measurable, and systematic.

What nuances should be applied to this statement?

The only nuance concerns hash fragments used for Ajax crawling (the hashbang #! system that Google proposed and then abandoned in 2015). Some very old sites still use it, but it is technically obsolete and Google no longer officially supports it.

The second point: Google can theoretically execute JavaScript that manipulates the URL after the initial rendering. But in practice, if your content relies on a hash to be displayed, the probability that it is correctly indexed is nearly zero. Don't count on hypothetical heuristics.

In what cases does this rule pose problems in production?

The classic case: a React/Vue app that uses hash mode by default to avoid server configuration. The dev team delivers quickly, the content works perfectly in client-side navigation, but Google sees nothing. The SEO discovers the problem three months after the launch.

Another common situation: dynamically generated temporary events (webinars, matches, flash promotions). If the technical team took the shortcut of a hash to avoid touching the backend infrastructure, the content remains invisible. Result: zero organic traffic during the event, exactly when the search peak is highest.

What concrete steps should be taken to make temporary content indexable?

First step: audit your current routes. If you are using a JavaScript framework, check the configured routing mode. React Router, Vue Router, Angular: all offer a history mode (HTML5 pushState) that generates clean URLs without a hash.

Next, configure your server so that all routes return your main HTML (index.html or equivalent). This is the principle of universal fallback: Nginx, Apache, Netlify, Vercel all have standard configurations for this. Without this fallback, a manual refresh on /match/live-123 returns a server 404.

How to properly manage the end of life of temporary content?

The approach recommended by Martin Splitt is simple: return a true 404 once the event is over. Not a soft 404, not a redirect to the homepage: a clear HTTP 404.

You can soften the user experience with a custom 404 page suggesting similar upcoming events, but the HTTP code must be 404. Google will interpret the signal correctly and will remove the URL from the index within a few days or weeks, depending on your site's crawl frequency.

What mistakes should absolutely be avoided in this context?

Mistake number 1: using hashes for content you want to index. It’s a complete blind spot; no heuristic will come to your rescue. Don't rely on Google's JavaScript execution to circumvent this structural problem.

Mistake number 2: allowing temporary content URLs to return 200 with a message "event ended". This is a soft 404; Google will take longer to deindex, and you pollute your index with pages of no value. A 404 is an honest and effective response.

• Check your JavaScript framework's routing mode (hash vs history)
• Configure the server fallback so that all routes return the main HTML
• Test direct navigation (manual refresh) on a deep route to validate the configuration
• Return a clear HTTP 404 once the temporary content has expired
• Monitor deindexing through Search Console to validate that Google is indeed removing the URLs
• Document the logic of generation/expiration of temporary URLs for the tech teams