Filters aren’t configured in the theme. They’re configured in the free Search & Discovery app, and the theme’s job is to support the filtering API and render whatever the app exposes. Any current Online Store 2.0 theme does. Older third-party themes may only support tag filtering, in which case the theme has to be updated before any of this applies.
Knowing where the boundary sits saves a lot of misdirected development.
What you can filter by
Search & Discovery builds filters from these sources:
- Availability
- Price
- Product type
- Product tags
- Vendor
- Variant options — size, colour, whatever your options are
- Product and variant metafields
- Category attributes generated by the Standard Product Taxonomy
The last one is worth defaulting to. Assigning a product category generates standard attributes automatically, with values drawn from a controlled vocabulary. They make better filters than custom metafields because the values are consistent without anyone maintaining them.
The limits, precisely
These are the numbers that determine whether the native system will work for a given catalogue:
25 filters per store. That’s the total, combining the standard filters with everything custom. Each source can only be used once.
1,000 filter values per filter. Metafield filters may show fewer, because there’s a cap on how many metafields get checked for unique values.
AND across filters, OR within a filter. Selecting red and blue under Colour returns both. Selecting red under Colour and large under Size returns products that are red and large. This is not configurable.
Price filters work only in the store’s primary currency. A platform limitation, not a theme one. If you sell in multiple currencies, the price filter is approximate everywhere except home.
Tags can’t be translated. A tag-based filter works in one language. If the store is multilingual, tag filtering is a filter that half your customers can’t read. This alone is reason enough to move product attributes into metafields.
How filters appear in the URL
Filters are reflected as URL parameters, which matters for building links, preselected views, and analytics:
filter.p.tag=new,trending
filter.p.product_type=shoes
filter.p.vendor=vendor1
filter.p.m.custom.made_in=canada
filter.v.availability=1
filter.v.price.lte=5
filter.v.option.color=red
filter.v.m.custom.fabric=leatherp is product level, v is variant level, and m denotes a metafield followed by its namespace and key.
The practical use: you can link directly into a filtered view from navigation, campaigns, or content. That’s often a better answer than creating a collection, because it needs no maintenance and stays correct as the catalogue changes.
Product versus variant filters
The distinction is easy to miss and changes the result.
A variant filter links through to the matching variant — clicking a red swatch shows the red variant, not the product’s default. A product filter narrows the results but doesn’t select anything.
If the filter is a colour swatch, you almost certainly want variant-level. If it’s an attribute that describes the whole product — country of origin, collection year — product level is correct.
For visual swatches specifically: create a metaobject definition with both a colour field and an image field, reference it from a variant metafield, and enable storefront access on both the metaobject and the metafield definition. Providing both fields even if you only use one leaves the option open later. If products can have several filterable colours, define the metafield to allow a list of entries.
Where it stops
The native system is capable, and then it isn’t. The failure points are predictable:
Catalogues with deep attribute taxonomies. The 25-filter cap binds quickly once you’re generating category metafields across a varied catalogue. A fashion store with sleeve length, neckline, occasion, material, fit, and pattern is already spending six filters on one product type.
Relevance ranking. Search & Discovery gives you some control, but not the ranking logic a large catalogue eventually needs.
Faceted counts. Showing how many products sit behind each unselected filter value, and updating those counts as filters apply, is beyond the native system.
OR logic across different filters. Not available.
Very large collections. Filtering behaviour degrades on collections beyond a thousand products in ways that are inconsistent and awkward to debug.
What to do when you hit the ceiling
Three routes, in ascending order of cost:
Restructure before replacing. Most stores hitting the 25-filter limit are spending filters on attributes nobody uses. Pull the analytics on filter usage before assuming you need more. It’s common to find that four filters carry most of the interaction and the rest are noise.
Install a search and filtering app. The mature ones handle faceted counts, relevance tuning, and unlimited facets. You’re trading a monthly fee and some rendering control for capability.
Build it. The Storefront API and the filter Liquid API give you full control, and this is also the only route for headless. It’s the right answer for genuinely unusual merchandising models and the wrong answer for a catalogue that just needs thirty filters.
The thing to check first
Before any of this: look at how customers actually browse. Filter interaction data usually shows that a small number of filters carry nearly all the use, and that the ones merchandisers care about aren’t the ones customers touch.
More filters is rarely the fix. A shorter list, ordered by actual usage, usually outperforms a longer one — and it costs nothing but the decision.