How to Design Filters and Faceted Search

Filters exist to narrow a set someone cannot scan. The failure mode is narrowing it to nothing and leaving them there.

How to Design Filters and Faceted Search — Troiana insight cover

In short

Show only filters that meaningfully divide the current set, display result counts so people can predict the outcome, and never let someone reach zero results without a route back. Filter state belongs in the URL so results can be shared and returned to — but that same URL generation is the largest source of crawl waste on catalogue sites, so decide deliberately which combinations should be indexable.

Start from how people narrow

People do not usually think in your taxonomy. They think in constraints: under €50, available now, in my size, the blue one.

So the filters that matter are the ones matching how someone actually eliminates options — which is rarely the same as how your catalogue is structured internally.

The most reliable source is your own data: which filters get used, in what order, and which searches return nothing. That tells you what people are trying to narrow by, including the dimension you did not offer.

Show fewer filters, better

A sidebar with fifteen collapsed filter groups is a wall, and most of it is never touched.

Show the filters that meaningfully divide this set. A filter where every item has the same value does nothing. A filter with twenty options each matching one item does nothing either.

Order by usefulness, not alphabetically or by internal hierarchy. Price and availability usually belong near the top.

Collapse the long tail but keep the first few options visible, so people can see what kind of thing the filter contains without expanding it.

Hide filters that do not apply. If someone has narrowed to one category, filters relevant only to another are noise.

Always show counts

A count beside each option — Blue (14) — does two things at once.

It lets someone predict the outcome before clicking, which prevents the frustrating cycle of applying a filter, getting nothing, and undoing it. And it communicates the shape of the set, which is information in itself.

Disable or hide options that would produce zero results. Letting someone select a filter that empties the page is the most avoidable failure in this pattern.

Zero results is a design failure

When it happens anyway, the empty state has work to do. It must say what produced no results, in terms of the filters applied, not "no results found."

Then it must offer a route: remove the most restrictive filter, clear everything, or show near matches with an explanation of what was relaxed. And it should keep the filters visible so someone can adjust rather than start again.

A dead end here loses the visit entirely, which is why this deserves the same care as any other empty state.

Make the applied state obvious

People lose track of what they have selected, particularly after scrolling.

Show applied filters as removable chips above the results, with a single control to clear all. Keep the result count visible and updated. And when results update without a page load, announce the change in a live region — otherwise a screen reader user selects a filter and receives no indication anything happened.

Put state in the URL

Filter state should live in the URL. Without it, people cannot share a filtered view, cannot bookmark one, and lose their selection on back or refresh — which is a surprisingly common and infuriating failure.

Keep the parameters readable and stable, and keep their order consistent so the same selection always produces the same URL. That last detail matters more than it appears, because inconsistent ordering multiplies the number of distinct URLs representing identical results.

The SEO problem

This is where faceted navigation causes real damage, and it is worth deciding before launch rather than after.

Filter combinations generate URLs combinatorially. Five filters with a handful of options each produce thousands of addresses, nearly all serving near-identical content. Left unmanaged this is the single largest source of crawl waste on catalogue sites, and it produces exactly the duplicate content pattern that leaves pages crawled and not indexed.

The approach that works:

Decide which combinations deserve indexing. Usually single high-value facets — a category, a brand — that people genuinely search for. Those can be real pages with their own titles and copy.

Keep everything else out of the index. noindex the arbitrary combinations, or block the parameters from being crawled.

Canonicalise sort and view parameters to the unsorted version, since sorting does not change the content.

Do not link to every combination. If your interface generates links to thousands of filtered views, crawlers will follow them.

Performance

Filtering feels broken when it is slow, because people expect it to be instant.

Update results without a full page load where you can, but keep the URL synchronised. Debounce inputs that filter as you type. And make sure the underlying queries are indexed for the fields people actually filter on — faceted queries with counts are among the more expensive things a catalogue does, and unindexed filter columns are the usual cause of a slow one.

A short checklist

Do the filters match how people narrow? Are counts shown? Are zero-result options prevented? Is the applied state visible and removable? Is state in the URL? Have you decided which combinations are indexable? Does it announce changes to assistive technology?

Most catalogue sites fail on counts, zero results, and the indexing decision — and the third is the one that quietly costs the most.

If you are building a catalogue and want the facet strategy settled before it generates fifty thousand URLs, book a call.

Common questions

Which filters should a product listing show?

The ones that meaningfully divide the current set and match how people actually narrow — price, availability, size, colour — rather than mirroring your internal taxonomy. A filter where every item shares the same value, or where each option matches one item, does no work and should not be shown.

Should filters show result counts?

Yes. Counts let someone predict the outcome before clicking, which prevents the cycle of applying a filter, getting nothing, and undoing it. They also communicate the shape of the set. Options that would produce zero results should be disabled or hidden entirely.

Should filter state be in the URL?

Yes — otherwise people cannot share or bookmark a filtered view and lose their selection on refresh or back. Keep parameters readable and their order consistent, since inconsistent ordering multiplies the number of distinct URLs representing identical results.

How do you stop faceted navigation causing SEO problems?

Decide which combinations deserve indexing — usually single high-value facets like a category or brand that people genuinely search — and keep everything else out with noindex or by blocking the parameters from crawling. Canonicalise sort and view parameters, and avoid linking to every possible combination.

What should happen when filters return no results?

The empty state should say which filters produced nothing, keep the filters visible so they can be adjusted rather than restarted, and offer a route out — removing the most restrictive filter, clearing everything, or showing near matches with an explanation of what was relaxed.

Have something worth building right?