Every Filter On Your Store Needs One Of Four Answers

We opened 40 live shops this week to see how they handle faceted navigation. Of the ten leaving their filter URLs open to crawling, eight have a rel=canonical as their only control.

Google's own documentation places that option last, below both of the approaches it recommends.

If you have already hung canonicals, disallow lines and noindex tags on your own filters and watched nothing change, this is why.

Those four tools are four different answers to the same question. Giving one filter two of them at once is how the problem survives the fix.

I am John Butterworth. I have spent 11 years doing SEO on ecommerce sites, and across the accounts we have run at Mint SEO that work has driven more than 3M organic sessions. Filter URLs are the first thing I open on an audit, because on a catalogue of any size that is where the crawl goes.

This article sets out the four answers a filter can have, the test that picks one of them, and the order to apply them in when there is already a mess in the index.

The Four Ways To Handle Any Filter On Your Store

Every facet on your store gets exactly one of four handlings. Colour is a facet, and blue is a filter inside it.

That decision belongs to the facet and you take it once, which is what makes the job finishable. Take it per URL instead and you never finish, because your catalogue generates addresses faster than you can judge them.

Google splits the choice in two before you reach any tag. Either you prevent these URLs being crawled, or you accept the cost and make them good enough to crawl properly. Everything else is a weaker signal layered on top of that decision.

Give It A Real Landing Page

This is the answer for a facet people search by name. Give it a clean crawlable URL with its own copy and its own title, then a place in your internal linking.

Chris Lever is a technical marketer in Manchester with 14 years in ecommerce and crawl optimisation, and he gave a talk at Manchester DM on this exact trade. In his Manchester DM deck he argues that opening facet URLs to indexing can drive serious search growth but needs control. The signals he uses to choose between them are search volume and conversion potential.

Those signals decide which facets qualify. Google's Managing crawling of faceted navigation URLs page then attaches conditions to any filter URL you want crawled. A brand facet on walking boots should resolve to one stable address whichever way the shopper arrived at it, joined by a standard ampersand, and a brand with nothing in stock should "return an HTTP 404 status code".

That last one catches most stores out. An empty filtered page that renders happily with nothing on it is a soft 404, and you have just asked Google to keep it.

Block It In robots.txt

This is the answer for everything else, and Google treats it as the default. The same page is blunt about the trade, saying that "oftentimes there's no good reason to allow crawling of filtered items, as it consumes server resources for no or negligible benefit".

Its suggested shape blocks at the parameter and leaves one unfiltered listing open:

Write that once per facet and it covers every value inside the facet forever. That is the whole argument for deciding at the facet level.

Never Let The Filter Become A URL

Your third answer is to stop the address existing at all. If the filter is a fragment after a hash there is nothing to crawl, because "Google Search generally doesn't support URL fragments in crawling and indexing".

It is the cleanest option on paper and the most expensive in practice.

Ryan Siddle of Merj pushed back on it publicly when the guidance landed. He warned that fragment-based filtering can create accessibility problems under WCAG and add latency through web worker dependencies.

He also cites one development agency that needed over nine months to integrate it fully.

Nine months of developer time to save crawl budget is a real number to weigh.

Point It Back With A Canonical

Reaching for the fourth answer first is the common instinct, and Google ranks it last. Canonical tags and nofollow attributes are described on that same page as "generally less effective in the long term than the previously mentioned methods".

A canonical asks. A disallow prevents.

Google's wording on what a canonical achieves here is carefully hedged. It says only that a canonical "may, over time, decrease the crawl volume" of the versions it points away from.

Nofollow carries a condition almost no shop can meet. For it to work, "every anchor pointing to a specific URL must have the rel="nofollow" attribute", and that includes links from other people's websites.

The Test That Decides Which Ones Get Indexed

Three questions settle it, in order, and the first one that says no ends it.

Start with demand. Waterproof walking boots is a query somebody types, while waterproof walking boots in a size nine sorted by price is not. This is the same work behind building a keyword map for the rest of your store.

Then count the products behind the combination. On r/TechSEO, u/chewster1 answers a thread about indexing depth with a working floor of "minimum 2 or 3 products", and below that the page is thin whatever you write on it.

That leaves depth. The same reply caps combinations at "1 of each of those, sometimes 2x other facets allowed", so brand plus category earns a page while brand plus category plus colour plus size does not.

So a facet failing all three tests is not a landing page at all. It belongs behind one of the other three answers.

Why Three Fixes At Once Leave The Bloat In Place

Now for the mechanism behind the index bloat I opened with.

That bloat is what a store owner describes on r/TechSEO. u/Enough_Love945 has a JavaScript-heavy shop drowning in duplicate content from filter URLs. They had already tried canonical tags, disallow rules and noindex tags. The verdict on that thread was blunt: "the problem persists".

Two of those cancel each other out. Google's Block Search indexing with noindex page states the reason without hedging.

