Storefront search is the most commercially loaded screen in an online store. A shopper who enters a query already knows what they want: their conversion rate is several times higher than that of someone browsing categories. If search returns no results because of a typo, misses products because of inconsistent wording, or shows irrelevant results, the store pays for it with direct lost orders. Below is an open breakdown of how retail solves this with Elasticsearch. This is not a KT.Team case study, but an overview of industry practices with links to primary sources.
Why Elasticsearch for catalog search
Elasticsearch is an open-source distributed search engine built on Apache Lucene. For e-commerce, it covers three tasks with one tool: full-text search with ranking, facet filtering through aggregations, and suggestions/autocomplete. Ranking is based on the BM25 algorithm - the same one used in Elasticsearch and Apache Solr - and it remains the standard for production search in e-commerce: it ranks products by how often query terms appear in the title, description, and attributes (oneuptime).
The key architectural choice is not to fork the store core for search. The mature approach is to run Elasticsearch as a separate service alongside the platform (Shopware, Magento, custom backend), sync the catalog into it, and keep search logic in that service. That lets search evolve and be handed to another team without rewriting the storefront - a typical case for a separate microservice instead of extending the monolith.
Facets: filters with counts that do not lie
Facet search lets users filter results by brand, price, rating, and attributes while showing the number of products next to each value. In Elasticsearch this is done with aggregations: `terms` for categorical fields (brand, category) and `range` for continuous ones (price) (oneuptime).
The main engineering subtlety is counts under multi-select. If you apply the filter with a regular `query`, it narrows both the results and the counts for all facets; a user who selects a brand will see price counts drop to zero. The correct setup is: `post_filter` applies the filter after aggregations are calculated, and each facet gets its own nested filter aggregation that takes into account all other facet filters except its own. That keeps all counts correct for any combination of selected values (oneuptime). The business result is direct: shoppers do not hit dead-end filters and do not abandon search.
Synonyms: one product, many words
Shoppers use different words for the same thing: "women's / female / for women", "phone / smartphone / mobile", "sneakers / trainers". Without synonym handling, part of the queries end up with empty results. Elasticsearch solves this with a synonym filter in the analyzer: the mapping list is applied at indexing or query time and merges variants into one meaning. Here the rule "read before you write" applies: instead of a hand-built dictionary, it is smarter to rely on ready-made industry thesauri and the engine's standard mechanisms, supplementing them with your own search analytics data (what people actually type and fail to find).
Typo correction: fuzzy and edit distance
Typos are a major cause of no results, especially on mobile. Elasticsearch supports fuzzy search based on Levenshtein distance (edit distance): "adidos" finds "adidas", "iphione" finds "iphone" (oneuptime). The `fuzziness` parameter sets the allowed number of edits; in practice it is combined with autocomplete via edge n-grams so suggestions appear from the first characters and reduce the chance of a typo itself. Every query that used to return zero results and now leads to a product is a saved order.
Ranking for business metrics
BM25 relevance is not enough for commerce: equally suitable products must be ranked with margin, availability, rating, and user behavior in mind. The basic technique is `function_score` with multiplicative boosting: final score = BM25 × (1 + cohort match × weight), which gently lifts the right products without breaking textual relevance (Elastic Search Labs).
The next level is Learning to Rank: a machine learning model reorders results according to selected metrics. The open Elasticsearch Learning to Rank plugin from OpenSource Connections is used in the search of Yelp, Wikipedia, and Snag. Snag reports the result after adopting LTR: "a net 32% conversion lift on historically worst-case scenarios" (OpenSource Connections). To keep tuning from being guesswork, relevance is measured: the Quepid tool (open source, works with Elasticsearch and Solr) tracks query test cases, manual judgments, and automatic NDCG calculation, proving that each configuration change actually improves results (OpenSource Connections).
Business Impact
Search quality translates directly into money. According to industry reports, enabled site search can increase conversion by up to 50%, and the HSE brand recorded an 8% increase in customer satisfaction after improving search accuracy on Elasticsearch (hyperflex). The numbers depend on the starting state of the storefront, but the direction is consistent: fewer zero-result pages, more accurate filters, more margin-rich items at the top, higher search conversion, and a higher average order value.
Business process takeaway
Catalog search stops being a "text field" and becomes a managed process: queries are logged, zero results and typos are analyzed, synonyms and boosts are maintained as a living dictionary, and every change is checked against a test set using NDCG. This cycle - measure relevance, adjust configuration, verify by metric, roll out - turns search from a one-time setup into a continuous driver of conversion and average order value, all built on open source without forking the store core.
