Does a page URL with a # affect indexing in front-end SEO (Google/Baidu)?

In front-end SEO (Google/Baidu), whether a page URL contains a # makes a noticeable difference to indexing. Based on 2026 project delivery experience, pages with a # are more likely to be treated as the same address by Google and Baidu, and the indexing coverage of content pages is typically 30–50% lower than with history routing; if the content is also loaded client-side via JavaScript, missed indexing becomes even more obvious. Therefore, for content-oriented sites and SPA projects, we recommend using history routing so that every page has an independent path.

Search engines treat # as an anchor, not a new page

In the HTTP protocol, the # in a URL is a fragment identifier, and the browser does not send the part after # to the server. For search engine crawlers, http://example.com/#/about and http://example.com/#/home are usually treated as the same resource address; if content is also switched in the browser using JavaScript, a crawler that fetches the homepage sees only an empty shell, so naturally only the homepage gets indexed. Google once provided compatibility for #! (hashbang), but official guidance as of 2026 no longer recommends it; Baidu's ability to crawl hash routes segment by segment is a common shortcoming.

• Hash routing: simple to implement and requires no server support, but content after # does not pass through the server, making it hard for crawlers to distinguish. Suitable for tool backends, demo pages, or pages that do not need SEO.
• History routing: clean, accessible URLs that crawlers can treat as independent addresses, but the server must fall back unknown paths to the entry file. Suitable for content sites, e-commerce listing pages, and other indexing-dependent scenarios.

Applicable scenarios and boundaries: which projects should change, and which shouldn't

Based on enterprise project deliveries in 2026, three types of situations most often suffer from hash routing: news/blog/product showcase sites where pages need to pass authority; mini programs and H5 pages sharing the same codebase, with hash navigation inside the H5 shell; and marketing websites that rely on Baidu organic traffic. In these scenarios, if you keep hash routing, operators usually see only the homepage rank, while index coverage for internal pages stays flat.

In a 2026 company website redesign, the client asked us to keep the original URLs and ensure every campaign page could be found by search. The existing site was a Vue app with hash routing and asynchronous page loading; after one month live, Baidu had only indexed the homepage. Although the budget and domain restrictions ruled out a full SSR rebuild, we changed the routing from hash to history, added a try_files fallback on the server, and pre-rendered static content for key pages. The old campaign URLs needed 301 redirects, which added two to three days of integration work, but index coverage ultimately rose from single digits to above 60%.

Not every page is worth removing the #, though. An authenticated admin backend, a utility SPA, or an internal enterprise system that does not want search traffic can keep hash routing as a low-cost option without server support. The rule is simple: does the page content need organic search traffic? If not, keep the hash.

Before changing routes, run the three-step verification

We've often seen teams switch directly from hash to history, then face 404s on refresh, index loss for internal pages, or even ranking decline. Before any route change, verify three things from top to bottom:

1. Confirm that all content has an independently reachable URL: After removing #, can the full path be visited directly? For example, change /#/news/123 to /news/123 and open that address in a browser; does the server return the HTML entry instead of a 404?
2. Confirm that server fallback is correct: For SPAs, all non-static paths should fall back to index.html, or a refresh returns 404. A common Nginx configuration is try_files $uri $uri/ /index.html; Apache, Node, and edge services have similar rules.
3. Confirm that required content is output directly or pre-rendered in HTML: If a crawler cannot execute (or fully execute) JavaScript, at least pre-render the title, meta description, and body summary on the server. Full SSR is better, but on-demand pre-rendering or a skeleton can be enough.

The first step is decisive: after switching from hash to history, each path must be storable, shareable, and crawlable as an independent URL. The second step is the usual trap; many post-launch declines in Baidu indexing are not because Baidu rejects history routing, but because server misconfiguration causes crawlers to hit large-scale 404s. The third step decides whether content can be indexed. Common practice in 2026 shows that pre-rendering only the first-screen routes can solve most issues when budget is tight.

Four rework points to block before launch

From project delivery experience, these four problems cause the most rework, so fix them before switching routes:

• 301 old URLs: Hash-routed URLs usually contain #, so search engines may have already indexed some of those addresses. After launch, redirect those old URLs with 301s to the new history URLs instead of serving 404s, otherwise existing indexation will be lost.
• Convert all internal links to history format: This includes navigation, button jumps, and article inline links. If any component still uses window.location.assign('/#/x'), the same page will appear under two sets of URLs.
• Ensure tracking does not use # to separate pages: Many teams use hash for SPA analytics; after migration, switch to the history popstate event, otherwise PV/UV data will break.
• Submit new URLs in Google Search Console and Baidu Webmaster Tools: In the first few weeks after launch, watch crawl errors and index status, and use the URL inspection tool to simulate Googlebot when necessary.

What counts as passing? Visit the new URL directly in a logged-out browser and you should get a 200 with meaningful content; save the page source and find the title and core text; simulate fetching and rendering in webmaster tools and the returned HTML should no longer be an empty shell. After these checks pass, wait one or two indexing cycles and you will usually see visible changes in index coverage.

Frequently Asked Questions

Can a URL with a # be indexed by Baidu?

Yes, but normally only the homepage or a very few hash addresses are indexed. Baidu's recognition of hash fragments is limited; if the homepage can render content, Baidu may index it, but it will not treat internal pages as independent URLs.

Does every page need SSR after switching to history routing?

Not necessarily. Pages whose content needs to be indexed are the ones worth SSR or pre-rendering; purely interactive pages can stay with CSR. In our typical experience range, pre-rendering handles 70–80% of the problem.

What happens if an old site with many # links simply removes them?

Direct removal causes 404s for already-indexed pages and lost authority. Find the hash paths that are actually accessed from historical access logs first, and set up 301 redirects for the ones still receiving traffic instead of cutting them off.

Does Google treat hash and history routing the same?

Google is more friendly to history, but it can render some JavaScript. If Googlebot can execute JS, content on hash-routed pages may still be discovered. Baidu and third-party engines inside WeChat are generally weaker, so history remains the safer choice.

If you are doing front-end SEO (Google/Baidu), first check whether your live content-page URLs contain a # and determine whether those pages depend on organic traffic. For pages with traffic value, switch them to history by following the three-step verification above and configure the server fallback; for admin backends or tool pages, there is no need. During the migration, set up 301s and submit the new URLs for verification; you can usually see a change in index coverage within two to four weeks. This approach applies to content-driven sites and SPA marketing websites, not to purely local tools or applications that explicitly do not require indexing.