Elasticsearch for ecommerce: it's about UX, not speed

We spent three weeks on Elasticsearch. Two of those weeks were infrastructure: mapping, shards, replication, Russian morphology analyzers. Everything worked.

Then we spent three days on relevance weights and facet behavior. Those three days moved conversion by 18%.

I kept thinking about that ratio. Two weeks building a fast search. Three days building a useful one. The useful part was worth more.

We ran on SQL LIKE for two years

The shop ran on Bitrix with 28,000 SKUs. Search worked through LIKE '%nike sneakers%' — standard out-of-the-box behavior.

The problems were predictable: "nike sneakers" returned results; "sneakers nike" returned nothing. Synonyms didn't exist. The first page of results showed the oldest articles because they had the lowest id. Filtering by multiple parameters at once crushed page load time.

We had Elasticsearch queued as a "search speed" task. That was the wrong framing. It was a conversion task.

Why teams adopt Elasticsearch — and miss the point

The typical conversation goes: "Our search is slow, we want Elasticsearch." Then after launch: "Search is faster, but users still can't find what they need."

Speed is the floor. Users don't notice the difference between 120ms and 40ms. What they notice: they typed "sneakers" with a typo and got nothing. The size filter shows 500 options, 480 of which are out of stock. Products on the first page rank by warehouse inventory count, not by what the user actually searched for.

Elasticsearch solves all of this. But none of these problems are infrastructure problems — they're UX problems.

Search UX isn't about design

Search UX is the logic behind what users see and how they narrow down results. Not the buttons. Not the color scheme.

Relevance determines which products show first and why. If someone searches "iPhone 13" and an accessory with "iPhone" in the description ranks above the phone itself, they leave. Facets determine which filters are available and in what order — a "Color" filter with 40 unsorted options is an anti-pattern, and a "Size" filter that doesn't reflect stock availability wastes everyone's time. Then there's zero results: what happens when there's no exact match. "Nothing found" is the worst outcome. Fuzzy suggestions with similar products at least give users somewhere to go.

All three are configurable in Elasticsearch. None of them are configurable in SQL.

The three days that moved conversion by 18%

Started with field boost. By default, Elasticsearch weights a keyword match in the product name, description, and attributes equally. We bumped name to 3.0, category_name to 2.0, and left description at 1.0. Products where the keyword is in the name immediately surfaced to the top.

Then synonyms and normalization. Added a synonyms file: "sneakers ↔ trainers", "nike ↔ NK". Applied the russian analyzer for morphological stemming. Users can now find "winter boots" by searching "boots winter."

Last — facets filtered by availability. The "Size" facet now only shows values where stock > 0. Before this, 60% of the facet values were unavailable: user clicked, got an empty page, left. This sounds obvious. It wasn't done during the original "search implementation."

Three changes. Three days. 18% lift in conversion by end of month, measured against the same pages in the prior period.

The search bar outperforms the homepage

Analytics from that same project: users who used the search bar converted at 2.3x the rate of users who navigated through category pages.

This isn't a one-off result. Industry data consistently shows that site searchers convert at 1.5–3x the rate of browsers. We see the same pattern across projects.

Investment in search pays back faster than a new homepage banner or a category menu redesign. Someone using the search bar already knows what they want. The question is whether you can give it to them.

When Elasticsearch is overkill — honestly

You don't need Elasticsearch if your catalog has fewer than 5,000 SKUs with clean structure and search usage in the single digits per day. Bitrix with properly configured indexes handles it. Overbuilding infrastructure is also technical debt.

You don't need it if your team isn't ready to maintain it. Elasticsearch requires ongoing content work: someone has to maintain the synonyms file, track zero-result queries, update boost weights for seasonality. Without that, it degrades over time.

You do need it when search is a conversion mechanism. When users search frequently, when the catalog is large and uneven, when you want to know what users are failing to find.

Takeaway

We spent three weeks building Elasticsearch as infrastructure. That work was necessary — without correct mapping and analyzers, nothing would function properly.

But conversion doesn't come from infrastructure. It comes from what the user sees: the right ranking, facets that reflect real availability, fallback behavior that recovers instead of dead-ending.

Elasticsearch gives you the tools. Using them is separate work — work that usually falls outside the scope of "search implementation."

That's why it's not a fast database. It's a UX tool for people who've already decided to buy and haven't found it yet.

*Related: Why I turned down a $40K rewrite contract — same logic: what actually moves the metric.*