Search is the one interface every shopper touches, and the one most stores treat as a checkbox. On a multi-vendor marketplace it is not a checkbox — it is the store. What follows is the practitioner's checklist we run against our own search on a live catalogue of three thousand-plus products from six independent vendors who never agreed on how to name anything. Read the architecture overview for how the hybrid engine fits together; this piece is the field checklist that hangs off it, with a pointer to the deep dive for each item.
Why search earns the budget
A shopper who searches has told you exactly what they want. They convert at a far higher rate than one who browses, and they judge the entire store on the first five results. That asymmetry is why a ten-percent improvement in search quality is usually worth more than a homepage redesign: you are compounding on your highest-intent traffic. On a marketplace the stakes are higher still, because the catalogue is assembled from vendors with clashing vocabularies, and the search box is the only place those clashes get reconciled in front of the customer.
The mistake we see most often is treating search as a ranking problem to be solved once at launch. It is not a launch milestone; it is a weekly habit. The stores with good search are not the ones with the cleverest algorithm — they are the ones that read their failing queries every week and fix the top offender.
Speed is table stakes, not a differentiator. Sub-hundred-millisecond results are expected, and past that point latency stops winning shoppers — relevance is what they notice. Spend your effort where it is felt, on whether the right product appears, rather than shaving milliseconds off an already-fast query. The engines are fast; the data and the tuning are where stores actually differ.
The nine-point checklist
Here is the whole checklist in one place. Each row links to the article that goes deep.
| Capability | What good looks like | Deep dive |
|---|---|---|
| Typo tolerance | On for descriptions, off for identifiers | Typo-tolerant search |
| Synonyms | Curated cross-language plus generated per product | Search synonyms |
| Semantic recall | Vectors triggered selectively, not always on | Semantic search |
| Facets | Built from normalized, enriched attributes | Faceted navigation |
| Variant collapsing | One family, one result on page one | Product variants |
| Empty states | Honest "we don't carry this" with alternatives | Zero-results pages |
| Multilingual | Native fields per locale, not translations | Search synonyms |
| Index hygiene | Only sellable products indexed | Below |
| Measurement | The query-to-click join, reviewed weekly | Site search analytics |
Fix recall before you tune ranking
The first three rows are all one job: make sure the right product is in the candidate set at all. Ranking cannot promote a product it never retrieved. Recall failures come in three flavours, and each has a different tool. A misspelling — "creatne", "magnesim" — is a job for typo tolerance, which corrects within a small edit distance. A vocabulary mismatch — the shopper says "plant protein", your catalogue says "vegan" — is a job for synonyms. And an intent phrase — "something for sore muscles after training" — has no lexical overlap with any product name and is a job for the semantic layer.
The order matters. Cheap, deterministic tools first: get typo tolerance and synonyms right, because they are transparent and testable, before you reach for embeddings. Semantic search is powerful but it fails in ways that are hard to explain to a merchandiser, so it belongs at the end of the recall pipeline, not the start.
One caution on ordering trips teams up: do not solve recall by loosening ranking. Widening typo tolerance or lowering the relevance floor to rescue a handful of queries floods every other query with weak matches. Fix the specific recall gap with the specific tool — a synonym, an exception, a triggered vector search — and leave the global thresholds strict.
Shape the result set
Once the right products are retrieved, three decisions shape what the shopper actually sees. First, collapse variant families: a catalogue with eighteen flavours of one pre-workout should return one card, not eighteen near-duplicates that push every other product off page one. We do this with a distinct-on-parent rule and prefer an in-stock variant when we surface the family. Second, prefer in-stock: an exact match that is sold out is worse than a close match you can buy today. Third, offer facets — but only facets that are backed by real, normalized data. A "form: powder / capsules / liquid" filter is only trustworthy if that attribute means the same thing across every vendor, which is a data problem long before it is a UI one.
Your default sort is a decision, not a default. Relevance-first is right for a query, but a category browse with no query is better served by a considered order — popularity, margin, in-stock — than by whatever the index happens to return. And whatever the sort, keep it stable within a session: results that reshuffle between clicks make a store feel broken even when every individual ranking is defensible.
The honest edge cases
Two situations expose whether your search respects the customer. The first is the query for a brand you do not carry. A permissive engine will happily return look-alikes and pretend they are the answer; a better one detects the brand-not-carried case and says so, then offers real alternatives. The second is language. If you serve a small-language market, global platforms tune for English and your local customers can tell — native-language fields and a curated cross-language dictionary are a moat hiding in plain sight. Both cases are covered in the zero-results and synonyms pieces.
Index hygiene beats index size
A smaller index of sellable products outperforms a complete index of noise. Discontinued items, orphaned variants and products with no photo all dilute recall and erode trust when they surface. Our rule is to gate them at ingestion rather than filter them at query time, because a query-time filter is one more thing that can be forgotten on a code path.
We drop products with no image at ingestion — they never enter the index. A shopper who lands on a photoless result assumes the whole store is sloppy, and one bad result taints the fifty good ones around it. Hygiene at the door is cheaper than hygiene in the results.
Measure it weekly, or you are guessing
None of the above improves without instrumentation. The single most valuable thing you can build is a join between each search query and the click that followed it, keyed on a per-request id. That join separates ranking problems (position one skipped) from product problems (clicks but no cart) from catalogue gaps (nothing clicked at all). Add the zero-result rate on top, review both every week, and search stops being a matter of taste. The analytics piece has the full event schema, and the marketplace overview explains why search sits at the centre of the whole operation.
Key takeaways
- Search is the store on a marketplace — a ten-percent quality gain beats a homepage redesign because it compounds on your highest-intent traffic.
- Fix recall before ranking, and in order: typo tolerance for misspellings, synonyms for vocabulary, semantic search for intent.
- Collapse variant families and prefer in-stock so page one is diverse and buyable, not eighteen flavours of one product.
- Build facets from normalized attributes — a filter is only as honest as the data behind it.
- Gate junk at ingestion — imageless and discontinued products never belong in the index.
- Instrument the query-to-click join and review it weekly — measurement is what turns search tuning from taste into evidence.
Frequently asked questions
What are the most important ecommerce search best practices?
How do I improve my ecommerce site search?
Is site search worth investing in for a small store?
What is the difference between keyword and semantic search?
Search that finds things, out of the box.
The hybrid search in this checklist runs in production on the marketplace we operate and add to sites that already have traffic.
Request early access Try the live search →