Разработка модуля поиска для каталога 1С-Битрикс

Когда каталог превышает 5 000 позиций, штатный поиск Битрикс на основе b_search_content перестаёт справляться: товары не находятся по опечаткам, транслитерации, синонимам?

На одном проекте с 30 000 товаров доля нулевых результатов составляла 15% — после внедрения кастомного модуля на PostgreSQL FTS она упала до 1.2%. Один из клиентов терял более 200 000 ₽ в месяц из-за того, что пользователи не находили нужные товары; после внедрения модуля доход вырос на 12%. Наша разработка модуля поиска по каталогу 1С-Битрикс включает нечёткий поиск, синонимы и транслитерацию — всё, что нужно для быстрого и релевантного поиска. Компания TrueTech — 5+ лет на рынке, 150+ проектов, сертифицированные специалисты 1С-Битрикс. Гарантируем стабильную работу и поддержку после запуска. Снижение отказов на 15% экономит клиенту до 300 000 ₽ в месяц на рекламе. Закажите консультацию — мы проанализируем ваш каталог и предложим оптимальное решение. Свяжитесь с нами, чтобы получить бесплатный аудит текущего поиска.

Почему штатный поиск не подходит для каталога?

Штатный поиск (search.php и модуль search) строит полнотекстовый индекс b_search_content. Он работает для контентных сайтов, но не справляется с каталогом: не поддерживает транслитерацию («iphone 12» → «айфон 12»), синонимы, числовые диапазоны («наушники до 3000 рублей»). Как только каталог превышает 10 000 позиций, поиск становится медленным и нерелевантным. Дополнительная проблема — отсутствие нормализации запросов: пользователи вводят «айфон» и не находят iPhone.

Как разработать модуль поиска по каталогу 1С-Битрикс?

Варианты реализации

Прежде чем писать собственный индекс, стоит честно рассмотреть готовые решения:

Мы проектируем модуль с абстрактным слоем поискового движка, чтобы переключать бэкенд без переработки логики Битрикс.

Архитектура модуля

Индексатор. Агент раз в час проверяет изменения в b_iblock_element (по полю TIMESTAMP_X) и обновляет поисковый индекс. При сохранении товара через события OnAfterIBlockElementUpdate индекс обновляется немедленно для этого элемента. Индекс содержит поля: название, описание, характеристики (значения свойств), артикул, бренд, категория, цена (для фильтрации по диапазону), наличие. Числовые поля хранятся отдельно для range-запросов.

class SearchIndexer { public function indexElement(int $elementId): void { $element = $this->loadElementWithProps($elementId); $document = [ 'id' => $elementId, 'title' => $element['NAME'], 'description' => strip_tags($element['DETAIL_TEXT']), 'sku' => $element['PROPERTY_ARTICLE_VALUE'], 'price' => $this->getMinPrice($elementId), 'in_stock' => $this->isInStock($elementId), 'brand' => $element['PROPERTY_BRAND_VALUE'], 'tsvector' => null, ]; SearchIndexTable::merge($document); } } 

Поисковый запрос. Пользовательская строка нормализуется: транслитерация (iphone → айфон и обратно), исправление раскладки клавиатуры (руьщт → iphone), удаление стоп-слов. После нормализации — запрос к индексу с ранжированием по ts_rank. Словарь синонимов хранится в таблице myvendor_search_synonyms, перед поиском запрос проверяется на совпадение.

Как работает нечёткий поиск?

Самая частая причина нулевых результатов — опечатки. Решение — расстояние Дамерау-Левенштейна для коротких запросов и pg_trgm для PostgreSQL (подробнее о full-text search).

-- Индекс триграм для нечёткого поиска CREATE INDEX idx_search_title_trgm ON myvendor_search_index USING gin(title gin_trgm_ops); -- Нечёткий поиск с порогом схожести SELECT id, title, similarity(title, 'айфно') AS sim FROM myvendor_search_index WHERE title % 'айфно' ORDER BY sim DESC LIMIT 20; 

Расширение pg_trgm позволяет искать по схожести с порогом (0.3), что эффективнее предвычисленных исправлений. В одном из проектов с каталогом 40 000 товаров внедрение нечёткого поиска снизило долю нулевых результатов с 12% до 0.8%, а средняя позиция найденного товара переместилась с 5-й на 2-ю.

Что входит в разработку модуля поиска?

Саджест (автодополнение)

AJAX-эндпоинт возвращает подсказки по первым 2+ символам запроса. Подсказки берутся из предрассчитанной таблицы популярных запросов (myvendor_search_popular, обновляется из лога запросов раз в сутки) и из индекса по LIKE 'запрос%' с лимитом 5. Ответ кешируется в Memcached/Redis с TTL 1 час.

Как проходит разработка модуля поиска?

1. Аудит текущего поиска и сбор лога запросов.
2. Выбор поискового бэкенда (PostgreSQL, Elasticsearch или Sphinx).
3. Разработка индексатора и движка поиска.
4. Интеграция с сайтом (компонент, AJAX-роутинг).
5. Настройка сервера и создание индексов.
6. Тестирование и обучение сотрудников.
7. Документация и передача исходного кода.
8. Поддержка в течение 1 месяца после релиза.

Что входит в работу

• Документация — техническое задание, описание архитектуры, инструкции по развертыванию и обновлению.
• Исходный код — полный код модуля с комментариями, без обфускации, размещается в репозитории.
• Обучение — 2-часовая онлайн-сессия для администраторов и разработчиков заказчика.
• Деплой — настройка поискового бэкенда и перенос файлов на боевой сервер, настройка агентов кэширования.
• Поддержка — 1 месяц бесплатного сопровождения после запуска (исправление критических ошибок).

Сроки разработки

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

Детальную информацию о поисковых механизмах можно найти в официальной документации 1С-Битрикс.