Search That Sells: Elasticsearch for Big Catalogs

43% of online shoppers use search. These users convert 2 to 3 times more often than people who just browse the catalog. But most Bitrix stores hand them broken search, and lose their hottest audience. Let's look at why this happens and what to do about it.

The problem: native Bitrix search doesn't scale

The built-in 1C-Bitrix search was designed as a helper tool, not as the core of conversion. On catalogs up to 500-1000 items it works acceptably. But once your SKU count passes 5,000, you hit problems that no amount of configuration can solve.

Here's the typical picture on a mid-size enterprise Bitrix store:

• Search query time: 500-900 ms. The user waits almost a full second, and that's before the results even render.
• Faceted filtering: 1.5-3 seconds on catalogs of 10,000+ SKU. Every click on a filter brings a new pause.
• Zero-result rate (ZRR): 15-25%. Every fourth or fifth query returns an empty page. A user searches for "krossovki naik" and gets nothing, because the catalog stores "Nike" in Latin script.
• No typo handling: "smartfn" instead of "smartphone" returns zero results.
• No synonyms: "notebook" and "laptop" are different queries with different results.
• No relevance weighting: a product with an exact match in its title ranks at the same level as one where the word appears once in the description.

Each of these problems is a direct loss of conversion. Together they can cost 10-30% of the potential revenue from the search channel.

Why optimizing native search is a dead end

The first instinct: "let's tune what we already have." Plug in morphology, add database indexes, set up caching. It helps, but it hits a ceiling.

The reason is architecture. Native Bitrix search runs through MySQL (or, at best, through the kernel search module). That means:

• SQL LIKE queries don't support fuzzy search, relevance ranking, or synonym handling at the engine level.
• Faceted filtering recalculates counters through JOINs across several tables on every request. On 50,000 SKU with 20 properties, that's tens of milliseconds at best, seconds in a typical case.
• Autocomplete needs a separate implementation that competes for resources with the main database.
• Search analytics simply isn't there. You don't know what users search for, what they fail to find, or how search queries connect to purchases.

You can pour 2-3 months into fine-tuning and get a 20-30% improvement. Or you can spend the same time and reach a fundamentally different level.

The solution: Elasticsearch via API, and how it works

Elasticsearch is a dedicated search engine, designed from the start for full-text search, faceted filtering, and analytics. Here's what the integration looks like paired with a headless Next.js frontend.

The architecture:

1. Catalog sync: Bitrix stays the master system. When a product changes (price, stock, properties), a webhook pushes the data to Elasticsearch. A full reindex runs once a day as a safety net.
2. Search API endpoint: a separate service receives search queries, processes them through Elasticsearch, and returns results. Bitrix takes no part in handling search queries at all.
3. Next.js frontend: instant filtering, autocomplete, and facets all render on the client without a page reload. Server-side rendering keeps SEO intact.

What this gives you in numbers:

• Search query: Bitrix 500-900 ms, Elasticsearch 80-150 ms
• Faceted filtering: Bitrix 1.5-3 s, Elasticsearch 120-200 ms
• Autocomplete: Bitrix none or custom, Elasticsearch 30-60 ms
• Typo handling: Bitrix none, Elasticsearch out of the box
• Synonyms: Bitrix manual redirects, Elasticsearch dictionaries plus ML
• Relevance weighting: Bitrix none, Elasticsearch configurable boost factors
• Zero-result rate: Bitrix 15-25%, Elasticsearch 3-7%

The difference isn't measured in percentages, it's measured in multiples. Search in 80 ms instead of 800 ms isn't "a bit faster." It's a fundamentally different UX, where filtering feels instant.

The metrics you need to measure

Search is one of the few channels in e-commerce where you can measure the impact on money precisely. Here are the key metrics:

• Zero-result rate (ZRR): the share of queries that return 0 results. Target: below 5%. Every percentage point of ZRR above that is lost sessions.
• Search-to-conversion rate: the share of search sessions that end in a purchase. On good search it's 8-15%, on broken search 2-4%.
• Search response time (p95): the 95th percentile of response time. Target: below 200 ms. Anything above 500 ms cuts engagement.
• Filter usage rate: how often filters get used after a search. A rise in this metric after Elasticsearch goes live is a sign that filtering became usable.
• Autocomplete CTR: the share of clicks on suggestions. Good autocomplete reduces the load on search and shortens the path to the product.

Without these metrics, you don't know whether your search works. With them, you see the direct link between search quality and revenue.

Rollout: phased, no big bang

Replacing search isn't a six-month project. The right approach is incremental:

Phase 1, catalog search (2-3 weeks). We index the catalog into Elasticsearch, connect the search endpoint, and measure baseline metrics. The difference in speed and relevance is already visible at this stage.

Phase 2, faceted filtering (1-2 weeks). We move the filters onto Elasticsearch: instant counters, dynamic facets, filtering without a page reload.

Phase 3, autocomplete and suggestions (1 week). Search suggestions as you type, typo correction, popular queries.

Phase 4, analytics and optimization (ongoing). Collecting query data, A/B testing the ranking, expanding synonym dictionaries based on real user queries.

At every phase: measure, compare against baseline, decide on the next step. You can roll back at any moment.

Who needs this

An Elasticsearch integration is justified if:

• Your catalog is 5,000+ SKU (and growing)
• You have a complex structure of categories and properties
• Users actively use search and filters
• Your current zero-result rate is above 10%
• Search response time is over 300 ms
• The business depends on conversion from search traffic

If you have 200 SKU and a simple catalog, native search is enough. But if the catalog is your main asset, search has to be up to the job.

The next step

Start with a search audit. We'll measure your current search performance for free: response time, zero-result rate, relevance quality. You'll get concrete numbers and a clear sense of how many conversions you're losing right now.

Product: Headless Next.js + Elasticsearch