URL Fragments and SEO: Google Ignores Everything After the #

On a classifieds site, filters multiply URLs faster than listings do. Price range, distance, mileage, year, seller type, sort order, posted-within: every combination is a new address if the filter lives in the path or the query string. I've been working through this on Gumtree's search pages, and one option keeps coming up in the discussion: put some of the filters after the #.

Two things about that option are settled. Everything else is a judgement call, so I'll separate them.

What is certain

Google doesn't crawl or index fragments. Google's documentation on faceted navigation says so directly:

Google Search generally doesn't support URL fragments in crawling and indexing. If your filtering mechanism is based on URL fragments, it will have no impact on crawling (positive or negative). [1]

The page was last updated on 18 December 2025.

The server never sees the fragment. This isn't a Google policy. It's how URLs work. RFC 3986 §3.5 says the fragment is separated from the rest of the URI before the request is made, and is "dereferenced solely by the user agent" [2]. When a browser requests /cars/manchester#price=0-5000, the server receives /cars/manchester. So does Googlebot's fetcher.

Put those together and a fragment filter is invisible to search. It creates no new URL to crawl, no duplicate to canonicalise, no index bloat. It also creates nothing that can rank. Google's phrase "positive or negative" is the whole trade in three words.

What Reddit's SEOs have said

I went through the r/TechSEO, r/bigseo and r/SEO threads on hash URLs and faceted navigation. The practitioners agree with the documentation, and the useful parts are the edge cases they raise.

Crawlers treat # the way Google does. In an April 2025 thread, someone asked why Screaming Frog wasn't crawling their hash URLs [3]. It's off by default, under Configuration > Spider > Advanced > "Crawl Fragment Identifiers". One reply made the point that matters: if you're trying to emulate a search engine, leave it off, because search engines ignore everything past the hash too. Turning it on mostly inflates your duplicate title counts.

Links to a fragment count for the page. Asked whether a 301 pointing at an anchor loses anything, one r/bigseo reply said PageRank doesn't flow to hash URLs but goes to the root URL instead [4]. A link to /cars/manchester#price=0-5000 is a link to /cars/manchester. That's good news for fragment filters: a shared filtered link still helps the category page.

Split filters by whether anyone searches for them. The clearest version of this is from a 2019 thread about moving to AJAX faceted navigation [5]. The advice was not to create a URL at all for something you don't want Googlebot to crawl: make the facets you want indexed into real paths, and the rest into fragment variables, as in /women/clothing/skirts/white/#size=52. "White" gets a page. Size 52 doesn't.

If a filter has search demand, it needs a real URL. A 2021 thread asked about AJAX filters with fragments, and the top reply's warning was about traffic, not crawling: if filtered pages could attract search volume, give them a dedicated page instead of a fragment [6]. Another reply pushed back on fragments entirely, for a user reason: people can't bookmark or share filters that don't update the URL, and canonicals from real filter URLs to the main page would be simpler. That's a fair objection to filters that don't update the address bar at all. It doesn't apply to fragment filters, which do.

Check traffic before you move anything. In an August 2020 thread about hash-routed URLs, a reply reminded the poster to check backlinks and other channels before deciding what not to redirect [7]. If an old parameter URL is indexed and earning clicks, moving that filter behind a # removes the page from search.

Hashbang is a different thing, and it's dead. Older threads about AngularJS sites and "hashtags within URLs" are mostly about #!, which Google once treated specially under its AJAX crawling scheme. That scheme was deprecated years ago. One reply recommending fragments to keep links out of the index made the distinction explicitly: a hash, but not a hashbang [8].

Google adds fragments of its own. A February 2025 r/webdev thread asked how to detect visitors arriving from Google's AI links, which use #:~:text= to highlight a passage [9]. The answer: you can't, by design. The spec keeps the text fragment away from page scripts. Another reply noted that ordinary quoted-phrase results use the same mechanism, so it wouldn't identify AI traffic anyway.

The other approach, for contrast

Most faceted navigation threads are arguments about query parameters: robots.txt disallow or canonical, noindex or not, whether crawl budget is real at 200,000 URLs [10][11]. One reply in a 2024 thread warned that when filter URLs share a structure with normal catalogue pages, Googlebot spends its time on the wrong ones [10].

Fragment filters sidestep that whole argument, because the URLs never exist as far as Google is concerned. You don't have to block, canonicalise or noindex something that was never requested.

How I'd apply it to classifieds search

The question for each filter is whether people search for the filtered result as a thing in itself.

Real URLs (path or clean parameter), indexable:

• Category: cars, sofas, bikes, property to rent.
• Location: city and region pages carry most of the demand on a local marketplace.
• Make and model, where the category has them: "used Ford Fiesta Leeds" is a search people make.

Fragment candidates:

• Sort order.
• Price range sliders, mileage bands, year ranges.
• Distance radius.
• Posted within the last 24 hours or 7 days.
• List or grid view.

None of those has a stable result set or a search query worth building a page for. Nobody searches for "cars in Manchester sorted by newest, within 15 miles".

Some filters sit in between, such as seller type, or a price bracket like "under £1000". Check Search Console and keyword data for them before deciding. If the query exists with real volume, give it a real, linked page with its own title rather than exposing the raw filter.

What fragments cost you

The fragment isn't free. The same property that hides it from Google hides it from your own server.

• Filtering is client-side. The server can't render a filtered result, because it never receives the filter. The page loads unfiltered, then JavaScript reads location.hash and fetches the filtered listings. Design for that first paint, or users see the wrong results flash.
• Server logs lose the filter. You'll need analytics events to see which filters people actually use. That data is also how you'd spot a filter that deserves promotion to a real URL later.
• Existing indexed filter URLs will drop. Moving a filter from ?price= to #price= means the parameter URL stops being linked. If it had clicks, you've given them up.
• Don't put indexable filters behind a #. If location or make ends up in the fragment, those pages disappear from search, and nothing in Google's reports will say why.

Checklist

1. List every filter on the search results page.
2. For each one, check Search Console queries and keyword data for demand on the filtered result.
3. Filters with demand get real, internally linked URLs. Everything else is a fragment candidate.
4. Before moving a filter, check whether its current URLs are indexed or earning traffic or links.
5. Make the JavaScript read the fragment on load, not only on click, so shared links open filtered.
6. Leave "Crawl Fragment Identifiers" off in your crawler if you want it to see what Google sees.

If you're moving filters out of query parameters, our redirect checker shows what an old URL now resolves to, and the bulk URL checker confirms the category pages you're keeping still return 200.

Sources

1. Google Search Central, Managing crawling of faceted navigation URLs, last updated 18 December 2025.
2. IETF, RFC 3986: Uniform Resource Identifier (URI): Generic Syntax, §3.5 Fragment.
3. r/TechSEO, Screaming Frog skipping URLs with hash fragments – is this normal?, April 2025.
4. r/bigseo, 301 to anchor tag, October 2022.
5. r/TechSEO, Moving towards an AJAX faceted navigation, July 2019.
6. r/TechSEO, AJAX with URL fragments for page filtering, January 2021.
7. r/TechSEO, Redirect plan for hashed URLs, August 2020.
8. r/TechSEO, What is the best way to prevent indexation of links by Google Bot?, June 2021.
9. r/webdev, Does anyone know if there is actually a way in JS to grab the text from a fragment directive from the URL?, February 2025.
10. r/TechSEO, Ecommerce Facet Navigation - Optimal Indexing Depth?, December 2024.
11. r/SEO, Faceted Filter Navigation - Stop with canonicals or robots.txt?, June 2018.