A catalog is only useful if people can find the right product. That sounds obvious until a store contains hundreds or thousands of products.

In its April 2026 review of more than 170 ecommerce sites and apps, Baymard found that 56% inadequately support users’ search needs. The same research says roughly half of participants turn to search as their preferred product-finding strategy, with the other half using main navigation. That is a pattern in usability testing, not a real-world usage share. For large catalogs, product discovery is not a secondary UX feature. It is part of the commerce engine.

At a glance

  • Search quality starts with structured product data, not with the search box.
  • B2B search is reference-driven: SKU, model, dimensions and compatibility must match exactly.
  • Filters should follow purchase criteria, not every database field.
  • Zero-result searches are a signal about your catalog, not just your search engine.

Search starts with product data

Search quality cannot be fixed entirely in the search interface. If a customer searches for “brown leather belt 35mm” and the database contains only a title and a generic description, the search engine has almost nothing to work with.

A structured record might instead contain product type, material, colour, width, length, brand, SKU, reference, collection and compatibility. Search improves because the data improves.

B2B search is even more reference-driven

Professional buyers usually know what they need. They search by SKU, manufacturer reference, EAN or GTIN, part number, model, specification or dimension. An exact search should be genuinely exact.

Baymard’s search research highlights exact product and model searches as a query type ecommerce search must support well. For B2B stores, getting the reference right can matter more than sophisticated visual discovery — the catalog context is described in B2B ecommerce.

Autocomplete should reduce effort

Autocomplete helps before the results page. Useful suggestions include products, categories, brands, recent searches and popular matching terms. But it should clarify rather than overwhelm. Typing “leath…” could suggest leather belts, leather wallets and leather bags, with product suggestions underneath. The objective is to narrow intent quickly.

Search results need enough information to decide what to open

A product listing is not merely an image grid. Its job is to support comparison. Depending on the catalog, each item may need name, image, price, variant indication, availability, key attributes, reference, quantity unit and badges that genuinely matter.

Too little information forces users to open every product; too much destroys scanability. The result card is essentially a compact version of the product page decision.

Filtering should follow purchase criteria

Filters should represent how people choose, not every field in the database:

Catalog type Typical filters
Fashion Size, colour, material, fit
Industrial Diameter, material, compatibility, voltage
Food supply Format, weight, pack size, allergen

The correct filter taxonomy comes from product and buying logic.

Do not confuse categories and filters

A category is a durable grouping; a filter refines it. “Leather belts” is a category; colour, width, size and price are filters. When every filter becomes a category, navigation explodes. When every category becomes a filter, important commercial landing pages disappear. The SEO consequences are covered in ecommerce SEO for large catalogs.

Applied filters must remain understandable

Once multiple filters are active, customers need to know what they changed. Make the current state clear — which filters are applied, the active values and an obvious way to clear them — and test whether people can recover from an over-filtered result set.

Mobile filtering is a separate design problem

Desktop gives filters persistent space; mobile does not. A mobile implementation must make three things obvious: that filters exist, that filters are active and that filters can be removed. The user should never wonder why only four products remain. If updating results blocks input or freezes the page, investigate the interaction cost described in Core Web Vitals for ecommerce.

The no-results page is part of search

A dead end such as “no products found” wastes the user’s intent. A better no-results state preserves the query, offers a spelling correction, removes overly restrictive filters, suggests related categories and exposes contact for specialist B2B requests. It should never pretend an unrelated product matches the request.

Search analytics reveal catalog problems

Track more than usage: searches per session, zero-result searches, search exits, query refinement, result click-through, search-to-order conversion and top internal queries.

Zero-result terms are especially useful. They reveal missing synonyms, missing attributes, missing products, bad naming, poor indexing and real market demand. Search becomes a feedback loop for product data.

Search should fail gracefully

A strong search handles an exact query, a broad product query, a brand query, an attribute query, a SKU, an abbreviation, a minor typo and a synonym. But avoid using semantic search to work around poor product data. Semantic search cannot reliably reconstruct attributes that were never stored.

The real product discovery stack

Good discovery is the combination of product data, taxonomy, search logic, filters, listing UX, analytics and crawl control. Optimising only the search box is not enough. The strongest systems start further back — with the structure of the catalog itself.

Continue reading

Product discovery sits in the Commerce work at FRN.Q.