Search that sells: why Elasticsearch is the only path forward for large-catalog e-commerce

43% посетителей интернет-магазинов используют поиск. Эти пользователи конвертируются в 2-3 раза чаще, чем те, кто просто листает каталог. Но большинство магазинов на Битрикс отдают этим пользователям сломанный поиск — и теряют самую «горячую» аудиторию. Разберёмся, почему так происходит и что с этим делать.

Проблема: нативный поиск Битрикс не масштабируется

Встроенный поиск 1С-Битрикс проектировался как вспомогательный инструмент, а не как ядро конверсии. На каталогах до 500-1000 позиций он работает приемлемо. Но когда SKU переваливает за 5 000, начинаются проблемы, которые невозможно решить настройками.

Типичная картина на среднем enterprise-магазине на Битрикс:

• Время поискового запроса: 500-900 мс. Пользователь ждёт почти секунду — и это до рендеринга результатов.
• Фасетная фильтрация: 1.5-3 секунды на каталогах от 10 000 SKU. При каждом клике на фильтр — новая пауза.
• Zero-result rate (ZRR): 15-25%. Каждый четвёртый-пятый запрос возвращает пустую страницу. Пользователь ищет «кроссовки найк» — получает ноль результатов, потому что в каталоге «Nike» латиницей.
• Нет обработки опечаток: «смартфн» вместо «смартфон» — ноль результатов.
• Нет синонимов: «ноутбук» и «лэптоп» — разные запросы с разной выдачей.
• Нет весов релевантности: товар с точным совпадением в названии показывается на одном уровне с товаром, где слово встречается в описании один раз.

Каждая из этих проблем — прямая потеря конверсии. В сумме они могут стоить 10-30% от потенциальной выручки поискового канала.

Почему оптимизация нативного поиска — тупик

Первый импульс: «давайте настроим то, что есть». Подключить морфологию, добавить индексы в базу данных, настроить кеширование. Это даёт эффект — но упирается в потолок.

Причина в архитектуре. Нативный поиск Битрикс работает через MySQL (или в лучшем случае через модуль поиска ядра). Это означает:

• SQL LIKE-запросы не поддерживают нечёткий поиск, релевантное ранжирование и работу с синонимами на уровне движка.
• Фасетная фильтрация при каждом запросе пересчитывает счётчики через JOIN-ы по нескольким таблицам. На 50 000 SKU с 20 свойствами — это десятки миллисекунд в лучшем случае, секунды — в типичном.
• Автокомплит требует отдельной реализации, которая будет конкурировать за ресурсы с основной базой данных.
• Аналитика поиска отсутствует — вы не знаете, что ищут пользователи, что не находят, и как поисковые запросы связаны с покупками.

Можно вложить 2-3 месяца в тонкую настройку — и получить улучшение на 20-30%. А можно за то же время выйти на принципиально другой уровень.

Решение: Elasticsearch через API — как это работает

Elasticsearch — специализированный поисковый движок, который изначально проектировался для полнотекстового поиска, фасетной фильтрации и аналитики. Вот как выглядит интеграция в связке с headless-фронтендом на Next.js.

Архитектура:

1. Синхронизация каталога: Битрикс остаётся мастер-системой. При изменении товара (цена, остатки, свойства) вебхук отправляет данные в Elasticsearch. Полная переиндексация — раз в сутки как страховка.
2. Поисковый API-эндпоинт: Отдельный сервис принимает поисковые запросы, обрабатывает их через Elasticsearch и возвращает результаты. Битрикс не участвует в обработке поисковых запросов вообще.
3. Next.js фронтенд: Мгновенная фильтрация, автокомплит, фасеты — всё рендерится на клиенте без перезагрузки страницы. Server-Side Rendering обеспечивает SEO.

Что это даёт в цифрах:

• Поисковый запрос: Битрикс — 500–900 мс, Elasticsearch — 80–150 мс
• Фасетная фильтрация: Битрикс — 1.5–3 с, Elasticsearch — 120–200 мс
• Автокомплит: Битрикс — нет / кастомный, Elasticsearch — 30–60 мс
• Обработка опечаток: Битрикс — нет, Elasticsearch — из коробки
• Синонимы: Битрикс — ручные редиректы, Elasticsearch — словари + ML
• Весовая релевантность: Битрикс — нет, Elasticsearch — настраиваемые boost-факторы
• Zero-result rate: Битрикс — 15–25%, Elasticsearch — 3–7%

Разница не в процентах — в разах. Поиск за 80 мс вместо 800 мс — это не «немного быстрее». Это принципиально другой UX, где фильтрация ощущается мгновенной.

Метрики, которые нужно измерять

Поиск — один из немногих каналов в e-commerce, где можно точно посчитать влияние на деньги. Вот ключевые метрики:

• Zero-result rate (ZRR): процент запросов, вернувших 0 результатов. Цель — ниже 5%. Каждый процент ZRR сверх этого — потерянные сессии.
• Search-to-conversion rate: доля поисковых сессий, закончившихся покупкой. На хорошем поиске — 8-15%, на сломанном — 2-4%.
• Search response time (p95): 95-й перцентиль времени ответа. Цель — ниже 200 мс. Всё, что выше 500 мс, снижает вовлечённость.
• Filter usage rate: как часто используют фильтры после поиска. Рост этой метрики после внедрения Elasticsearch — признак того, что фильтрация стала юзабельной.
• Autocomplete CTR: процент кликов по подсказкам. Хороший автокомплит снижает нагрузку на поиск и ускоряет путь к товару.

Без этих метрик вы не знаете, работает ли ваш поиск. С ними — видите прямую связь между качеством поиска и выручкой.

Внедрение: без big bang, поэтапно

Замена поиска — не проект на полгода. Правильный подход — инкрементальный:

Этап 1 — Каталожный поиск (2-3 недели). Индексируем каталог в Elasticsearch, подключаем поисковый эндпоинт, замеряем базовые метрики. На этом этапе уже видна разница в скорости и релевантности.

Этап 2 — Фасетная фильтрация (1-2 недели). Переносим фильтры на Elasticsearch: мгновенные счётчики, динамические фасеты, фильтрация без перезагрузки страницы.

Этап 3 — Автокомплит и подсказки (1 неделя). Поисковые подсказки по мере ввода, исправление опечаток, популярные запросы.

Этап 4 — Аналитика и оптимизация (постоянно). Сбор данных о запросах, A/B-тесты ранжирования, расширение словарей синонимов на основе реальных запросов пользователей.

На каждом этапе — измерение, сравнение с baseline, решение о следующем шаге. Откат возможен в любой момент.

Кому это нужно

Elasticsearch-интеграция оправдана, если:

• Каталог от 5 000 SKU (и растёт)
• Сложная структура категорий и свойств
• Пользователи активно используют поиск и фильтры
• Текущий zero-result rate выше 10%
• Время ответа поиска больше 300 мс
• Бизнес зависит от конверсии поискового трафика

Если у вас 200 SKU и простой каталог — нативного поиска достаточно. Но если каталог — ваш основной актив, поиск должен быть на уровне.

Следующий шаг

Начните с аудита поиска. Мы бесплатно замерим текущую производительность вашего поиска: время ответа, zero-result rate, качество релевантности. Вы получите конкретные цифры и понимание, сколько конверсий теряется прямо сейчас.

Продукт: https://webgoodpeople.com/ru/products/headless-next-elasticsearch