How to set up filters and product attributes

Filters are the difference between a customer browsing your collection page and a customer finding a plant they actually want to buy. They're also one of the most under-invested features in plant shops — most resellers either skip filters entirely (forcing customers to scroll through 60 products) or bolt on a default filter set without thinking about what's underneath. The filter UI on the page is only the visible half. The real work is the data discipline that powers it.

Filters and attributes — two faces of the same data

Before anything else, understand the relationship: an attribute (sometimes called a property, spec, or metafield) is a piece of structured data on a product — light requirement, pot size, pet-safety. A filter is the UI that lets a customer narrow a collection page using those attributes.

This means filters and attributes are the same data, viewed from two ends:

• From the back-end (your perspective when you're building the catalog), it's an attribute on a product.

• From the front-end (the customer's perspective on a collection page), it's a filter checkbox.

Every filter you want to offer requires a clean, populated attribute on every product in scope. This is also why the filter discussion can't be separated from the spec discussion: see product specifications for the underlying spec template.

Starter set: 5–7 filters max

Most plant shops should ship with no more than 5–7 filters per collection page. Beyond that, customers stop scanning and start ignoring the filter panel. The starter set that works for almost any plant shop:

1. Care level (Easy / Medium / Advanced) — the single most-used filter. Customers self-identify their experience and want plants that match.

2. Light requirement (Bright direct / Bright indirect / Medium / Low) — second most-used. Driven by the room they're shopping for.

3. Pet-safe (Yes / No) — binary. High emotional weight; cat owners use it religiously.

4. Pot size (Ø in cm: 6, 9, 12, 17, 21, 24+) — driven by where the plant will go.

5. Plant height at delivery (Up to 30cm / 30–60cm / 60–100cm / 100cm+) — distinct from pot size; tells the customer how mature the plant arrives.

6. Price range (slider or buckets) — every shop, every collection.

7. Optional 7th: depends on collection. On Outdoor plants — Hardiness zone or Full sun / Shade. On Gifts — Occasion or Recipient. On Houseplants — Air-purifying.

Anything beyond that is filter clutter. Resist the urge to expose every attribute in your database — most attributes belong on the product page (specs), not in the filter panel.

When something is an attribute and when it's also a filter

A useful test for any candidate filter:

• Would a customer search for it? "Pet-friendly" — yes. "Wholesale code" — no. The first is a filter; the second is internal data.

• Are there 3+ products on each side of the filter? A filter that returns 1 product is broken. If "Pot size 6cm" only matches 2 products, that's a spec to display on the PDP, not a filter to expose.

• Is the data discrete and consistent? "Light: bright indirect" works as a filter (4 discrete buckets). "Daily water uptake in ml" doesn't (continuous, varies by season).

Concrete example for plant attributes that filter well:

• Light requirement (4 discrete buckets)

• Pet-safety (binary)

• Pot diameter (5–7 standard sizes)

• Care level (3 buckets)

• Mature height (4 buckets)

• Air-purifying (binary)

• Currently flowering (binary)

And attributes that don't filter well — these belong as specs on the PDP only:

• Latin species name (too granular, customer doesn't filter by it)

• Watering frequency in days (varies by season, not a stable filter value)

• Origin country (interesting, not a buying decision)

• Botanical family (relevant to enthusiasts, not to first-time buyers)

The empty-state problem

This is where filters fail in production. A customer applies three filters — "Pet-safe + Low light + Under €30" — and the page returns zero results. The standard treatment is a flat "No results found" message, which sends the customer to a competitor.

What to do instead:

• Suggest the closest match: "0 results for these filters. Try removing 'Under €30' to see 7 plants that match your other criteria."

• Identify the most-restrictive filter automatically and suggest relaxing it specifically. Most filter apps (Shopify Search & Discovery, WooCommerce filter plugins like FacetWP) support this with configuration.

• Show "alternative collections": "Browse all pet-safe plants" / "Browse low-light plants" — give the customer a doorway out, not a dead end.

This is one filter feature where the implementation effort is small and the conversion impact is large. Don't ship filters without an empty-state plan.

Single-select vs. multi-select

Per attribute, decide whether the customer can pick one value or multiple:

• Single-select for hierarchical or mutually-exclusive attributes. Care level: you're either a beginner or you're not. Pot size: you're shopping for one specific size.

• Multi-select for parallel options. Light: a customer with multiple rooms might want plants for "Bright indirect" AND "Medium". Pet-safe: usually binary, but if you split into Cat-safe and Dog-safe, allow both.

A reasonable default for a plant shop:

• Multi-select: Light, Pot size, Plant height, Care level

• Single-select: Pet-safe (binary), Price range

Data discipline — where filters live or die

The hardest part of filters isn't the UI — it's keeping the underlying attributes clean across hundreds of products. A few non-negotiable rules:

• Every product in scope must have a value for every filter attribute. If your "Pet-safe" filter applies to all houseplants, every houseplant needs Yes or No — not a missing value. Missing data quietly excludes products from filter results.

• Use the same value vocabulary across products. "Bright indirect" and "Indirect bright light" are the same thing to a human and different things to a filter. Standardise to one phrasing per spec, write it down as your internal taxonomy.

• Normalise units. Pot size sometimes arrives from suppliers in cm, sometimes in inches, sometimes as litre volume. Convert to a single unit (cm diameter) for filters. Show the source data in the spec table on the PDP if you want, but the filter value is normalised.

• Audit before each season. When you add new spring or autumn products, run a quick "missing attribute" report and fill the gaps before they go live. The Everspring catalog gives you the source data; the filter mapping is yours.

Where filters go on the page

A separate but related decision: where on the collection page does the filter UI live?

• Desktop: left sidebar is the default and works. Filters are persistent, customer can adjust without losing context.

• Desktop: top filter bar (above the grid) works for shops with 3–4 filters. Cleaner visually, less screen real estate, but breaks down once you add a 5th filter.

• Mobile: bottom-sheet drawer. Pinned bottom button "Filter (3)" opens a drawer over the grid. Don't try to inline filters above the grid on mobile — wastes scroll, customer can't see products while filtering.

Filters vs. on-site search

One last thing worth saying: filters and search overlap, but they're not the same tool. Filters narrow a collection page that the customer arrived at; search starts from a query. A customer who knows they want "Calathea Orbifolia" uses search. A customer who wants "a low-light plant for the bathroom" uses filters on the Houseplants collection. Both should work. Read how to set up your on-site search bar for the search side of this equation.

What to do tomorrow

Open your shop's filter settings (Shopify: Online Store → Navigation → Filters or via Search & Discovery; WooCommerce: native widget or FacetWP / WooCommerce Product Filter plugin). List every filter currently active. For each one, ask: does every product in this collection have a clean, normalised value for this attribute? If yes, keep it. If less than 95% coverage, either fill the data or remove the filter. Then check your starter set against the 5–7 above — add what's missing, drop what's never used (look at filter analytics if your platform exposes them). Finally, test the empty-state behaviour by deliberately picking a 0-result combination — if your shop returns a flat "No results found", configure a relaxation suggestion or fall back to a related collection. Then move on to on-site search, which catches the queries filters can't.