Поиск по сайту в 1С-Битрикс: релевантность, морфология и Sphinx

Покупатель, который открыл строку поиска, — это самый «горячий» посетитель магазина. Он не листает каталог из любопытства, а прямо говорит, что хочет купить: пишет название, модель, артикул или просто «чёрные ботинки 42 размер». И если в ответ он получает пустую страницу, нерелевантную кашу или «ничего не найдено» из-за одной опечатки, он уходит — чаще всего к конкуренту, где поиск работает. Поэтому поиск по сайту в 1С-Битрикс — это не второстепенная деталь витрины, а один из главных каналов, по которому магазин теряет или зарабатывает деньги.

В этой статье разберём поиск без общих слов: как устроен штатный модуль «Поиск», как индексируются инфоблоки и контент, зачем нужна морфология русского языка и стоп-слова, как работают синонимы, релевантность и обработка опечаток, как показать поисковые подсказки в шапке, чем поиск отличается от умного фильтра, когда штатного движка перестаёт хватать и в игру вступает Sphinx или ElasticSearch, и как аналитика запросов помогает поднять конверсию. Материал — выжимка из наших проектов по разработке сайтов с умным поиском на 1С-Битрикс, где поиск почти всегда оказывается точкой роста продаж.

Зачем магазину хороший поиск

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

Хороший поиск делает три вещи. Он понимает запрос, написанный живым языком, с опечатками, в любой словоформе и любым синонимом. Он находит релевантные товары, даже если в карточке они названы иначе, чем в голове у покупателя. И он ранжирует выдачу так, чтобы самое нужное было сверху. Если хотя бы одно из трёх работает плохо, посетитель либо не найдёт товар, который есть на складе, либо утонет в нерелевантной выдаче.

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

Модуль «Поиск» в 1С-Битрикс

За поиск по сайту в 1С-Битрикс отвечает штатный модуль «Поиск» (search). Это полноценная подсистема, которая умеет индексировать содержимое сайта, разбирать русскую и английскую морфологию, работать со стоп-словами и синонимами, ранжировать результаты и отдавать выдачу компонентам. Для большинства магазинов среднего размера этого модуля достаточно, чтобы поиск работал хорошо, — при условии, что его правильно настроили.

Ключевая идея модуля в том, что он строит собственный поисковый индекс — отдельную структуру, оптимизированную под быстрый текстовый поиск. Поиск идёт не по таблицам инфоблоков напрямую, а по этому индексу. Такой подход даёт скорость (не нужно на каждый запрос перебирать сотни тысяч товаров) и гибкость (в индекс можно включать разные типы контента), но взамен требует, чтобы индекс поддерживался в актуальном состоянии.

Модуль «Поиск» индексирует не только товары. В его область попадают инфоблоки (товары, разделы, статьи блога, новости), а при желании — форумы, разделы сайта, статические страницы. Благодаря этому один и тот же поиск может искать и по каталогу, и по контентной части сайта, отдавая покупателю смешанную выдачу «товары + статьи + разделы».

Индексация контента и инфоблоков

Всё качество поиска начинается с индексации. Если товара нет в поисковом индексе, поиск его не найдёт — каким бы умным ни был разбор запроса. Поэтому первое, что настраивают, — это область индексации и режим обновления индекса.

Что попадает в индекс

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

Когда обновляется индекс

Индекс наполняется двумя путями. Первый — индексация «на лету»: при сохранении элемента (в админке или обменом) он тут же попадает в индекс. Второй — переиндексация по расписанию через агент или крон: система периодически проходит по контенту и обновляет индекс. На боевом магазине обычно используют оба режима, но с оговоркой: массовый обмен с 1С лучше сопровождать отдельной переиндексацией, потому что индексация на лету при загрузке десятков тысяч позиций сильно нагружает сайт.

Отдельно стоит следить за тем, чтобы процесс переиндексации не «зависал». На больших каталогах полная переиндексация — тяжёлая операция, и если она обрывается на середине, часть товаров остаётся вне индекса. В таких случаях переиндексацию запускают порциями, в часы низкой нагрузки, и контролируют её завершение. Это одна из причин, по которой на очень крупных магазинах переходят на внешний поисковый движок — о нём ниже.

