Most category pages do not lose sales because the products are wrong. They lose sales because shoppers cannot narrow 1,200 items down to the 6 they actually want. That is a product filter design problem, and it is almost always fixable with layout rules rather than a full redesign.
This guide breaks down how to build a filter sidebar that works: which control to use for each attribute type, how to structure groups, how to display applied filters and result counts, and how the whole thing should change when it collapses into a mobile bottom sheet. Every rule below is concrete enough to hand to a designer or a front-end developer today.
What a Filter Sidebar Actually Has to Do
Before choosing components, agree on the three jobs your filter panel performs. Every layout decision should serve one of them:
- Reveal what is filterable. If a shopper cannot see that you support filtering by inseam, fit or fabric, that filter does not exist to them.
- Make selection cheap. The cost of applying a filter should be one tap or click, with instant visible feedback.
- Make reversal cheap. Shoppers explore by trial and error. Removing a filter must be as fast as adding one, and the back button must behave.
A sidebar that nails visibility but hides the “remove” action creates dead ends. A sidebar with beautiful chips that require a full page reload creates hesitation. Good product filter design balances all three.
Choosing the Right Filter Control
The single most common mistake is using one control type for everything. Attribute data has shape, and the control should match that shape.
Decision table: control by attribute type
| Attribute type | Recommended control | Why | Example |
|---|---|---|---|
| Multi-select list, 3 to 12 values | Checkboxes with counts | Scannable, allows OR logic, shows all options at once | Brand, category, fit |
| Multi-select list, 13+ values | Checkboxes + inline search + “show more” | Search beats scrolling once a list passes one screen height | Brand on a marketplace |
| Mutually exclusive choice | Radio buttons or a segmented toggle | Signals that only one value can apply | Gender, delivery speed |
| Short values, visual scanning | Chips or pills in a wrap grid | Dense, tap-friendly, good for uniform-length labels | Size, shoe size, sleeve length |
| Color | Swatch grid with label on hover and a text alternative | Color is recognised faster visually than by name | Apparel color families |
| Continuous numeric range | Dual-handle slider plus two editable number inputs | Slider for exploration, inputs for precision | Price |
| Numeric range with natural buckets | Predefined range checkboxes | Faster than dragging when shoppers think in tiers | Under 50, 50 to 100, 100 to 200 |
| Ordinal threshold | Stacked “X and up” options | Shoppers filter by minimum, not by exact value | Customer rating |
| Binary flag | Single switch or standalone checkbox | One-line group, no header needed | In stock only, on sale |
When sliders are the wrong choice
Price sliders look premium and test badly more often than teams expect. Use them only when all of the following are true:
- The price distribution is wide and roughly continuous, not clustered around three price points
- You can render a histogram behind the track so shoppers see where inventory sits
- You also expose min and max text inputs for keyboard and screen reader users
- The slider does not re-query the catalogue on every pixel of drag, only on release
If any of those fail, bucketed checkboxes will outperform. On mobile, a slider handle sitting under a thumb hides the value it is setting, so the numeric readout must appear above the track, never below it.
When chips beat checkboxes
Chips are compact and inherently tappable, but they lose to checkboxes when labels are long or uneven. The practical rule:
- Use chips when labels are under roughly 8 characters and you can fit 3 or 4 per row without ragged wrapping (sizes, numbers, short codes).
- Use checkboxes when labels vary in length or need a count suffix (“Water resistant (24)”).
- Never mix both patterns within the same visual column unless the difference carries meaning.
When to collapse a group
Accordions save vertical space and cost a click. Apply this hierarchy:
- Always expanded: the top 3 groups by usage, typically category, size and price for apparel.
- Expanded by default, truncated to 6 items: mid-usage groups with a “Show all (18)” link.
- Collapsed by default: long tail attributes such as material, care instructions, technical specs.
- Always expanded regardless of position: any group that currently has an active selection. A collapsed group hiding an applied filter is the number one source of “why are there no results” confusion.
Desktop Sidebar: Concrete Layout Rules
The left-hand vertical sidebar remains the default for desktop because it supports persistent visibility and simultaneous scanning of results. Horizontal filter bars work for catalogues with fewer than 5 facets, but they force dropdowns and hide the option landscape.
Measurements that work
- Width: 240px to 280px. Below 220px, labels with counts wrap. Above 300px you steal a product column.
- Position: left side, above the fold, aligned to the top of the first product row.
- Sticky behaviour: make the sidebar sticky with its own internal scroll once the page scrolls past the header. Long catalogues make non-sticky sidebars useless after two scrolls.
- Group spacing: 24px between groups, 12px between options, 8px between a checkbox and its label. Increase the click target to the full row width, not just the box.
- Row height: minimum 36px on desktop for comfortable clicking.
- Group headers: 14px to 15px, semibold, with the chevron on the far right and the entire header row clickable.
Ordering the groups
Order by usage data, not by database schema. If you have no data yet, this default order works for most catalogues:
- Sub-category or product type
- Size or the primary fit attribute
- Price
- Color
- Brand
- Rating
- Everything else, alphabetical or by count
Within a group, sort options by result count descending for brands and long lists, but by natural order for anything ordinal (XS to XXL, 36 to 46). Alphabetical sorting of sizes is a classic and avoidable bug.
Apply instantly or use an apply button?
On desktop, apply instantly. The results grid is visible next to the sidebar, so feedback is immediate and the mental model is direct manipulation. Requirements to make it work:
- Update results in under 400ms, ideally with a skeleton or dimmed grid rather than a spinner that shifts layout
- Keep scroll position, never jump the user back to the top of the page
- Debounce multi-clicks so selecting three brands in a row does not fire three full queries
- Update the URL with each change so the state is shareable and the back button steps through history
Mobile: The Bottom Sheet Pattern
On mobile there is no room for a persistent sidebar, and the old “full screen filter page” approach severs the connection between filters and results. In 2026 the dominant and best-performing pattern is the bottom sheet, a panel that slides up over the results and can be dragged between heights.
The entry point
- Use a sticky bottom bar or a sticky top bar containing “Filter” and “Sort” as two distinct controls. Merging them into one button hides sorting.
- Show the active filter count in a badge: “Filter (3)”. This is the cheapest state signal you can build.
- Keep the trigger visible during scroll. Shoppers decide to refine after seeing a few bad results, not before.
Sheet structure
Two layouts work. Choose based on facet count:
| Layout | Best for | How it works |
|---|---|---|
| Stacked accordion sheet | Up to about 8 facets | One scrollable column of collapsible groups, all in a single sheet |
| Two-level drill-down | 9+ facets or very long option lists | Level 1 lists facet names with current selections as subtitles, tapping pushes a second panel |
| Single-facet quick sheet | Horizontal chip bar above the grid | Tapping a chip like “Size” opens a short sheet with only that facet |
The third option is worth combining with either of the first two. A horizontal scrolling row of the top 3 or 4 facets above the grid gives one-tap access to the filters that matter most, while the full sheet stays available behind the “All filters” button.
Mobile layout rules
- Snap points: open at roughly 60% to 75% of viewport height so a strip of results stays visible behind the sheet. Allow a drag to full height.
- Handle: include a drag handle at the top plus a visible close X. Do not rely on swipe alone.
- Tap targets: 48px minimum row height, 44px minimum for chips and swatches, 8px minimum gap between adjacent targets.
- Sticky footer: a fixed action bar inside the sheet containing “Clear all” on the left and a primary button on the right that reads “Show 84 results”, updating live.
- Safe area: add bottom padding for home indicators so the apply button is never half covered.
- No horizontal scroll inside the sheet body, except for a deliberate chip carousel.
Apply button on mobile: yes
Unlike desktop, mobile shoppers cannot see the grid change behind a sheet covering 70% of the screen. Use a live-updating count on the primary button so selections still feel responsive, then commit on tap. Two acceptable variants:
- Deferred apply: nothing changes behind the sheet until the shopper taps “Show 84 results”. Simplest to build, easiest to understand.
- Live apply with a close button: results update behind the sheet, the button reads “Show 84 results” and simply dismisses. Works well only if the sheet opens at 60% so the change is partly visible.
Desktop vs Mobile: Side by Side
| Decision | Desktop sidebar | Mobile bottom sheet |
|---|---|---|
| Visibility | Always visible, sticky | Hidden behind a sticky trigger with a count badge |
| Application timing | Instant on each change | Deferred, committed by an apply button |
| Groups open by default | Top 3 to 5 expanded | All collapsed, or drill-down list |
| Options shown per group | 6 to 8, then “show more” | All, inside a scrollable panel |
| Minimum target height | 36px | 48px |
| Applied filter display | Chip row above the grid plus checked states in the sidebar | Chip row above the grid plus count badge on the trigger |
| Price control | Slider with histogram and number inputs | Bucketed checkboxes, or slider with value above the track |
| Clear all | Top of sidebar and end of chip row | Left side of the sticky sheet footer |
Applied Filter States: The Part Teams Skip
Selection feedback is where average product filter design falls apart. A shopper who cannot tell what is currently applied will not trust the results and will restart from the category page.
The four required signals
- In-control state. The checkbox is checked, the chip is filled, the swatch has a ring. High contrast, not a subtle tint.
- Group-level summary. Each collapsed group header shows what is inside it: “Color (2)” or, better, “Color: Black, Navy”.
- Global chip row. A horizontal row of removable chips sitting directly above the product grid, one per applied value, each with an X. End the row with “Clear all”.
- Result count in context. “84 results” placed next to the chip row, updating with every change.
Chip row rules
- Label chips with the value, prefixed by the facet only when ambiguous: “Black” is fine, “36” should read “Size 36”.
- Keep chip order stable. Newly applied filters append to the end so nothing jumps around.
- Show “Clear all” only from the second applied filter onward.
- On mobile, let the chip row scroll horizontally with a partial chip visible at the edge so the overflow is discoverable.
- Removing a chip must never collapse the corresponding sidebar group or reset unrelated facets.
URL and history
Every applied filter state should live in the URL as query parameters. This gives you shareable links, working back buttons, restorable state after a product detail visit, and clean analytics. Return the shopper to the exact scroll position and filter set when they hit back from a product page. Losing filter state on back navigation is one of the most expensive bugs in ecommerce.
Result Counts: Show Them, But Do It Right
Counts next to each option answer the question “is this worth clicking” before the click happens. They also prevent dead ends.
Rules for counts
- Show the count for every option in list-style facets, formatted as a muted number in parentheses.
- Recalculate counts against the currently applied filters, not against the whole catalogue. Static counts are worse than no counts.
- Options with zero results: disable and grey them out rather than hiding them. Hiding causes options to disappear mid-interaction, which feels broken. Exception: if more than half a long list would be disabled, hide them and offer a “Show unavailable” toggle.
- Never disable an option that is currently selected.
- Skip counts on color swatches and small size chips where they create visual noise. Use a strikethrough or reduced opacity for unavailable values instead.
- Multi-select within one group is usually OR logic, so selecting “Black” should not zero out “Navy” in the same group. Counts across groups use AND logic. Make sure your recalculation reflects that or your numbers will look wrong.
Handling zero results
When a combination returns nothing, do not show an empty grid with a shrug. Build a recovery state:
- State plainly: “No results for your current filters.”
- Show the applied filter chips again, right there in the empty state, so removal is one tap.
- Suggest the single filter whose removal returns the most products: “Remove Under 50 to see 62 items.”
- Offer “Clear all filters” as a secondary action.
- Fall back to related products or the parent category below the message.
Accessibility Requirements
Filters are highly interactive, which makes them easy to get wrong for keyboard and screen reader users.
- Use native
input type="checkbox"andinput type="radio"wherever possible, styled rather than replaced by divs. - Wrap each group in a
fieldsetwith alegend, or userole="group"witharia-labelledby. - Accordion headers should be
buttonelements witharia-expandedandaria-controls. - Announce result changes through an
aria-live="polite"region: “84 results”. - Sliders need
role="slider", arrow key support, and the paired number inputs mentioned earlier. - Bottom sheets need focus trapping, focus returned to the trigger on close, and Escape to dismiss.
- Never signal availability by color alone. Pair the grey-out with strikethrough text or a “(0)” count.
- Visible focus rings on every interactive element, including swatches.
Technical and SEO Considerations
Faceted navigation can generate an enormous number of URL combinations. Left unmanaged, it dilutes crawl budget and creates near-duplicate pages.
- Decide which filter combinations deserve indexable pages. Typically these are high-demand combinations such as category plus color or category plus brand.
- Give indexable combinations clean, static-looking URLs with unique titles, H1s and intro copy.
- Apply
noindex, followor canonical tags to low-value combinations such as multi-select price plus rating plus availability. - Keep sort order and pagination out of the indexation plan entirely.
- Render filter option links as real anchors where possible so crawlers can discover the valuable variants.
- Watch performance: facet count recalculation on every interaction can be expensive. Cache aggregations and return counts alongside results in a single response.
Common Product Filter Design Mistakes
| Mistake | Fix |
|---|---|
| Every group collapsed on desktop | Expand the top 3 to 5, keep any group with an active selection open |
| Filters reset when returning from a product page | Store state in the URL and restore scroll position |
| Page jumps to the top after each selection | Update the grid in place, preserve scroll |
| Filter and Sort merged into one control | Split into two buttons in the mobile sticky bar |
| Sizes sorted alphabetically | Sort ordinal values by natural order, always |
| Counts calculated against the full catalogue | Recalculate against currently applied filters |
| Applied filters only visible inside a closed panel | Add a removable chip row above the grid |
| Too many facets, many with a single value | Hide any facet where one option covers the entire result set |
Pre-Launch QA Checklist
- Applying, removing and clearing filters all work without a full page reload
- Result count updates within 400ms and is announced to assistive tech
- Back button steps through filter history correctly
- Deep-linked filtered URL renders the correct checked states
- Zero-result state offers at least one specific recovery action
- Every group with an applied filter is expanded on load
- Mobile sheet apply button is above the safe area on notched devices
- Keyboard-only user can reach, toggle and clear every filter
- Facet counts respect OR logic within groups and AND logic across groups
- Filter usage is tracked per facet so you can reorder groups with real data
How to Prioritise Your Own Improvements
If you cannot ship everything, ship in this order. The sequence is deliberate: each step reduces the largest remaining source of friction.
- Applied filter chips above the grid with a working X on each
- Live result counts on the mobile apply button
- Per-option counts recalculated against active filters
- Filter state persisted in the URL and restored on back navigation
- Group ordering driven by your own usage analytics
- Slider replaced by buckets, or the reverse, based on an A/B test
FAQ
Should filters be on the left or the top of the page?
Left sidebar for catalogues with more than 5 facets, because it shows option labels without extra clicks and supports vertical scanning next to the grid. A horizontal top bar is acceptable for small catalogues, and it pairs well with a mobile-style chip row, but it hides options inside dropdowns.
How many filters should a category page have?
Enough to narrow the catalogue meaningfully, rarely more than 8 to 10 visible groups. Drop any facet where one value covers nearly all products, and merge near-duplicate attributes. Quality of facets beats quantity every time.
Should selecting a filter update results instantly or require an apply button?
Instantly on desktop where the grid is visible, deferred behind an apply button on mobile where the sheet covers the results. Put the live count on the apply button so the shopper still gets feedback before committing. The piece 1043 ‘Filtering Options’ Design Examples makes a good next read.
Should out-of-stock or zero-result options be hidden or greyed out?
Grey them out and disable them in most cases, since disappearing options make the interface feel unstable. Hide them only when a long list would become mostly unusable, and then offer a toggle to reveal unavailable values.
What is the ideal width for a desktop filter sidebar?
240px to 280px. That range fits typical labels with counts on one line while leaving room for a 3 or 4 column product grid on standard laptop widths.
Do product filters hurt SEO?
Only when left unmanaged. Choose a small set of high-demand filter combinations to make indexable with unique content, and use canonical tags or noindex on the rest so crawl budget goes to pages that can actually rank. logrocket.com makes the same point with more data.
Are bottom sheets better than full-screen mobile filter pages?
Generally yes. A bottom sheet keeps part of the results visible, preserves context, and can be dismissed with a drag. Full-screen pages break the connection between the filters and the products they affect, which increases abandonment during refinement.
Final Word
Strong product filter design is not about a novel component. It is about matching the control to the data, keeping the applied state visible at all times, showing honest counts, and adapting the layout to the constraints of each device rather than shrinking a desktop sidebar into a phone. Fix the chip row, the counts and the URL state first. Those three changes typically deliver more than any visual refresh.