Category and search pages: the funnel nobody audits
Category and search pages decide whether a customer ever reaches a product page, and most stores never measure them. The three failures are almost always the same: search that only matches product titles, filters built from attributes nobody shops by, and a zero-results page that ends the visit. Fixing those is cheaper than redesigning anything.
Conversion work concentrates on two pages: the product page and the checkout. Between them sits the part of the store where a customer decides whether your catalogue contains what they came for, and it is audited about a tenth as often.
Why this part of the funnel gets skipped
Category and search pages fall between two owners. Design treats them as templates, merchandising treats them as a listing, and neither treats them as a conversion surface with its own failure modes.
The result is predictable. In the audits we run, stores can usually quote their checkout abandonment rate to a decimal place and cannot say what proportion of site searches return nothing at all. One of those numbers is being worked on. The other is often larger and entirely unexamined.
Search users are the audience you are ignoring
Customers who use site search have told you exactly what they want. In every store where we have compared the two groups, searchers convert at a higher rate than browsers — which is unsurprising, because a search is an intent statement, and it makes the neglect harder to justify.
Three failures account for most of the loss.
Matching only product titles. A customer searching “waterproof jacket” finds nothing when your products are named “Storm Shell II” and the word waterproof lives in the description. Indexing descriptions, attributes, category names and tags fixes this in an afternoon on most platforms.
No tolerance for how people type. Plurals, hyphens, misspellings and word order. “mens boots”, “men’s boots” and “boots mens” are one query to a customer and three to a naïve index.
Ranking by whatever the database returned. Results in database order are not results. Ranking should reflect availability, popularity and relevance, and a product that is out of stock should not be the first thing a searcher sees.
The zero-results page is the most expensive page you own
Nothing in a store wastes higher-intent traffic than an empty result set with no way forward. The visitor arrived, told you what they wanted, and received a blank grid.
A zero-results page that works does four things: states plainly that nothing matched, keeps the query visible so it can be corrected, offers the nearest alternatives under a looser rule, and provides a route to a person. That is a small amount of work protecting your most motivated visitors.
Worth saying explicitly: if a customer searches for something you genuinely do not sell, the honest answer is to say so rather than to present unrelated products. A shopper who is told plainly is more likely to come back than one who is shown a grid of things they did not ask for.
Filters: build from questions, not from your database
Most filter sets are assembled from whatever attributes the catalogue happens to hold. That is backwards. The right source is what customers ask about — the search log, the emails, the questions your support inbox answers repeatedly.
A useful test: for each filter, name the customer sentence it answers. “Filter by material” answers “does this come in leather?” and earns its place. “Filter by SKU prefix” answers nothing anybody has ever asked.
Every filter costs something. Vertical space on mobile, cognitive load on everyone, and a URL combination that may be crawled and indexed. Fewer filters that map to real questions beat a complete reflection of your product data.
Faceted navigation and the URL explosion
Filters generate URLs. Four filters with five options each generate over six hundred combinations, most of which contain the same products in a different order, and a crawler will find them.
Google’s guidance on faceted navigation is the primary source worth reading before designing filters. The practical rules we apply:
- Decide which filter combinations deserve to be indexable pages, and treat only those as real URLs
- Keep everything else out of the index rather than hoping it will be ignored
- Never let filtering create pages that differ only in sort order
- Make the indexable ones genuinely useful — “waterproof walking boots” is a page worth having; “waterproof walking boots sorted by price descending” is not
Get this wrong and a store with two hundred products presents a crawler with fifty thousand near-identical pages. That is the same thin-content problem that a badly built location system creates, arriving through a different door.
Pagination that works for people and crawlers
Real paginated URLs, each linkable and each reachable without JavaScript. Products on page four should be findable by something that does not scroll.
Infinite scroll is not forbidden, but it should be layered on top of paginated URLs rather than replacing them — the pattern Google documents for incremental loading. Replacing pagination entirely breaks the back button, strands the footer permanently out of reach, and hides the deeper catalogue.
The audit we run, in order
Six checks, cheapest first. Most stores find something in the first two.
| # | Check | What you are looking for |
|---|---|---|
| 1 | Search log, two weeks | Zero-result rate and no-click rate |
| 2 | Search five real product descriptions | Whether the index covers more than titles |
| 3 | Zero-results page | Query preserved, alternatives offered, route to a person |
| 4 | Every filter | The customer question each one answers |
| 5 | Filter URLs | How many combinations exist, and how many are indexable |
| 6 | Category page on a phone | How far you scroll before reaching a product |
Check six catches the failure that surprises people most. On mobile, a category page carrying a banner, a description, a filter bar and a sort control can push the first product entirely below the fold, which means the page is doing everything except showing the catalogue.
Accessibility is not a separate pass
Filters and search are interactive controls, which makes them the part of a category page most likely to fail an accessibility check. Three things go wrong repeatedly and all three are covered by WCAG 2.2: filters implemented as clickable divs that a keyboard cannot reach, result counts that update without announcing anything to a screen reader, and a live region that announces every keystroke rather than the settled result.
Fixing them is not a favour to a minority of users. A filter that works with a keyboard also works with a phone in one hand on a train.
What we would change first
Given one week on a typical store, in this order: index descriptions and attributes as well as titles, then fix the zero-results page, then remove every filter nobody uses.
None of that is a redesign. All of it is cheaper than one, and in our experience it moves more revenue than the redesign it replaces — because the customers it helps had already decided to buy something.