Как работает поиск: от запроса к выдаче

Чтобы настраивать поиск осознанно, полезно представлять весь путь запроса — от того момента, как покупатель нажал Enter, до того, как на экране появилась выдача. Этот путь одинаков и для штатного модуля, и для внешнего движка, меняются только детали каждого шага.

1. Разбор запроса. Строку «купить телефоны samsung» система разбивает на слова, убирает стоп-слова, приводит каждое слово к начальной форме (морфология) и подмешивает синонимы.
2. Поиск по индексу. По разобранным словам система находит в поисковом индексе все элементы, где эти слова (или их синонимы) встречаются.
3. Ранжирование. Найденные элементы сортируются по релевантности: где слово встречается в названии, где — только в описании, насколько полно совпал запрос.
4. Формирование выдачи. Компонент search.page получает отранжированный список, подгружает данные товаров (цену, картинку, наличие) и рисует страницу результатов.

Из этой схемы видно, где чаще всего ломается поиск. Если товара нет в индексе — не поможет никакой разбор запроса. Если морфология выключена — «телефоны» не найдут «телефон». Если нет синонимов — «сотовый» не найдёт «смартфон». Если плохо настроено ранжирование — нужный товар окажется на пятой странице. Дальше разберём каждый из этих узлов по отдельности.

Морфология русского языка и стоп-слова

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

Что делает морфология

Морфология приводит каждое слово к начальной форме — лемме. И запрос, и содержимое индекса нормализуются к одной форме, поэтому «купить красные кроссовки» находит карточку «Кроссовки красный», хотя буквально ни одно слово не совпадает по написанию. В 1С-Битрикс поддержка морфологии русского и английского языков входит в модуль «Поиск» — её нужно только включить и убедиться, что она применяется и к запросу, и к индексируемому тексту.

Стоп-слова

Стоп-слова — это высокочастотные служебные слова: предлоги, союзы, частицы («и», «в», «на», «для», «с», «по»). Они встречаются почти в каждом тексте и не несут смысла для поиска, поэтому их исключают из индекса и из разбора запроса. Это даёт два эффекта: индекс становится компактнее, а релевантность — чище, потому что совпадение по слову «для» не поднимает нерелевантный товар наверх. Список стоп-слов в Битриксе настраивается — при желании его дополняют словами, специфичными для конкретного магазина.

Синонимы и словарь замен

Морфология решает проблему словоформ, но не решает проблему разных слов для одного понятия. Покупатель пишет «сотовый», а в карточке — «смартфон». Пишет «холодильник no frost», а в свойствах — «система разморозки». Пишет «кеды», а товар назван «кроссовки». Для этого нужен словарь синонимов — таблица соответствий, по которой поиск подмешивает к запросу связанные слова.

Синонимы бывают нескольких видов, и их полезно различать при настройке:

• Языковые синонимы. «Телефон» = «смартфон» = «сотовый». Одно и то же понятие разными словами.
• Профессиональный и бытовой словарь. «Перфоратор» и «отбойник», «ноутбук» и «лэптоп». Клиент называет товар не так, как каталог.
• Латиница и кириллица. «Samsung» и «Самсунг», «iPhone» и «айфон». Бренды пишут и так, и так.
• Опечаточные и сленговые формы. «Зарядка» вместо «зарядное устройство», «флешка» вместо «USB-накопитель».

Словарь синонимов наполняют не «из головы», а на основе реальных поисковых запросов. Из аналитики видно, какими словами покупатели ищут товары, — и если по частому запросу выдача пустая, а товар есть, значит нужен синоним. Это прямая связка между аналитикой запросов (о ней ниже) и качеством поиска: словарь синонимов должен жить и пополняться, а не оставаться пустым после запуска.

Релевантность и ранжирование

Найти все подходящие товары — половина дела. Вторая половина — расположить их в правильном порядке, чтобы самое нужное было сверху. Этим занимается ранжирование по релевантности. Покупатель редко идёт дальше первого экрана выдачи, поэтому то, что оказалось на первых позициях, фактически и есть результат поиска.

