Faceted Filtering
Date: 2026-08-17
Narrowing a set by independent attributes. On a large catalogue it is the navigation, and its two failure modes are opposite — filters that return nothing, and filters that generate millions of crawlable URLs nobody wanted.
Faceted filtering lets someone narrow a result set by selecting values across several independent attributes — brand, price, size, concern — in any order.
Facets are orthogonal; categories are hierarchical. That’s the whole reason both exist: a hierarchy can only express one path to a product, and facets express all the others simultaneously — Information Architecture.
The interaction rules
WITHIN one facet OR
Brand: A or B → shows both
ACROSS facets AND
Brand: A
+ Size: 50ml → only A in 50ml
This is a convention people have learned, and breaking it — making multiple brand selections behave as AND — produces empty results and confusion.
Show counts, and disable dead ends
The single highest-value implementation detail:
WITHOUT COUNTS WITH COUNTS
□ Sensitive skin □ Sensitive skin (23)
□ Oily skin □ Oily skin (41)
□ Mature skin □ Mature skin (0) ← greyed
out
Counts prevent the dead end. Without them, every selection is a gamble, and a zero-result filter combination reads as a broken site rather than as an empty intersection.
Update counts as selections are made, so the remaining options reflect the current set. Static counts are worse than none, because they promise results that aren’t there.
What to do when the result set is empty
BAD "0 products found"
GOOD "No products match all 4 filters.
Try removing:
× Size: 50ml (would show 12)
× Price: under £20 (would show 8)"
Naming which filter to relax turns a dead end into a decision. It requires computing the count with each filter removed — cheap, and rarely implemented.
Choosing which facets to offer
OFFER
attributes people actually decide by
→ concern, brand, price, size, format
DON'T OFFER
attributes with one value across the
catalogue
attributes with 200 values and no
grouping
internal classifications
anything with poor data coverage
Data coverage is the constraint nobody checks. A facet where 40% of products have no value silently hides those products the moment anyone uses it — Taxonomy and Labelling.
Order facets by usage, not by internal logic. Price and brand are usually top; a merchandiser’s preferred axis usually isn’t.
The URL and SEO problem
The failure mode that costs the most and is least visible in UX work.
4 facets × 10 values each
= over a million combinations
= over a million URLs
→ crawl budget spent on near-duplicates
→ thin, duplicated pages indexed
Decide deliberately which filtered views are pages and which aren’t:
INDEXABLE high-demand combinations
with real search volume
"sensitive skin serum"
→ a real landing page
NOT INDEXABLE everything else
→ canonical to the parent
category, or noindex,
or use parameters the
crawler is told to
ignore
This is a decision, not a default — and left undecided, the platform’s default is usually to expose everything — Faceted Navigation and Crawl Budget, Technical SEO.
Mobile
Facets on mobile are a genuinely different design, not a narrower one:
- A full-screen panel, not a squeezed sidebar
- Apply as a deliberate action, so the list doesn’t reflow under the finger on every tap
- Show the resulting count on the apply button — “Show 23 products” — so the outcome is known before committing
- Selected filters visible and individually removable after applying, or people forget what’s applied and conclude the catalogue is small
Measuring it
- Filter usage rate, and by facet — unused facets are clutter
- Zero-result combinations — which, and how often
- Conversion with versus without filtering — filterers usually convert much better. Correlational, and still informative
- Abandonment after filtering — the sharpest signal of a bad result set
Zero-result combinations are a range-planning input as much as a UX one — a combination people repeatedly try and you never stock is demand data — Search and Findability.