On a store of any size, the search box gets the credit and the filters do the work. Watch a session recording for ten minutes and you will see it: people land on a category, hit two filters, and buy. They only reach for search when the filters have failed them.
Which makes it strange how often filters are treated as a theme feature rather than a data problem. They are almost entirely a data problem.
A filter is only as good as its attribute coverage
A colour filter listing eight colours is not useful if only sixty per cent of products have the colour field populated. The customer selects “navy,” gets nineteen results, and has no idea that another forty navy items exist with an empty field.
That is worse than having no filter at all, because the empty filter is honest and the incomplete one is confidently wrong. The customer concludes the store does not stock what they want and leaves.
So the first thing I measure before designing a filter set is coverage per attribute across the whole catalogue. Anything below about ninety-five per cent either gets fixed or does not ship. There is no third option that ends well.
Consistency beats completeness
The second failure is the same value written five ways. Navy, NAVY, Navy Blue, navy-blue, and Nvy will all appear as separate options in the filter list, and the customer will pick one and see a fifth of the products.
This is a data-cleaning job, not a front-end one, and it is exactly the work I describe in cleaning product data before it reaches the store. A controlled vocabulary — a fixed list of allowed values per attribute, enforced at import — is the only thing that holds over time. Without it, drift is guaranteed the first time somebody types a value by hand.
The controlled list should also be shorter than instinct suggests. Nobody filters by seventeen shades of blue. Group them into the handful of options people actually think in, and keep the precise shade in the product description where it belongs.
Choose filters per category, not per site
A global filter set is a compromise nobody asked for. Size means something different for trousers than for storage boxes, and neither of them cares about voltage.
Filters should be defined per department and inherited down. That means the attribute schema has to be planned by category before any of it is imported, which pushes the work back to field mapping — which is where it should be, because that is when it is cheap.
The practical shape is three to six filters per category page. Fewer than three and browsing does not narrow fast enough. More than six and the panel becomes a form, and people do not fill in forms to shop.
The two failure states nobody designs
- Zero results. Someone selected a valid combination that no product matches. A blank page reads as a broken site. Show what was selected, name the filter that eliminated everything, and offer to remove it.
- One result. Usually fine, occasionally a sign that the filter set is too granular for the size of the catalogue.
- Everything selected. If a filter never reduces the result count, it is decoration and should be removed.
Zero results is the one worth building properly. It is the moment a customer decides whether the store is thin or the filter was unlucky, and the difference is entirely in how the page explains itself.
Indexability, briefly but firmly
Filtered URLs multiply combinatorially, and left alone they will generate tens of thousands of near-identical pages for a search engine to crawl.
The default should be that filter combinations are not indexed. The exception is the small set of combinations that represent real demand — the ones people actually search for as a phrase. Those deserve to be proper landing pages with their own copy, not accidental filter URLs. Everything else gets excluded, and the crawl budget goes to the pages that matter.
What this is really about
Filters are the interface to the catalogue’s data quality. When they work, the store feels bigger and better stocked than it is, because customers can find the depth. When they do not, the store feels thin regardless of how much stock is sitting in the warehouse.
And the fix is almost never in the theme. It is in the attributes: are they populated, are they consistent, and were they planned per category before anything was imported. Those three questions decide whether the filter panel is a feature or a liability.