Релевантность в поиске 1С-Битрикс складывается из нескольких сигналов. Условно их можно разделить на текстовые (насколько хорошо запрос совпал с текстом элемента) и бизнесовые (насколько этот товар важен для магазина).

• Где встретилось слово. Совпадение в названии товара весит больше, чем совпадение в глубине описания. Это самый важный текстовый сигнал.
• Полнота совпадения. Товар, где нашлись все слова запроса, релевантнее того, где совпало одно слово из трёх.
• Бизнес-приоритеты. Товары в наличии разумно поднимать выше распроданных; популярные и маржинальные позиции можно приоритизировать.
• Ручное закрепление. Под важные запросы («новинка», акционный товар) выдачу иногда «пинят» вручную — закрепляют нужный товар на первом месте.

Важное правило: не стоит смешивать в поисковую выдачу распроданные товары наравне с доступными. Если человек ищет товар, находит его первым в списке, заходит — а там «нет в наличии», это разочарование и потерянный заказ. Наличие — один из ключевых сигналов ранжирования именно в магазине, а не в контентном поиске.

Опечатки и «вы искали»

Люди печатают с ошибками — особенно на мобильных, где легко промахнуться по клавише. «Кросовки», «телвизор», «самсунг галакси» — если поиск воспринимает такие запросы буквально, он выдаёт пустоту, хотя товар есть на складе. Хороший поиск должен прощать опечатки.

Есть два механизма борьбы с опечатками, и они дополняют друг друга:

• Исправление «вы искали». Поиск определяет, что запрос похож на известное слово из индекса, и предлагает исправленный вариант: «Возможно, вы искали: кроссовки». Покупатель одним кликом переходит к правильной выдаче.
• Нечёткий поиск (fuzzy). Поиск сразу ищет с допуском на несколько отличающихся символов, находя товары, несмотря на опечатку. Это особенно хорошо умеют внешние движки вроде ElasticSearch.

Штатный модуль «Поиск» умеет предлагать исправления и подсказывать варианты на основе своего индекса и словарей. Для более агрессивной обработки опечаток (когда ошибок много и они разные) часто подключают внешний движок, где нечёткий поиск реализован из коробки и настраивается тонко — вплоть до количества допустимых различий в слове.

Поисковые подсказки в шапке

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

За такие поисковые подсказки в 1С-Битрикс отвечает компонент search.title (в ряде сборок используется его расширенная версия, известная как search.title.ball). По мере ввода символов компонент подгружает совпадения из того же поискового индекса и рисует их выпадающим блоком. Настраивают в нём несколько вещей: с какого символа начинать подсказывать, сколько результатов показывать, какие типы контента подмешивать (товары, разделы, статьи) и выводить ли у товаров картинку, цену и наличие.

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

Компоненты search.page и search.title

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

• bitrix:search.page — страница результатов поиска. Принимает запрос, обращается к поисковому индексу, получает отранжированный список и выводит его постранично. Здесь настраивают, по каким модулям искать, сколько результатов на странице, как подсвечивать совпадения, показывать ли форму «вы искали». Часто шаблон search.page дорабатывают, чтобы выдача для товаров выглядела как плитка каталога — с картинкой, ценой, кнопкой «В корзину», а не как сухой список ссылок.
• bitrix:search.title — «умная» строка поиска с выпадающими подсказками. Работает по мере ввода, показывает мгновенные результаты. Вставляется в шаблон шапки рядом с полем ввода.

На практике оба компонента настраивают согласованно: одинаковая область поиска, одинаковая логика показа наличия и цены, единый визуальный стиль. Тогда покупатель видит связный опыт: то, что мелькнуло в подсказке, он находит и на полной странице результатов.

Отдельная задача — доработка шаблона выдачи под магазин. Стандартный шаблон search.page изначально «контентный»: он рассчитан на список ссылок со сниппетами. Для интернет-магазина его переделывают так, чтобы товарные результаты выводились карточками с коммерческими данными, а контентные (статьи, разделы) — компактным списком. Это одна из типовых доработок в наших проектах по поиску.

Поиск по каталогу против общего поиска

В магазине на 1С-Битрикс уживаются два немного разных сценария поиска, и важно не путать их при проектировании.

