Search and filters in an online store: helping customers find the right product

As long as a catalog has fifty products, customers look at all of them. From a few hundred on, something else starts happening: someone who doesn't quickly find what they're looking for doesn't ask for help, they leave. Search and filters aren't a decoration for the store: they're what keeps a large catalog usable for someone who doesn't already know it.

The starting point isn't technical. It's understanding which criteria the customer uses to choose, which are almost never the same ones the company uses to organize the warehouse.

The customer's criteria aren't the catalog's criteria

A catalog is organized around how things are purchased, stocked, and invoiced: vendor, product family, internal code. A customer chooses based on how they'll use the item: what problem it needs to solve, what it needs to be compatible with, how long it needs to last, how much they can spend.

The fastest way to find this out is to listen to whoever answers the phone and reread the requests you've received. The questions customers ask before buying are the list of filters, already written. If the recurring question is "will this work for my model?", compatibility is the first filter, not a secondary attribute.

• The three questions you receive most often before a purchase.
• The reasons a product gets returned: behind them there's almost always a selection criterion that wasn't visible.
• The words customers use to name things, which rarely match the ones on the price list.

Before filters comes data cleanup

A filter only works if the attribute is filled in for every product, and always the same way. It's tedious work, and the website can't do it for you.

• Consistent units of measurement: if one product is expressed in millimeters and another in centimeters, a selection range makes no sense.
• Closed values instead of free text: "stainless steel," "stainless," and the technical code, entered by hand, become three different filters for the same material.
• Synonyms handled by search: the customer searches for the word they know, not the one in the catalog.
• Required attributes per category: if compatibility is a filter, a product without compatibility filled in is invisible to anyone filtering.

A filter prototype: spare parts

An illustrative example: a store selling spare parts for industrial machines. The order of the filters matters as much as the filters themselves, because the first one needs to be the one that rules out the most wrong products.

Two details make the difference in a case like this. Next to every value, show how many products remain, so the customer doesn't head down paths that lead to zero. And the selected machine, if the customer repeats it on every visit, should be remembered: it's their permanent condition, not an occasional filter.

No results: the screen that decides whether the customer stays

It's the most important page and the least cared for. "No products match your criteria" is a dead end. Whoever gets there has just declared what they want to buy: they're the most interested visitor you have at that moment.

1. Say which criterion emptied the list and let the customer remove it with a single action.
2. Show the closest results, explaining how they differ from the request.
3. Leave a human way out: an availability request or a contact option, with the selection already carried over into the message.

It's worth keeping the list of searches that come up empty. It's the most honest record of the relationship between what you sell and what's being asked of you: it tells you which products are missing, which words you don't recognize, and which attributes are poorly filled in.

Internal search and paths to the product

Search serves someone who already knows the name of what they want; filters serve someone who still has to decide. They're two different tools, not two versions of the same one.

• Search needs to tolerate typos, plurals, and synonyms, and it should also search item codes.
• Suggestions while typing are useful if they lead to the product, not to a new list to filter from scratch.
• After a search, the customer needs to be able to filter the results: without this step, a broad search produces a list as long as the whole catalog.

The shortest path to the right product doesn't always go through filters. In technical catalogs, pages built around a specific question — a machine model, a type of work, an application — also work well, since they already gather the relevant products and spare the customer the selection process.

What this guide doesn't cover

This guide covers how the customer finds the product once they're already in the store. How to organize categories, product pages, and filter pages so they're also found by search engines — and which filter combinations are better off not turned into standalone pages — is a related but separate topic, with its own rules. Preparing data and images for importing a catalog also has its own dedicated guide.