"If the page is blocked by a robots.txt file or the crawler can't access the page, the crawler will never see the noindex rule, and the page can still appear in search results, for example if other pages link to it."

A noindex is an instruction printed inside the page, while a disallow stops anyone opening the page. Put both on one URL and you have locked the letter inside the envelope.

The Order To Clear Filter URLs In

On a catalogue this bites hardest, because the filter URLs already in the index outnumber the products by an order of magnitude. u/HustlinInTheHall states the constraint further down the same r/TechSEO thread: "you can't block them until Google has crawled them, or Google won't see the noindex tag".

When there is already a mess in the index, the order is fixed, and few people run it this way round.

1. Put a noindex on the filtered pages and remove any canonical competing with it. On the same r/TechSEO thread u/IamWhatIAmStill is explicit about that second half, recommending it "while not having a canonical tag in the header to confuse signals".
2. Leave them crawlable and wait. Abandoning this step early is the usual mistake, because that reply warns it "can take a long time, months or beyond" before the pages clear out.
3. Only once they have dropped out, add the disallow so the crawling stops for good.

At scale you can carry step one in the HTTP header instead. Another commenter on that r/TechSEO thread, u/dohlant, suggests an X-Robots-Tag "to save further on crawl budget". That is the same instruction without the page having to render.

Why it takes months is worth understanding. Gary Illyes of Google put it plainly: "Once it discovers a set of URLs, it cannot make a decision about whether that URL space is good or not."

Googlebot cannot separate your worthless filters from your valuable ones cheaply. It pays first and judges afterwards.

Every Filter Combination Becomes Its Own Address

That cost is worth seeing for yourself, because the multiplication is the whole problem.

Google's Crawling December post on faceted navigation describes "a virtually infinite number of new URLs waiting to be discovered", because changing any single parameter mints a new address.

That is because filters multiply your crawlable surface. Four facets holding ten values each produce ten thousand combinations from one collection page.

Filter order then doubles that again. If a shopper clicking blue then medium produces a different URL from medium then blue, every combination exists twice over.

Google's guidance therefore asks you to "ensure that the logical order of the filters always stays the same and that no duplicate filters can exist". Developers call that normalisation. ABC always has to equal ACB.

This is also where parameter handling and pagination start compounding each other, and I have written separately about pagination on a large catalogue.

The Cost Of Leaving Every Filter Open To Crawling

In February 2026 Google published its year-end report on crawling problems, and Illyes broke the causes down by share on the Search Off the Record podcast.

Top of that list, at 50% of all the crawling problems Google recorded, were shop filters. Action parameters took a further 25%.

That puts half of everything Google finds difficult about crawling the web down to faceted navigation, which makes it the largest single category by a wide margin.

Google's own post says the same thing from the other direction, calling this "by far the most common source of overcrawl issues site owners report to us".

That is the cost of doing nothing. The cost of over-correcting is quieter, and it is just as real.

Block every filter and you give up a band of demand sitting between your category terms and your product names. Jill Kocher Brown made the case for that middle band in Practical Ecommerce, calling faceted pages "ideal for targeting keywords with midsized demand".

Brass table lamps is a real query, and neither your lamps category nor any single product page is answering it. Blocking everything is as blunt an answer as indexing everything.

Spend the crawl on the facets that earn it, which is the same discipline as working in order when you want more sales.

How Real Stores Handle Faceted Navigation Today

The guidance above is what Google recommends. What follows is what 40 shops are doing about it. On 5th August 2026 we opened one category page on each of 40 live ecommerce sites, spread across Shopify brands and large non-Shopify retailers in the UK and US, and every store named below can be checked the same way in a browser.

How We Measured The 40 Stores

On each page we pulled every link carrying a filter parameter. We then parsed that store's robots.txt using Google's own matching rules, and re-fetched sample filter URLs to read their canonical and meta robots tags.

Those checks did not work everywhere. Fifteen of the 40 pages had to be set aside, because eleven rendered no filter interface our headless browser could see and four never loaded at all.

A page whose filters we could not see is no evidence about how that shop is set up, so all fifteen are excluded from the counts below. That leaves 25 stores where the setup was observable.

What The Numbers Say

Eleven had already solved the crawl problem without using a directive at all, because their filters are checkboxes and buttons with no href behind them. Jill Kocher Brown named that mechanism years ago, pointing out that bots do not recognise links coded as "div or span tags".

Those eleven forfeit the mid-demand traffic an indexed facet would earn. Nothing is leaking, though.

But fourteen stores do turn filter combinations into crawlable addresses, and only four of them block those addresses in robots.txt. Brooklinen, Represent, IKEA and Matalan are the four.

The other ten leave them open, and this is the finding that matters. Eight of those ten rely on a rel=canonical and nothing else. Bombas and Ruggable are in that group, as are Wickes and Hobbycraft.