Общий поиск по сайту. Ищет по всему: товарам, разделам, статьям, новостям, страницам. Он удобен, когда покупатель может искать что угодно — и товар, и статью «как выбрать», и информацию о доставке. Выдача получается смешанной: сверху товары, ниже — контент. Такой поиск — это классический search.page по всем модулям.

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

Во многих проектах эти сценарии сочетают: глобальная строка в шапке ведёт в общий поиск, а внутри раздела каталога работает более узкий поиск по товарам с возможностью тут же уточнить результат фильтром. Какой сценарий основной, зависит от типа магазина: для контентного проекта важнее общий поиск, для крупного каталога — товарный.

Поиск по артикулу и свойствам

Для B2B-магазинов и для покупателей, которые заказывают «по прайсу», поиск по артикулу важнее поиска по названию. Клиент видит в накладной код SM-A155-BK и вводит его в строку — и ждёт, что найдётся ровно этот товар или его вариация. Штатный поиск, заточенный под текст и морфологию, с кодами справляется хуже, поэтому поиск по артикулу настраивают отдельно.

Что учесть при поиске по артикулу

• Артикул должен быть в индексе. Свойство «Артикул» товаров и торговых предложений явно включают в область индексации, иначе поиск по коду не сработает.
• Морфология коду вредит. Для кодов отключают морфологический разбор и ищут по вхождению строки — иначе A155 может «развалиться» на части.
• Частичное совпадение. Клиенты часто вводят часть артикула. Полезно поддержать поиск по началу или подстроке кода.
• Артикулы вариаций. В каталоге с торговыми предложениями у каждой вариации свой артикул — поиск должен находить конкретный SKU и вести на его карточку с уже выбранной вариацией.

Поиск по артикулу — отдельная большая тема, особенно для оптовых магазинов, где скорость и точность подбора по кодам напрямую влияют на объём заказов. Мы подробно разбираем её в статье про поиск по артикулу в B2B: там про быстрый ввод, загрузку списка кодов и распознавание частичных совпадений. А про то, как устроены сами вариации и их артикулы, — в материале про торговые предложения (SKU) в 1С-Битрикс.

Кроме артикула, покупатели ищут и по свойствам: «телевизор 55 дюймов», «сверло 6 мм», «кабель 3 метра». Здесь поиск и фильтр начинают пересекаться. Числовые характеристики из запроса можно распознавать и превращать в условие фильтра, но это уже продвинутый сценарий. Базовый уровень — включить ключевые свойства (диагональ, объём, мощность) в индекс, чтобы совпадение по ним хотя бы поднимало товар в выдаче.

Фильтр против поиска: когда что

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

Поиск отвечает на вопрос «где это лежит?». Покупатель не знает раздела, вводит произвольный текст, а система разбирает его, прощает опечатки, учитывает морфологию и синонимы и приводит человека к товару из любого раздела. Поиск работает с неточным, «человеческим» вводом.

Умный фильтр отвечает на вопрос «какой из этих?». Покупатель уже в нужном разделе и сужает выборку по точным значениям свойств — цене, бренду, размеру. Фильтр работает с фасетным индексом и точными значениями, а не с произвольным текстом.

На практике поиск и фильтр работают в связке: поиск приводит покупателя в нужную категорию, а фильтр уточняет результат. Именно поэтому в товарном поиске выдачу часто дополняют фильтром — чтобы после ввода запроса человек мог сузить её привычными галочками. Если хотите глубже разобраться в фильтре, у нас есть подробный разбор про умный фильтр в 1С-Битрикс — с фасетным индексом, кэшем и SEO-страницами.

Когда штатного поиска мало

Штатный модуль «Поиск» — крепкий инструмент, но у него есть предел. На больших и очень активных магазинах появляются симптомы, по которым понятно: пора смотреть в сторону внешнего движка — Sphinx или ElasticSearch.

• Поиск заметно тормозит. На каталоге в сотни тысяч позиций ответ штатного поиска становится медленным, особенно под нагрузкой.
• Переиндексация тяжёлая. Полное обновление индекса занимает часы и мешает работе сайта; частые обмены с 1С усугубляют проблему.
• Качество по опечаткам не устраивает. Нужен агрессивный нечёткий поиск, гибкое ранжирование, разбор запросов на лету.
• Нужна сложная логика выдачи. Персонализация, буст по продажам, продвинутая обработка синонимов и фраз.

