Search that finds what shoppers actually mean:
filtered by what they actually care about
A catalogue past a few dozen products needs real search and faceted filtering, or shoppers either scroll through everything or leave, because a flat product grid with no way to narrow by the attribute they actually care about is not browsing, it is guessing.
What it is
Faceted search lets a shopper narrow a catalogue by the attributes that actually matter for what they are buying, size, price range, material, brand, rating, with each filter updating 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, because 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, which meant search and filtering were structurally broken 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 you need it (and when you do not)
You need real faceted search once your catalogue is large enough, usually somewhere past a hundred products, or varied enough in attributes, that a flat grid or a basic dropdown filter genuinely frustrates shoppers trying to narrow down to what they want. 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 we build it (stack, components, integrations)
We typically use Meilisearch for its speed and good-enough relevance out of the box, or Elasticsearch 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 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 either near-real-time through webhooks when your platform supports them, or on a tight schedule otherwise, so 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, a bottom sheet instead of a sidebar, than desktop, and we design for that rather than shrinking a desktop layout.
What to watch (risks, cost of ownership, vendor lock-in)
Facets are only as good as the underlying product data; a search engine cannot filter by an attribute your catalogue never recorded, so the real work is often cleaning up product data before the search technology adds value. Relevance tuning also needs occasional attention as a catalogue grows, since the default ranking that worked for two hundred products may not for two thousand. There is minimal lock-in since 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, since 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
| Option | Price | What it covers | Timeline |
|---|---|---|---|
| Search on clean catalogue | from $3,500 | Search engine, facets, filter UI | 3 to 4 weeks |
| Search with catalogue cleanup | from $6,000 | Product data restructuring plus search build | 5 to 7 weeks |
| Multi-language search | from $8,500 | Facets and relevance tuned across languages | 6 to 8 weeks |
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, and 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 D2C store Thailand audit and rebuild case study and 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.
FAQ
How much does faceted search cost?
From $3,500 for search and filters on an existing catalogue with clean product data. $6,000 to $10,000 is typical when the catalogue needs restructuring first or facets need to span multiple languages.
How long does it take?
3 to 7 weeks depending on catalogue size and how much the product data needs cleaning before it can power good facets.
What is the stack?
Meilisearch or Elasticsearch as the search engine, synced from your store's product data on a schedule or in near-real-time depending on how often your catalogue changes, with a Next.js or theme-embedded filter UI on top.
Who owns the search index and its data?
You. The search engine runs on infrastructure in your name, built from your own catalogue data, not a third-party search-as-a-service subscription you would lose access to if you stopped paying.
Who maintains it after launch?
The sync and indexing run unattended. Facet definitions and relevance tuning benefit from occasional review as your catalogue grows; we offer a support plan for that.