Покупатель вводит название модели, которая есть в каталоге, и получает «Ничего не найдено». Другой ищет условия возврата, а видит десятки товаров со словом «возврат» в описании. Поле поиска работает, но задача остаётся нерешённой. В Гуси-Лебеди предлагаем проверять поиск по сайту именно по таким сценариям. Разберём, как выбрать решение, подготовить индекс, настроить выдачу и убедиться, что человек действительно находит нужное.
С чего начать настройку поиска по сайту
Внутренний поиск ищет внутри вашего каталога, блога или базы знаний. Он отличается от поиска сайта в Яндексе и от поиска слова на открытой странице браузера. Поэтому сначала определите, какое содержание должен находить посетитель и какую задачу он решает после перехода.
Соберите примеры из обращений клиентов, разрешённых к использованию поисковых журналов и названий реальных товаров. Если данных пока нет, подготовьте учебный набор вместе с менеджером каталога. Отмечайте происхождение запросов: предположения команды не становятся поведением покупателей автоматически.
| Сценарий | Учебный запрос | Ожидаемый результат |
|---|---|---|
| Точная модель | Код конкретной лампы | Нужная карточка среди первых результатов |
| Категория | Настольная лампа | Подходящие товары и переход к категории |
| Задача | Свет для рабочего стола | Согласованная подборка подходящих решений |
| Помощь | Как вернуть заказ | Актуальные условия возврата |
| Закрытый документ | Название внутреннего договора | Отсутствие утечки для посетителя без доступа |
Для каждого примера укажите допустимые результаты и нежелательные подмены. Так разработчик понимает критерий приёмки, а владелец сайта может сравнивать изменения на одном наборе. Товарный поиск и поиск по инструкциям иногда лучше разделить вкладками или понятными группами.
Как добавить поиск технически? Для простого проекта начните с возможностей CMS, плагина или платформы. Если нужны сложные правила, отдельные поля, управляемое ранжирование и обновление большого каталога, сравнивайте специализированные решения на своём наборе запросов. Название движка само по себе не подтверждает качество.
Например, инструкция Tilda описывает штатные поисковые блоки и включение внутреннего поиска в настройках сайта. У платформы есть ограничения, в том числе для страниц с доступом через личный кабинет. Не переносите эту настройку на другую CMS как универсальную инструкцию.
Что включить в поисковый индекс и как обновлять данные
Индекс является подготовленным представлением содержания, по которому работает поиск. Для товара полезно отдельно хранить название, артикул, бренд, категорию, свойства и адрес карточки. Для инструкции нужны заголовок, содержание, тема и статус публикации. Объединение всех полей в один длинный текст затрудняет управление результатами.
Определите источник каждого поля. Цена, наличие и название не должны обновляться по случайным независимым правилам. Если поиск показывает сохранённую цену, согласуйте, как быстро она должна изменяться после обновления товара. Проверьте и саму карточку товара: обещание в выдаче должно соответствовать странице перехода.
Отдельно опишите создание, изменение и удаление записи. Недостаточно один раз загрузить каталог. После снятия товара с публикации проверьте его отсутствие в выдаче, подсказках и старых кэшированных ответах. После переименования проверьте новые и старые варианты названия по согласованному правилу.
Права доступа применяйте до передачи результата пользователю. Скрытая ссылка при видимом названии документа всё равно раскрывает информацию. Проверяйте также фрагменты текста, подсказки и счётчики. Для разных ролей подготовьте отдельные сценарии и убедитесь, что общий кэш не возвращает закрытые данные другому посетителю.
Перед подключением внешнего сервиса определите, какие данные передаются, где они обрабатываются и что действительно необходимо для поиска. Не отправляйте весь документ только потому, что так проще собрать индекс. Решение выбирают с учётом содержания и условий работы проекта.
Как настроить результаты, опечатки и поиск по артикулу
Сначала система получает подходящих кандидатов, затем определяет их порядок. Если точная модель оказалась в конце списка, проверьте обе стадии: попала ли она в кандидаты и почему уступила другим. Не пытайтесь исправить отсутствие записи повышением её позиции.
Для названий настройте обработку языка и форм слов, а для артикула предусмотрите точное сопоставление. Проверяйте пробелы, дефисы, регистр и похожие символы на настоящих кодах каталога. Удаление всех знаков может объединить разные модели. Правило нормализации нужно обосновать вашим форматом идентификаторов.
Опечатки полезно обрабатывать избирательно. Разница в одной букве слова и разница в цифре артикула могут означать совершенно разные вещи. Показывайте исправление понятным образом и сохраняйте возможность вернуться к исходному запросу. Не превращайте близкое совпадение в уверенное обещание найти точную модель.
В документации Elasticsearch описаны анализ текста и параметры нечёткого сопоставления для match. Это возможности конкретного запроса, а не готовый рецепт для любого каталога. Язык, поля и взаимодействие правил проверяйте отдельно.
Синонимы добавляйте по смыслу и направлению. Запрос широкой категории не обязательно должен находить каждый её частный вид с одинаковым приоритетом. Учебное соответствие «светильник для стола» и «настольная лампа» полезно проверить, а связь «лампа» и «люстра» нельзя принять только из-за общего назначения.
Рекламный приоритет, маржа и наличие могут участвовать в порядке выдачи, но сначала результат должен отвечать запросу. В обзоре релевантности Algolia отдельно рассматривают поисковые поля, порядок результатов и последующую аналитику. Не копируйте настройки чужого магазина без проверки собственного ассортимента.
Что показывать, когда поиск ничего не нашёл
Пустая выдача имеет разные причины: товара нет, мешают фильтры, запрос содержит опечатку, индекс устарел или поисковый сервис не ответил. Одна надпись «Ничего не найдено» не объясняет, что делать дальше. Ошибку сервиса вообще нельзя выдавать за отсутствие товара.
Сохраняйте введённый запрос. Если ограничение связано с выбранной категорией или фильтром, покажите возможность расширить область. Если предлагаете исправленное написание, явно обозначьте изменение. Не сбрасывайте условия молча, иначе человек не поймёт, почему в списке появились неподходящие варианты.
Когда точного товара нет, предложите подходящий следующий шаг: открыть категорию, посмотреть согласованные альтернативы, проверить наличие у менеджера или найти инструкцию. Не заполняйте пустоту случайными популярными товарами под видом ответа на запрос.
Фильтры и поиск должны работать вместе. При заказе поиска и фильтрации каталога опишите, сохраняются ли условия при новом запросе, как сбрасывается отдельное ограничение и что происходит после возврата из карточки. Для магазина на соответствующей платформе обсудите настройку фильтров WooCommerce и VirtueMart с теми же сценариями.
Сохранённый адрес результатов должен восстанавливать согласованное состояние. Проверьте прямое открытие, возврат браузером и ссылку с уже удалённым параметром. Для технической ошибки предусмотрите повторную попытку и понятное объяснение без внутренних кодов сервиса.
Как сделать удобную строку поиска и подсказки
Поле должно быть заметным там, где посетитель начинает поиск. Дайте ему понятное название, которое сохраняется после ввода. Подсказка внутри пустого поля не заменяет доступное обозначение. Кнопка отправки, очистка и выбранная область должны иметь различимые назначения.
Для подсказок задайте поведение клавиатуры: переход по вариантам, выбор и закрытие списка. Проверьте видимость фокуса и работу с экранным считывателем. На телефоне клавиатура не должна полностью скрывать список или кнопку, а длинный запрос должен оставаться редактируемым.
Отдельная техническая проверка касается порядка ответов. Посетитель быстро изменил запрос, но медленный ответ на предыдущий пришёл позже. Интерфейс должен показывать результаты актуального запроса, а не просто последнего завершившегося запроса к серверу.
Список результатов помогает принять решение до перехода: понятное название, тип документа, подходящий фрагмент и нужные характеристики. Товары, инструкции и услуги лучше визуально различать. Не обещайте наличие через оформление, если источник этих данных не обновляется по согласованному правилу.
Проверьте сценарий целиком: ввод, подсказка, выдача, карточка и возврат. В статье о проверке удобства сайта объясняем, почему отдельный красивый элемент не подтверждает удобство всего пути.
Как проверить качество поиска и безопасно выпустить изменения
До выпуска прогоните согласованный набор запросов и сохраните ожидаемые результаты. Включите опечатки, точные коды, отсутствие товара, закрытые документы и удалённые записи. Отмечайте положение первого подходящего результата и случаи, когда подходящего ответа вообще нет.
| Проверка | Что фиксировать | Ограничение вывода |
|---|---|---|
| Релевантность | Подходящий результат и его позиция | Один удачный запрос не проверяет каталог |
| Пустая выдача | Доля завершённых поисков без результатов | Разделять ошибки сервиса и отсутствие совпадений |
| Переходы | Выбранный результат и его место | Клик не доказывает решение задачи |
| Переформулировки | Повторный запрос в одном сценарии | Уточнение не всегда является ошибкой |
| Актуальность | Обновление, удаление, смена доступа | Проверять выдачу, подсказки и кэш |
| Надёжность | Время ответа, ошибки и восстановление | Нужны согласованные условия измерения |
В аналитике связывайте отправку запроса, показ результатов и переход общим идентификатором сценария. Считайте отправленные завершённые поиски, а не каждое нажатие клавиши. Сырые строки могут содержать личные данные, поэтому определите допустимый состав, обработку и срок хранения.
Конверсия посетителей с поиском и без него не доказывает влияние нового алгоритма: группы могут изначально иметь разные намерения. Для причинного сравнения нужен подходящий эксперимент, о котором рассказываем в материале про A/B-тестирование. Не обещайте рост продаж по одному изменению выдачи.
При замене индекса подготовьте новую версию отдельно, проверьте набор запросов и обновление данных, затем переключайте приложение по согласованному плану. Предусмотрите возврат к прежней версии и проверьте, что после переключения продолжают поступать изменения каталога. Включите поисковый сценарий в мониторинг работы сайта.
Внешнее SEO проверяйте отдельно. Произвольные страницы поисковых запросов не становятся полезными посадочными страницами автоматически. Определите политику адресов и индексации, чтобы не создавать бесконечные комбинации. И не заказывайте SearchAction ради обещанного поискового поля в Google: компания объявила удаление Sitelinks Search Box с 21 ноября 2024 года.
Приёмка заканчивается проверкой опубликованного поиска на реальных разрешённых данных, разных устройствах и ролях. Результат должен быть конкретным: нужная модель находится, условия понятны, закрытые записи не раскрываются, а обновления каталога доходят до выдачи.