Skip to content

Lesson 3 of 3

Faceted navigation and filters

Filters create thousands of URLs. Decide which ones Google should index and stop the rest wasting crawl budget.

5 min readIntermediateUpdated 2026-08-22

A store with a few hundred pairs of trail shoes lets shoppers narrow the list by size, colour, brand, price and sort order. Every tick adds a parameter to the URL, and the same options ticked in a different order produce yet another URL. To Googlebot each of those addresses is a page to fetch. Multiply the options together and a small catalogue turns into a site of tens of thousands of URLs, nearly all showing the same products in a different arrangement. Filters are the biggest way a store wastes Google's attention, and the fix is to decide which filtered views deserve to be pages and close the door on the rest.

How filters multiply into a crawl problem

Faceted navigation is the name for filters that can be combined: each facet (colour, size, brand) has values, and any mix can be selected. If the store builds a new URL for every mix, the URL count grows with every facet, and again when parameter order or the sort setting changes the URL without changing the products. Google's guidance on managing faceted navigation URLs names this as one of the most common causes of overcrawling, because the filtered pages mostly repeat content that already exists on the unfiltered collection.

Google doesn't crawl a site without limit. Its crawl budget guidance describes two halves: how fast Googlebot can fetch without straining your server, and how much it wants to fetch based on how valuable and fresh it thinks your URLs are. The same guidance says this is mostly a concern for very large sites, naming roughly a million unique pages that change weekly, or ten thousand that change daily, as the scale where it bites. A shoe store doesn't start there, but filters can carry it there unnoticed.

The damage shows up twice. In crawling, fetches go to filter clones while a new product or a price change waits its turn. In indexing, the clones compete with the collection they copy for the same searches.

Decide which filtered views deserve a page

A filtered view earns its own indexed page under the same test a collection passes in the structure lesson:

  1. People search for that combination. "Women's waterproof trail running shoes" is a search. "Trail shoes under a price cap, sorted by newest" is not.
  2. The products in it differ meaningfully from the parent collection.
  3. You can write a title, heading and intro that describe it in the buyer's words.

Build a view that passes as a collection with a clean, stable URL such as /collections/womens-waterproof-trail-shoes, give it intro text, link it from its parent collection, and put it in the sitemap.

In practice single facets such as gender, product type and sometimes brand pass. Two combined pass occasionally, three almost never, and price ranges, sort order and stock availability nearly never earn a page.

Keep the rest out of Google's way

Google's faceted navigation guidance lays out the options; they aren't equally effective.

Don't create crawlable URLs at all. This is the most effective option. If filter state lives in the URL fragment (the part after #), Google ignores it and sees one page. The same is true when filtering updates the product grid without changing the URL and without rendering <a href> links to each combination.

Block the parameter patterns in robots.txt. A rule such as Disallow: /*?*filter or a rule for your sort parameter stops Googlebot fetching those URLs. One caution from Google's own guidance: anything reachable only through a blocked URL loses its path, so keep every product linked from the unfiltered collection and listed in your sitemap.

Use canonical and noindex tags for indexing, not for budget. A canonical tag on the filtered page pointing to the unfiltered collection tells Google which version to index. But Google must fetch the page to read the tag, so the crawl is already spent. The same applies to noindex; Google's crawl budget guidance is clear that it doesn't save crawling.

For the filter URLs you do allow, the same faceted navigation guidance asks for standard key=value parameters joined with &, parameters in a consistent order no matter which box the shopper ticked first, and a 404 status for combinations with no products.

Platforms differ in what they give you. Shopify's filter URLs use parameters beginning filter. plus sort_by; its default robots.txt already blocks some sort and tag-combination patterns, and you can edit the rest through the robots.txt.liquid template. WooCommerce filter widgets typically use filter_ parameters and orderby. Don't assume what your store does; look.

Check what Google is actually doing

Watch whether Google's behaviour actually changes. Search Console's Page indexing report groups filtered URLs under reasons such as "Alternate page with proper canonical tag", "Excluded by noindex tag" and "Blocked by robots.txt"; the share in each bucket tells you which control is doing the work. The Crawl stats report, found under Settings, lists sample URLs Googlebot fetched. If the samples are full of parameter strings, the crawl is going to filters, whatever your tags say.

Expect the numbers to move slowly, because Google revisits known URLs on its own schedule.

What to take away

  • Filters generate a URL for every combination, and Google's faceted navigation guidance names them as a leading cause of wasted crawling.
  • A filtered view becomes an indexed page only when people search for it and you can build it as a collection with a clean URL and its own text.
  • The most effective controls stop URLs being crawlable at all; robots.txt blocks crawling; canonical and noindex only fix indexing after the crawl is spent.
  • Watch Search Console's Page indexing and Crawl stats reports to confirm the crawl has moved from filters to products.

Next

With the store's structure under control, the next chapter starts on the pages themselves in Product titles and descriptions.

Free tools this lesson uses

Saved in this browser only.

Chapter 3: Turn every page into a traffic and sales machine

All 9 chapters