Поиск по сайту интернет-магазина: настройка SearchWP/Elasticsearch и конверсия
Почему команды интернет-магазинов системно игнорируют поиск по сайту
Большинство B2B интернет-магазинов относятся к поисковой строке как к элементу декора: ставят в правом верхнем углу, никто её не настраивает и никто не смотрит данные. Но путь B2B-покупателя отличается от B2C: они не бродят бесцельно, а приходят с конкретными характеристиками — «304 stainless flange», «1000W inverter», «IP65 enclosure 200×150». Такие точные запросы почти невозможно найти через навигацию по категориям, только через поисковую строку.
Контринтуитивный вывод:Сайты с низкой долей использования поиска не в том, что поиск не нужен, а в том, что поиск настолько плох, что им боятся пользоваться. Посетитель вводит запрос один раз, получает 0 результатов или кучу нерелевантных страниц и в следующий раз просто закрывает страницу и уходит. Поэтому «поиском никто не пользуется» само по себе тревожный сигнал, а не доказательство того, что поиск не нужно оптимизировать. Как настроить отслеживание, смотрите в Развёртывание GA4 и события.
| Частое заблуждение | Реальный сигнал | Правильное действие |
|---|---|---|
| Поиском никто не пользуется, можно не обращать внимания | Высокая доля нулевых результатов = плохой поиск | Сначала две недели отслеживания, потом выводы |
| Достаточно поставить поисковую строку в правом верхнем углу | На мобильных поиск трудно найти | Закреплённая строка поиска сверху на мобильных |
| Страница результатов поиска не важна | Конверсия после поиска в 2–3 раза выше, чем после просмотра | Добавить фильтры и сортировку на страницу результатов |
| Поиска WP по умолчанию достаточно | WP по умолчанию ищет только по заголовкам и тексту | Атрибуты товаров нужно индексировать отдельно |
| Достаточно перейти на Elasticsearch | Если структура индекса не продумана, всё равно будет плохо | Сначала настроить веса, потом менять движок |
II. Решение о выборе: как выбрать из трёх уровней поиска
Самая частая ошибка команд интернет-магазинов — сразу обсуждать «Elasticsearch или Algolia», ставя выбор инструмента перед диагностикой проблемы. Правильный порядок: сначала две недели отслеживания, чтобы понять три показателя — долю использования поиска, долю нулевых результатов и долю кликов по первому результату, — и только потом решать, какой уровень подходит.
Порог определяется просто: если поиском пользуются менее 2% посетителей, сначала займитесь навигацией и контентом, а не меняйте движок; при 2–5% достаточно установить SearchWP и настроить синонимы и веса; если доля выше 5% и в каталоге более 500 SKU, тогда стоит рассмотреть Elasticsearch или облачный поисковый сервис. Общий подход к проектированию поиска по каталогу описан в удобству поиска по каталогу товаров.
| Уровень | Для какого масштаба | Время отклика | Годовая стоимость | Стоимость поддержки |
|---|---|---|---|---|
| Стандартный WP_Query в WordPress | <200 страниц, только статьи | 1–3 секунды | 0 долларов | Практически ноль |
| Плагин SearchWP | 200–5000 страниц с товарами | 200–400 миллисекунд | около 199 $ | ежегодная оплата + переиндексация |
| Локальный Elasticsearch | >5000 страниц, SKU>1000 | 80–150 миллисекунд | свой сервер за 30–80 $/мес | нужна поддержка инфраструктуры |
| Облачные Algolia/Meilisearch | у команды нет ресурсов на поддержку | 50–120 миллисекунд | 99–399 $ в месяц | оплата зависит от числа документов |
| Поиск товаров в WooCommerce | небольшой интернет-магазин | 300–600 миллисекунд | около 99 $/год | глубокая интеграция с Woo |
III. Как настроить SearchWP: веса, синонимы и страница без результатов
SearchWP — самое выгодное решение для улучшения поиска в экосистеме WordPress. Его главная ценность не в том, что он “быстрее”, а в том, что он позволяет настраивать релевантность. Стандартный поиск WordPress сортирует результаты по post_date в обратном порядке, а SearchWP позволяет задать вес для заголовка, текста, меток, произвольных полей, рубрик и краткого описания — для товарных сайтов это особенно важно, ведь покупатели ищут модель, а не заголовок статьи.
Пример конкретной настройки: на товарном сайте задайте вес 10 для поля “Модель товара”, 5 для “Краткого описания”, 2 для “Текста” и 3 для “Меток”. Тогда при вводе “WF-200” покупатель сразу попадёт в поле модели, а не наткнётся на абзац в блоге, где упоминается WF-200. В таблице синонимов должно быть не менее 50 групп: отраслевые сокращения, варианты написания, различия между американским и британским написанием (например, “aluminum” и “aluminium”). Как собрать техническую часть на WordPress, читайте в Технологический стек WordPress.
| Параметр | Рекомендуемое значение для товарного сайта | Рекомендуемое значение для контентного сайта | Сигнал для корректировки |
|---|---|---|---|
| Вес заголовка | 8 | 10 | повысить, если CTR первого результата <30% |
| Вес текста | 2 | 5 | понизить при высокой доле запросов без результатов |
| Вес произвольного поля | 10 (модель/характеристики) | 1 (почти не используется) | повысить, если поиск по модели даёт плохие результаты |
| Вес меток | 3 | 4 | дополнить, если синонимы покрывают не всё |
| Вес рубрик | 5 | 2 | понизить, если результаты слишком общие |
| Минимальная длина слова | 2 символа | 3 символа | снизить до 2, если короткие модели не находятся |
| Размытое сопоставление | включить (расстояние редактирования 1) | Закрыть | включать на рынках с частыми опечатками |
IV. Когда Elasticsearch действительно нужен и как его настроить
Elasticsearch — не синоним “продвинутого поиска”, он создан для масштабного полнотекстового поиска и сложных агрегаций. Интернет-магазину стоит его внедрять только при выполнении одного из двух условий: первое — более 1000 SKU и нужна фильтрация фасетов в реальном времени (одновременный отбор по ценовому диапазону, материалу и сертификату); второе — более 5000 страниц и время отклика поиска уже превышает 500 миллисекунд. Если эти условия не выполняются, Elasticsearch — это стрельба из пушки по воробьям.
配置上最容易踩的坑是中文和多语言分词。英文用standard analyzer够用,中文必须装IK分词器并配自定义词典(把你的产品型号、行业缩写加进去),否则”304不锈钢法兰”会被切成单字,召回完全错乱。多语言站还要按语言建独立index,用hreflang对应,这部分可参考 Hreflang для мультиязычных сайтов. Как настроить CDN и кэширование, смотрите в разделе Глобальное ускорение CDN.
| Ситуация | Рекомендуемый подход | Ключевые настройки | Ожидаемый результат |
|---|---|---|---|
| Блог на 500 страниц | SearchWP бесплатная версия | Вес заголовка 10, текста 5 | Доля запросов без результатов снизилась с 25% до 8% |
| Сайт с 3000 страниц товаров | SearchWP Pro | Вес поля модели 10 + таблица синонимов | Конверсия после поиска +15% |
| Интернет-магазин на 2000 SKU | Локальный Elasticsearch + плагин для WP | IK-токенизация + фасетная агрегация | Отклик <150 мс |
| Мультиязычный B2B-сайт | Elasticsearch с несколькими index | Отдельный index под каждый язык + синонимы | Доля запросов без результатов по каждому языку <10% |
| У команды нет DevOps | Облачные Algolia/Meilisearch | Официальный плагин для WordPress | Без обслуживания, оплата по объёму документов |
Пять: доля запросов без результатов важнее позиций в выдаче
Многие команды следят за тем, “на каком месте в выдаче” оказался результат, но для B2B-поиска настоящий убийственный показатель — доля запросов без результатов. Если по поисковому запросу не нашлось ничего, посетитель не станет листать страницы — он просто закроет браузер. Отраслевая норма такова: доля запросов без результатов выше 20% означает, что запросы и структура контента не совпадают, а выше 35% — что поиск практически не работает.
Работа с высокой долей запросов без результатов идёт в два шага. Первый: выгрузите запросы без результатов в таблицу, отсортируйте по частоте — первые 20 самых частых нужно обработать обязательно. Второй: по каждому запросу определите, “контента под этот запрос нет” или “контент есть, но его не находят”. В первом случае нужно добавить контент, во втором — настроить вес индекса или добавить синонимы. Как вытащить запросы из внутреннего поиска и превратить их в пробелы в контенте, смотрите в разделе поисковые запросы внутри сайта. В Core Web Vitals страница результатов поиска тоже влияет на LCP, смотрите в разделе Оптимизация Core Web Vitals.
| Показатель | Здоровый диапазон | Порог алерта | Действие |
|---|---|---|---|
| Доля сессий с поиском | 5–15% | Ниже 2% четыре недели подряд | Улучшить навигацию и заметность входа в поиск |
| Доля запросов без результатов | менее 10% | Выше 20% | Выгрузить частые запросы без результатов, добавить контент или настроить вес |
| Клик по первому результату | Выше 40% | Ниже 25% | Проблемы с релевантностью ранжирования, настроить вес |
| Конверсия из поиска | В 2–3 раза выше, чем при обычном просмотре | На уровне просмотра | На странице результатов не хватает фильтров и CTA |
| Время отклика поиска | Ниже 300 мс | Выше 800 мс | Добавить кэширование или обновить движок |
FAQ: частые вопросы
Обязательно ли ставить Elasticsearch на отдельный сайт?
Как понять, нужно ли оптимизировать внутренний поиск?
Чем SearchWP отличается от стандартного поиска WordPress?
Почему поиск на китайском в Elasticsearch даёт плохие результаты?
Что делать с высокой долей нулевых результатов и как обрабатывать их массово?
Как выбрать между Algolia и собственным Elasticsearch?
В заключение
Внутренний поиск — самый недооценённый по отдаче модуль интернет-магазина. Он не требует больших усилий: сначала две недели аналитики, затем по двум цифрам — доле нулевых результатов и доле использования поиска — решаете, на какой уровень переходить. Большинству сайтов достаточно остаться на SearchWP. Elasticsearch — не обязательный пункт, а естественный выбор при достижении масштаба, а не отправная точка для улучшения поиска.
Три шага к результату. Первый: на этой неделе настроить в поле поиска отслеживание событий GA4 — записывать запрос, клик и число результатов. Второй: через две недели выгрузить список запросов с нулевой выдачей и проработать 20 самых частых. Третий: по показателю использования поиска решить, нужен ли SearchWP; если поставить — один раз настроить веса и через месяц проверить, вырос ли CTR первого клика с 25% до 40% и выше.
Запомните главное: низкое использование поиска — это не «поиск не нужен», а «поиск настолько плох, что им боятся пользоваться». Сначала поставьте аналитику и разберитесь в причинах, а уже потом выбирайте движок.