That makes the most popular control in the field the one Google's own documentation ranks below both of its recommendations.

Nobody there is doing something wrong. They have simply picked the weakest of the four instruments, and most of the stores using any instrument at all picked the same one.

Two of the ten return a canonical that keeps the filter in place. Cotswold Outdoor and Snow+Rock are treating those filtered views as pages in their own right, which is what a deliberate decision looks like from the outside.

Faceted Navigation On Shopify And WooCommerce

Your platform has already made some of these choices for you, and on Shopify one of them changed recently.

Shopify's changelog records that from 16th March 2026, "storefront filter URLs use stable group identifiers instead of text values". A readable URL parameter for a colour became an internal identifier instead.

Pavel Ungr works with Shopify merchants running filtered landing pages, and he published an analysis of who that hits with a one-minute test attached.

Apply a filter on a collection page and read the address bar. If you see gid://shopify/FilterSettingGroup in it, you are affected.

For most merchants his breakdown of what stayed untouched is the useful half. Filters built on tags and product type kept their format, as did vendor and price, while variant options and defined-value metafields did not.

The lesson generalises past Shopify. You do not own the format of your filter URLs. Building landing pages on them commits you to maintaining something the platform can change underneath you.

WooCommerce owners hit a different wall, and theirs is a documentation problem. A store owner on r/TechSEO trying to optimise filtered category pages said plainly that they "could not find any guide" for doing it. On Woo the layered navigation widget names your parameters for you, and templating a filtered view usually means a developer.

Reading Your Own Crawl Before You Change Anything

None of the above tells you what your own store does right now. Two reports do, and they are already sitting in your Google Search Console account.

Open the page-indexing report and read two statuses against each other. Crawled currently not indexed is a page Google fetched and rejected, while indexed though blocked by robots.txt is a page it never fetched and indexed anyway.

Those two statuses look similar and they need opposite fixes.

That first status means you are spending crawl on pages Google does not want, so block them.

The second means you blocked something Google had already decided to keep. Unblock it, let the noindex be read, then block it again.

On a store that has never controlled its facets, I regularly see two thirds of the crawl going to filter URLs on a first audit.

Then open crawl stats and see what Googlebot is requesting on your own store against that benchmark.

While you read those numbers, Chris Lever's framing of the downside is the right one to hold. Handled badly, he warns, faceted navigation will "bury your most valuable pages".

Nothing errors while that happens. The pages you care about are reached later, or not at all.

If the numbers look wrong, work through the wider fix in sequence. I have set out the order we work in on a store's technical problems separately.

Getting A Second Pair Of Eyes On Your Filter Setup

The hard part of faceted navigation is not knowing the four answers. It is sitting with your own facet list, assigning one answer to each of them, then proving the decision landed.

That is what an SEO audit from us produces for a catalogue. You get a recorded verdict per facet on your own store, the robots.txt and template changes that carry it, and the Search Console evidence showing what the crawl did afterwards.

In the audits I run, crawl waste from filters is the finding I write up most often. It usually opens the report and carries the most revenue.

Eleven years of doing this on ecommerce sites means we have seen most filter setups before, including the ones a platform will not let you change cleanly.

If you want the facet list settled and the crawl evidence behind it, get your SEO audit. If you would rather put your own filter setup in front of someone first, book a free 30-minute call with me.

Frequently Asked Questions About Faceted Navigation

Should I noindex or canonical a filtered page?

Neither, as a default. Google's documentation ranks both below blocking the crawl or never creating the URL in the first place.

Run the demand test first, because it usually answers the question for you. A facet nobody searches for wants blocking outright, and a canonical is for the leftovers your shoppers genuinely click but nobody types.

Does robots.txt stop a page being indexed?

No, it only stops the crawl. Someone linking to your blue-size-nine page from a forum can still put it in the index, and because Googlebot is no longer allowed to fetch it, the noindex you placed inside never gets read.

Why are my filter pages still in Google after I blocked them?

Because the disallow landed before Googlebot had re-crawled them, which freezes those filter URLs in the index exactly as they were. Lift it, give the noindex the months it needs to be read across the catalogue, then put the disallow back.

How many products should a filtered page have before I index it?

Practitioners running this at scale work to a floor of two or three products. Search demand for the combination weighs heavier than the count, so no demand means no landing page however full it is.

Can filtered pages rank?

Yes. That is the whole reason to index any of them, and they target the middle of the demand curve, between your category terms and your product names.

How long does it take for blocked pages to drop out?

Months, on a large catalogue. Get the signal in place and leave it alone for longer than a fortnight before you judge it.

Does the order of filters in a URL matter?

Yes. If two orders produce two addresses for identical results, you have doubled the problem.

Normalise the parameter order at the template so blue-then-medium and medium-then-blue resolve to one address.

Most platforms handle this once a developer knows to ask, much as a customer record system settles duplicate records on the sales side.