Внешний движок берёт на себя индексацию и поиск, снимая нагрузку с базы данных сайта. Он строит собственные, очень быстрые индексы и умеет отдавать результаты за миллисекунды даже на огромных объёмах. Взамен появляется отдельный сервис, который нужно установить на сервере, настроить и поддерживать, — поэтому решение подключать его принимают по реальным объёмам и требованиям, а не «на всякий случай».

Между Sphinx и ElasticSearch выбор зависит от задач. Sphinx традиционно ценят за скорость полнотекстового поиска и относительно простую интеграцию с 1С-Битрикс. ElasticSearch — более универсальный движок с богатой аналитикой, гибким нечётким поиском и агрегациями, но тяжелее в поддержке. Для чисто товарного поиска на большом каталоге часто хватает Sphinx; когда нужна сложная аналитика и продвинутая релевантность — смотрят в сторону ElasticSearch.

Sphinx и ElasticSearch: подключение

Идея внешнего движка проста: он держит собственный индекс контента и отвечает на поисковые запросы вместо (или в дополнение к) штатного модуля. Сайт при этом продолжает работать на 1С-Битрикс, просто поиск «уезжает» на отдельный быстрый сервис.

Общая схема подключения выглядит так:

1. Установка движка. Sphinx (или ElasticSearch) ставится на сервере как отдельный сервис. Ему нужны свои ресурсы и настройка под объём каталога.
2. Настройка источника данных. Движку описывают, откуда брать данные для индекса — какие таблицы и поля инфоблоков товаров и предложений индексировать.
3. Построение индекса. Движок строит собственный полнотекстовый индекс по каталогу. Дальше он обновляется по расписанию или инкрементально при изменениях.
4. Интеграция с поиском Битрикса. Запросы с витрины направляются в движок; он возвращает список ID товаров, а Битрикс подгружает по ним данные и рисует выдачу привычными компонентами.
5. Настройка ранжирования и опечаток. В движке тонко настраивают веса полей, нечёткий поиск и обработку синонимов под конкретный магазин.

Ключевой выигрыш — скорость и разгрузка базы. Тяжёлые полнотекстовые запросы больше не бьют по основной БД сайта, а обрабатываются специализированным индексом. Плюс появляется гораздо больше контроля над релевантностью: можно точно задать, что название весит больше описания, что товары в наличии поднимаются выше, а опечатки прощаются с нужной степенью.

Аналитика поисковых запросов

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

Что даёт анализ поисковых запросов:

• Реальный спрос. Видно, что и как ищут покупатели, какие бренды и модели популярны, что сезонно растёт.
• Слова покупателя. Люди называют категории не так, как маркетологи. Эти формулировки — подсказки для названий разделов, тегов и SEO.
• Пробелы в ассортименте. Частые запросы товаров, которых нет в наличии, — прямой сигнал закупке.
• Дыры в поиске. Запросы с пустой выдачей по товарам, которые в каталоге есть, показывают, где не хватает синонимов или где сломана индексация.

1С-Битрикс ведёт статистику поисковых запросов: какие фразы вводят, сколько результатов они дают, что ищут чаще всего. Эти отчёты стоит просматривать регулярно — как минимум раз в месяц, а на активном магазине чаще. Топ запросов подсказывает, какие товары вынести в подсказки и на главную; список «нулевых» запросов подсказывает, что чинить в первую очередь.

Пустые выдачи и что с ними делать

«Ничего не найдено» — самая дорогая страница магазина. Покупатель дошёл до поиска, сформулировал запрос и получил пустоту. Дальше он либо уходит, либо, если магазин умный, получает подсказку и всё-таки находит нужное. Работа с пустыми выдачами — один из самых окупаемых видов работ по поиску.

Пустая выдача бывает двух принципиально разных типов, и лечатся они по-разному:

