{"id":8762,"date":"2026-08-11T02:21:10","date_gmt":"2026-08-11T02:21:10","guid":{"rendered":"https:\/\/dextora.agency\/insights\/category-pages-and-filters-where-buyers-are-lost\/"},"modified":"2026-08-11T02:21:10","modified_gmt":"2026-08-11T02:21:10","slug":"category-pages-and-filters-where-buyers-are-lost","status":"publish","type":"insight","link":"https:\/\/dextora.agency\/en\/insights\/category-pages-and-filters-where-buyers-are-lost\/","title":{"rendered":"Category Pages and Filters: Where Stores Lose Buyers Before the Product"},"content":{"rendered":"

Category pages get less attention than the product pages they lead to and the checkout they feed, which is odd, because most shopping sessions spend more time on them than on either. They are also where a specific and expensive failure happens: a visitor who wanted something you stock leaves without ever seeing it, because the path from a hundred products to the right three was harder than closing the tab.<\/p>\n

Baymard’s product list and filtering benchmark, built from more than twenty-one thousand manually scored parameters across 170-plus leading retailers, rates 58% of desktop and 78% of mobile implementations<\/a> as mediocre or worse. The mobile figure is the one worth sitting with, since that is where most of the traffic is.<\/p>\n

Filters fail in a small number of predictable ways<\/h2>\n

Filtering is not a hard problem technically. It fails for design reasons, and the same handful repeat across catalogues.<\/p>\n\n\n\n\n\n\n\n\n\n\n
Failure<\/th>\nWhat the shopper experiences<\/th>\nFix<\/th>\n<\/tr>\n<\/thead>\n
Generic facets everywhere<\/td>\n“Sleeve length” offered on a page of shoes<\/td>\nCategory-specific facet sets, defined per branch of the tree<\/td>\n<\/tr>\n
No result counts<\/td>\nSelecting a filter that leads to an empty page<\/td>\nShow the count next to each value, and disable zeroes<\/td>\n<\/tr>\n
Applied filters invisible<\/td>\nConfusion about why so few products are showing<\/td>\nPersistent chips with individual removal<\/td>\n<\/tr>\n
Filters buried on mobile<\/td>\nScrolling past forty products to find the controls<\/td>\nA sticky filter button that stays reachable<\/td>\n<\/tr>\n
Full page reload per selection<\/td>\nLosing scroll position on every click<\/td>\nUpdate in place, preserve position and history<\/td>\n<\/tr>\n
Sorting confused with filtering<\/td>\nSorting by price and expecting the range to narrow<\/td>\nSeparate the two visually and label them plainly<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
\n

Result counts are the highest-value item on that list and the most frequently skipped. They convert filtering from a guessing game into a navigation aid: a shopper who can see that “waterproof” leaves four products and “water-resistant” leaves forty makes a different and better-informed choice, and does not hit a dead end.<\/p>\n<\/div>\n

Desktop and mobile want different patterns<\/h2>\n

The instinct to build one filtering interaction and use it everywhere is the source of much of the mobile gap in the benchmark.<\/p>\n

On desktop, filters sitting in a persistent left column and applying immediately is the pattern that tests best. The results are visible while the controls are being used, so cause and effect are obvious and no confirmation step is needed.<\/p>\n

On mobile, the same immediacy is disorienting. The filter panel covers the results, so applying instantly means changing something the shopper cannot see. The pattern that works is a panel with an explicit apply button that states the outcome \u2014 “Show 24 results” \u2014 so the shopper knows what they are getting before the panel closes. The count on that button does most of the work.<\/p>\n

The combination that returns nothing<\/h2>\n

Filters create empty result sets far more often than search does, because shoppers combine constraints without knowing the inventory. A dead end here is a self-inflicted loss: the visitor was engaged enough to specify exactly what they wanted.<\/p>\n

Three things make it survivable. Prevent the impossible combination where you can, by disabling values that would return nothing. When it happens anyway, say which constraint caused it rather than showing a generic empty page. And offer the nearest available set by relaxing the least important filter, with the relaxation stated explicitly rather than performed silently, because a shopper who cannot tell that their size filter was dropped will assume the results are wrong.<\/p>\n

This mirrors the zero-results problem in search, and the same discipline applies to both, which is covered from the query side in what customers type into site search<\/a>.<\/p>\n

How to decide which facets a category gets<\/h2>\n

Facet sets are usually inherited from whatever the platform generated out of product attributes, which is why shoe pages offer sleeve length. Deciding them deliberately takes an afternoon per category branch and draws on three sources you already have.<\/p>\n

    \n
  1. The search log.<\/strong> Attributes people type into the search box are attributes they want to filter by. If “waterproof” and “size 43” appear repeatedly as queries, they belong in the filter panel of that category, not only in the index.<\/li>\n
  2. Support questions before purchase.<\/strong> Every pre-sale question about a property is a filter that would have answered itself. These are already logged somewhere, usually in a helpdesk nobody exports.<\/li>\n
  3. Return reasons.<\/strong> Returns caused by the wrong attribute point at a decision the shopper could not make on the site. Compatibility and dimensions dominate this list in most catalogues.<\/li>\n<\/ol>\n

    Then cut. A panel with fifteen facets is a panel nobody reads; four to seven, ordered by how often they are used rather than alphabetically, covers the great majority of real refinement. Attributes that matter to only a handful of products belong on those product pages, not in a filter that is empty for everything else.<\/p>\n

    Navigation is half of this problem<\/h2>\n

    Filtering only starts once the shopper reaches the right category, and a surprising share of category page failures are actually menu failures. Two patterns cause most of them.<\/p>\n

    The first is a menu built around internal structure rather than customer language: departments named after supplier divisions, or a hierarchy that mirrors the warehouse. The second is a mega menu so large that it becomes its own findability problem, particularly on mobile, where a three-level accordion is a worse tool than a search box.<\/p>\n

    The practical test costs nothing: give five people outside the company a product to find and watch where they go first. If they open search instead of the menu, the menu is not doing its job, and no amount of filtering work below it will compensate.<\/p>\n

    The SEO problem hiding underneath<\/h2>\n

    Faceted navigation generates URLs. A catalogue with six facets and a handful of values each can produce tens of thousands of crawlable combinations, most of them near-duplicates of one another, and all of them competing for the crawl attention your actual category pages need.<\/p>\n

    The decision is not technical but editorial: which filtered views are pages worth having, and which are states of a page. A useful rule is that a combination deserves indexing only if people search for it as a concept and it has enough inventory to be a satisfying landing page. “Waterproof hiking boots” usually qualifies. “Waterproof hiking boots, size 43, blue, sorted by price descending” never does.<\/p>\n

    Implementation follows from that decision: indexable combinations get static, readable URLs, a distinct title and a paragraph of their own copy. Everything else stays out of the index and out of the sitemap, and the sitemap should reflect what you decided rather than what the system can generate. The mechanics of checking this sit inside the twenty-point technical checklist<\/a>.<\/p>\n

    A category page is also a landing page<\/h2>\n

    For most retailers, category pages attract more search traffic than the homepage, and a visitor arriving from a search engine needs slightly different treatment from one who navigated internally.<\/p>\n

    Three additions handle it without turning the page into an article. A short paragraph above or below the grid that says what the category contains and who it suits, written for a person rather than for a keyword count. The most useful filters surfaced as links rather than buried in a panel, so the common refinements are one click away and crawlable. And guidance where the choice is genuinely hard, such as a sizing note or a two-sentence explanation of the difference between two adjacent product types.<\/p>\n

    What to put in the grid, and how much of it<\/h2>\n