Search that finds what shoppers actually mean:
filtered by what they actually care about

Why filtering needs a real search engine

Faceted search lets a shopper narrow a catalogue by the attributes that actually matter: size, price range, material, brand, rating. Each filter updates the others’ counts live, so a shopper never ends up on a dead-end combination with zero results.

The engineering behind this is a dedicated search engine, not a database query with a lot of WHERE clauses. Facet counting and typo-tolerant full-text search, at acceptable speed, need an index built for exactly that job.

On a real audit, we found a store where 81% of products sat outside any category. That meant search and filtering could not work, no matter how good the search box itself was, because there was nothing coherent to filter by. Fixing the catalogue structure came before any search technology could help.

When a flat grid stops being enough

You need real faceted search once your catalogue is large enough, usually past a hundred products, or varied enough in attributes. At that point, a flat grid or a basic dropdown filter genuinely frustrates shoppers. Zero-result searches are the clearest signal. If your analytics show shoppers searching for things your catalogue has, but search returns nothing, that is lost revenue with a known fix.

You do not need a dedicated search engine for a small catalogue. A simple category and attribute filter running directly against your database is faster to build, and perfectly adequate until the catalogue grows past what that approach handles well.

How the index gets built

We typically use Meilisearch for its speed and good-enough relevance out of the box. Elasticsearch comes in when the catalogue is large enough, or the relevance requirements complex enough, to need its deeper tuning options.

The index is built from your actual product data. Attributes get mapped to facets that reflect how your shoppers actually think about your catalogue, not a generic set of filters copied from another store’s template.

Sync runs near-real-time through webhooks when your platform supports them, or on a tight schedule otherwise. A price or stock change shows up in search results promptly. The filter UI itself is built mobile-first, since facet filtering on a small screen needs different interaction patterns than desktop, a bottom sheet instead of a sidebar. We design for that, rather than shrinking a desktop layout.

What search cannot fix by itself

Facets are only as good as the underlying product data. A search engine cannot filter by an attribute your catalogue never recorded. The real work is often cleaning up product data, before the search technology adds any value.

Relevance tuning also needs occasional attention as a catalogue grows. The default ranking that worked for two hundred products may not work for two thousand.

There is minimal lock-in. Both Meilisearch and Elasticsearch are open source, and the index can be rebuilt from your own product data if you ever switch providers.

Synonym handling is worth planning for in markets with regional spelling or brand-name variations. A shopper searching one common term should still find products tagged with its equivalent. We configure this during setup, rather than leaving it to be discovered through a string of zero-result searches your analytics later has to surface.

Price and timeline

Running cost is usually $10 to $40 a month in hosting for the search engine, separate from your main store infrastructure.

Related

This pairs with recommendation engine, since both are built on the same clean catalogue data. It also pairs with product feed management for ads, which depends on the same attribute structure. See the e-commerce service page for package details. For a real catalogue structure fix, see the multi-vendor marketplace platform case study.

Getting zero-result searches for products you actually sell? Get in touch and we will check your catalogue structure first.