• Товара действительно нет. Покупатель ищет то, чего в каталоге не существует. Это сигнал закупке (расширить ассортимент) и повод показать альтернативы вместо пустой страницы.
• Товар есть, но поиск его не находит. Причина в синонимах (клиент назвал иначе), опечатке, отсутствии в индексе или неправильной морфологии. Это чинится настройкой поиска, и это самый обидный случай — деньги лежат на складе, но покупатель их не видит.

Что показывать на странице «ничего не найдено», чтобы не терять покупателя:

1. Исправление опечатки. «Возможно, вы искали: …» — с ссылкой на правильную выдачу.
2. Похожие или популярные товары. Вместо пустоты — подборка, за которую может зацепиться взгляд.
3. Подсказки по разделам. Ссылки на близкие категории каталога.
4. Форма заявки. «Не нашли нужное? Оставьте запрос — подберём» — способ не потерять «горячего» покупателя совсем.

Мобильный поиск

На мобильных устройствах роль поиска ещё выше, чем на десктопе. Экран маленький, листать длинные каталоги неудобно, набирать текст сложнее — поэтому поиск часто становится главным способом навигации. При этом на телефоне у поиска свои требования.

• Заметная строка. Поиск должен быть на виду, а не спрятан за мелкой иконкой. Крупное поле или хотя бы явная кнопка сразу под шапкой.
• Терпимость к опечаткам. На сенсорной клавиатуре ошибок больше, поэтому обработка опечаток и «вы искали» на мобильном критичнее.
• Компактные подсказки. Выпадающие подсказки должны хорошо смотреться на узком экране: картинка, название, цена — без перегруза.
• Скорость. Мобильные соединения медленнее, поэтому лёгкость запросов и быстрый ответ индекса особенно важны. Здесь внешний движок помогает и по скорости.
• Голосовой ввод. Часть мобильных пользователей диктует запрос голосом — а надиктованный текст почти всегда «разговорный», с лишними словами. Стоп-слова и морфология тут особенно выручают.

Отдельно стоит следить за тем, чтобы клавиатура на мобильном не перекрывала подсказки и чтобы по тапу на подсказку сразу открывалась карточка, а не приходилось дополнительно нажимать «найти». Каждый лишний тап на телефоне — потерянные покупатели.

Влияние поиска на конверсию

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

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

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

Настройка поиска пошагово

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

1. Включите модуль «Поиск» и область индексации. Добавьте в индекс инфоблоки товаров, торговых предложений и разделов; выберите индексируемые поля, включая артикул и ключевые свойства.
2. Настройте морфологию. Убедитесь, что морфология русского (и при необходимости английского) включена и применяется и к запросу, и к индексу.
3. Проверьте стоп-слова. Оставьте стандартный список служебных слов, при необходимости дополните его словами, специфичными для магазина.
4. Наполните словарь синонимов. Заведите базовые синонимы (сотовый/смартфон, айфон/iphone) и договоритесь пополнять его из аналитики запросов.
5. Настройте переиндексацию. Включите индексацию на лету и переиндексацию по расписанию через агент/крон; для больших обменов предусмотрите отдельное обновление индекса.
6. Настройте search.page. Задайте область поиска, число результатов, подсветку, «вы искали». Доработайте шаблон, чтобы товары выводились карточками с ценой и наличием.
7. Подключите search.title. Вставьте подсказки в шапку, настройте типы контента, картинки, цену и наличие в выпадающем списке.
8. Настройте поиск по артикулу. Выключите морфологию для кодов, включите артикул в индекс, поддержите частичное совпадение и переход к нужному SKU.
9. Оформите пустую выдачу. Добавьте исправление опечаток, похожие товары, ссылки на разделы и форму заявки.
10. Оцените нагрузку и объём. Если каталог большой, поиск тормозит или переиндексация тяжёлая — спроектируйте подключение Sphinx или ElasticSearch.
11. Включите аналитику. Настройте разбор поисковых запросов и пустых выдач, назначьте регулярный просмотр отчётов.

Частые ошибки

