URL Fragments and Hash URLs: How Search Engines Treat #

Short answer: The part of a URL after the # sign is called the fragment. Browsers do not send it to the server, and search engines generally treat /page#section as the same URL as /page. That is fine for jump links within a page, which can even appear as “jump to” links in results. It is a problem when a site uses fragments to show different content, as in single-page apps with hash routing: every “page” collapses into one URL. Use real paths or query parameters for anything that should be indexed separately.

What a URL fragment is

A URL has several parts. In https://example.com/guide/?lang=en#pricing, the scheme is https, the host is example.com, the path is /guide/, the query is lang=en and the fragment is pricing.

The fragment was designed to point to a location inside a document. When a browser loads the URL, it requests /guide/?lang=en from the server, receives the page and then scrolls to the element with id="pricing". The fragment itself never reaches the server. That has consequences:

• Server logs never show fragments, so you cannot see in logs which section people linked to.
• The server cannot return different content based on the fragment. Only JavaScript in the browser can read it.
• Caches and CDNs treat URLs with different fragments as the same resource.

The formal definition is in the URI standard, RFC 3986, which describes the fragment as a secondary resource identified relative to the primary one.

How search engines treat fragments

Because the fragment identifies a place within a document, not a different document, search engines normally drop it when they decide which URL to crawl and index. /guide/#pricing, /guide/#faq and /guide/ are one URL from the index’s point of view. Links pointing to any of them count as links to /guide/.

There are a few exceptions and nuances worth knowing:

• Jump links in results. Google sometimes shows links that lead directly to a section of a page, using the fragment. Clear headings with id attributes and a table of contents make this more likely. Our guide to table of contents and jump links covers how to set them up.
• Text fragments. URLs with #:~:text= highlight specific text on a page. Search engines and browsers use them to send visitors to the exact passage from a snippet. You do not need to create them; they work automatically on normal HTML text.
• The old hashbang scheme. Years ago, Google supported an AJAX crawling scheme with #! URLs and special “escaped fragment” versions. It was deprecated in 2015 and is no longer supported. Sites still using #! URLs depend on rendering and are best migrated to normal paths.

Where fragments are fine

For their original purpose, fragments are useful and have no SEO downside:

• Table of contents links on long articles.
• FAQ anchors that let support teams link to a specific answer.
• Links from other pages to a specific section, for example /shipping/#returns.
• Tabs and accordions that exist in the HTML and use the fragment only to open the right panel.

In each case, all content is in the page HTML, and the fragment only changes the scroll position or which part is visible. Search engines index the whole page, including every section.

Best practice for these anchors: use short, stable, readable IDs like #returns rather than generated ones like #h-7f3a, and do not change them when you edit the heading, because external links may depend on them.

Where fragments cause problems

Problems start when the fragment is used to load different content, rather than to move within the same content.

1. Hash routing in single-page applications. Some JavaScript frameworks can use routes like /#/about, /#/products/42 and /#/contact. To a search engine these are all just /. Only one page can be indexed, and the content of the others is effectively invisible to search as separate pages.
2. Filters and pagination in fragments. A category that stores filters or page numbers as #color=red&page=3 gives search engines one URL, so deeper pages and their items may never be discovered through it.
3. Content loaded by fragment. A page that fetches a different article when the fragment changes shows crawlers only the default content.
4. Language versions in fragments. Using #de or #fr to switch languages makes it impossible to give each language its own indexable URL and hreflang annotations.

The general principle is the same as in JavaScript SEO basics: every piece of content that should rank on its own needs its own URL that returns that content when requested.

Fixing hash-routed sites

If your site or app uses hash routing for public content, the fix is to move to path-based routing:

1. Switch the router to history mode. Most frameworks support routes like /about using the browser’s History API instead of #/about. This is usually a configuration change in the router.
2. Configure the server. With history mode, the server must return the application for every route, not a 404. Ideally, render the content on the server or pre-render it, so that each URL returns its own HTML without waiting for JavaScript.
3. Redirect old hash URLs in the browser. Because the server never sees fragments, server redirects cannot catch /#/about. Add a small script that reads the fragment on load and replaces the URL with /about. External links to old hash URLs then still work for visitors.
4. Update internal links and the sitemap. All links should point to the new paths, and the XML sitemap should list them.
5. Give each route its own metadata. Unique title, meta description, canonical and headings per route.

For filters and pagination, use query parameters or paths for the combinations you want indexed, and follow the guidance in URL parameters and duplicate content for the rest.

Fragments in canonicals, sitemaps and hreflang

Fragments do not belong in the URLs you declare to search engines:

• Canonical tags should point to the URL without a fragment. A canonical of /guide/#top is at best ignored and at worst confusing. See canonical tags explained.
• XML sitemaps should list plain URLs. Listing /guide/#faq alongside /guide/ adds duplicates without benefit, as explained in XML sitemap best practices.
• hreflang annotations must point to the actual language version URLs, never to fragments.
• Open Graph URLs should match the canonical, without fragments.

Plugins and scripts sometimes add fragments automatically, for example a “#more” anchor on WordPress read-more links or a “#respond” anchor on comment links. These are harmless in links, but check that they do not end up in canonicals or sitemaps.

Fragments and tracking

Since fragments are not sent to the server, some tools use them for client-side purposes, such as passing campaign information or state within a page. A few points to keep in mind:

• Standard analytics tools read UTM parameters from the query string, not the fragment, unless specifically configured.
• Putting tracking data in the fragment avoids creating duplicate URLs for crawlers, which is why some teams prefer it, but it requires custom analytics setup.
• Access tokens or personal data in fragments are not sent to your server, but they are visible to scripts on the page and in browser history. Treat them with care.

Quick reference: path, query or fragment?

How an audit spots fragment problems

Hash-routed sites usually show a very clear pattern in a crawl: only a handful of URLs are found, and most content is missing or requires JavaScript to appear. Site SEO AI Audit crawls through links like a search engine, reports pages whose content depends on JavaScript, and checks canonicals, sitemaps and hreflang for problems such as duplicates and broken targets. If the crawl finds far fewer pages than your app has routes, fragments are a likely cause. Paid plans include re-audits to confirm the migration worked.

Related reading

• SEO-friendly URLs: how to write clean page slugs
• WWW, trailing slashes and case: one URL version only
• Why AI crawlers miss JavaScript content and how to fix it

The bottom line

Search engines treat everything after # as a location inside the same page. Use fragments for jump links, tables of contents and in-page tabs, where they work well. Never use them to separate content that should be indexed on its own, such as app routes, filters or language versions. Move those to paths or query parameters, redirect old hash URLs with a small script, and keep fragments out of canonicals, sitemaps and hreflang.

FAQ

Does Google index URLs with a hash?

Google generally ignores the fragment and indexes the URL without it. /page#a and /page#b are treated as the same URL as /page.

Are jump links good for SEO?

They help readers navigate long pages and can appear as direct links to sections in search results. They do not create separate indexable pages, and they do not need to.

Can I redirect a URL with a fragment on the server?

No. The server never receives the fragment, so the redirect must be done with JavaScript in the browser, which reads the fragment and changes the URL.

Is hash routing always bad?

For private app screens behind a login it does not matter. For public content that should appear in search, path-based routing with server-side or pre-rendered HTML is much safer.

Do links to URLs with fragments pass value?

Yes. A link to /page#section is treated as a link to /page, so it supports the page as a whole.