• Поиск ищет по «живым» данным, а не по индексу. Ждут, что новый товар найдётся сразу, забыв про переиндексацию. Поиск работает по индексу — его нужно обновлять после обмена.
• Морфология выключена или не применяется к индексу. «Телефоны» не находят «телефон». Морфология должна работать и для запроса, и для индексируемого текста.
• Пустой словарь синонимов. «Сотовый» не находит «смартфон». Синонимы после запуска остаются незаполненными и не пополняются из аналитики.
• Артикул не в индексе. Поиск по коду не работает, потому что артикул не включён в индексируемые поля или к нему применяется морфология.
• Распроданные товары в топе выдачи. Покупатель кликает на первый результат, а там «нет в наличии». Наличие должно влиять на ранжирование в магазине.
• Стандартный шаблон выдачи «как список ссылок». Товары показываются сухими ссылками без цены и картинки. Шаблон search.page нужно дорабатывать под магазин.
• Пустая выдача без альтернатив. «Ничего не найдено» без исправления опечатки, похожих товаров и формы заявки — потерянный «горячий» покупатель.
• Переиндексация «на лету» при массовом обмене. Загрузка десятков тысяч позиций с индексацией на лету кладёт сайт. Крупный обмен сопровождают отдельной переиндексацией в часы низкой нагрузки.
• Внешний движок поверх грязных данных. Ставят Sphinx, надеясь «починить поиск», не наведя порядок в каталоге. Движок ускоряет, но не чистит данные.
• Аналитику запросов никто не смотрит. Богатый источник данных о спросе и дырах в поиске лежит без дела; пустые выдачи не разбираются.
• Поиск спрятан на мобильном. На телефоне строку прячут за мелкой иконкой, хотя именно там поиск — главный способ навигации.

Чек-лист внедрения

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

1. Индексация настроена. В индекс включены товары, предложения, разделы и нужные свойства (в том числе артикул); переиндексация на лету и по расписанию работает.
2. Морфология включена. Русская (и при необходимости английская) морфология применяется к запросу и к индексу; словоформы находятся.
3. Стоп-слова и синонимы заведены. Служебные слова отсекаются; словарь синонимов наполнен и пополняется из аналитики.
4. Релевантность настроена. Название весит больше описания; товары в наличии ранжируются выше распроданных.
5. Опечатки обрабатываются. Работает «вы искали»; на больших объёмах — нечёткий поиск.
6. Подсказки в шапке работают. search.title показывает товары с ценой и наличием, разделы и ссылку на полную выдачу.
7. Выдача оформлена под магазин. Товары — карточками с ценой и картинкой; контент — компактным списком.
8. Поиск по артикулу точный. Код находит нужный товар или вариацию; морфология для кодов отключена.
9. Пустая выдача не тупиковая. Есть исправление опечаток, похожие товары и форма заявки.
10. Мобильный поиск удобен. Строка заметна, подсказки компактны, тап ведёт сразу в карточку.
11. Производительность в норме. На большом каталоге оценена нагрузка; при необходимости подключён внешний движок.
12. Аналитика включена. Отчёты по запросам и пустым выдачам просматриваются регулярно, выводы возвращаются в настройку.

Вывод

Поиск по сайту в 1С-Битрикс — это не строка с лупой, а полноценный канал продаж, который работает с самой «горячей» аудиторией магазина. Его качество складывается из понятной цепочки: индексация наполняет поисковый индекс, морфология и синонимы понимают запрос на живом языке, обработка опечаток прощает ошибки, ранжирование поднимает нужное наверх, а подсказки в шапке доводят покупателя до карточки прямо во время ввода. Штатный модуль «Поиск» закрывает большинство задач среднего магазина, а когда каталог вырастает и скорости не хватает — в игру вступают Sphinx или ElasticSearch.

Практический вывод один: относитесь к поиску так же серьёзно, как к карточке товара и оформлению заказа. Настройте индексацию и морфологию, наполните синонимы, оформите выдачу и подсказки под магазин, не оставляйте пустые выдачи тупиковыми и регулярно смотрите аналитику запросов. Сделайте это аккуратно — и поиск перестанет терять покупателей, а начнёт их приводить к покупке. А если хотите сразу заложить сильный поиск в структуру каталога, начните с грамотно спроектированного каталога товаров на 1С-Битрикс, где индексация, свойства и артикулы продуманы с самого начала. Другие разборы по теме — в рубрике «Каталог и поиск».