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

Поиск по товарам на сайте - первое, что показывает, готов магазин продавать или нет. Пользователь вбивает «кросовки» вместо «кроссовки» или «айфон 15 про» вместо точного названия модели, и если движок поиска возвращает пустую страницу, человек уходит смотреть тот же товар на маркетплейсе, где опечатки давно не проблема. Я настраивал поиск по каталогам на WordPress, Tilda и на кастомных сайтах, и почти каждый раз упираюсь в одни и те же три вещи: обработку опечаток, синонимы и скорость выдачи.

Почему стандартный поиск по товарам теряет покупателей

В большинстве движков поиск по товарам на сайте из коробки работает по одному принципу: запрос ищет введённую строку как подстроку в названии и описании товара. В WooCommerce стандартный поиск - это выборка по LIKE с процентами вокруг запроса в заголовке и содержимом записи, без учёта опечаток, порядка слов и релевантности: товар с точным совпадением в начале названия и товар, где слово один раз встретилось в середине описания, могут показаться в произвольном порядке. В Tilda у каталога тоже есть блок поиска по сайту, и он ищет по точному вхождению текста в карточках, поэтому запрос «кросовки» вместо «кроссовки» вернёт пустую выдачу.

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

Опечатки в поиске по каталогу: как их ловить

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

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

Поиск по расстоянию Левенштейна. Сравниваю введённое слово со словами из индекса товаров и допускаю одно-два отличающихся символа. На MySQL это можно посчитать хранимой функцией или вынести в отдельный PHP-скрипт, который проходит по индексу перед основным запросом. Работает нормально для каталога в несколько тысяч товаров, на десятках тысяч позиций такой перебор уже заметно тормозит.

Отдельный поисковый движок со встроенной устойчивостью к опечаткам, например Meilisearch или Elasticsearch. Оба умеют находить совпадения с ошибками ввода без ручной настройки и сразу ранжируют результаты по релевантности. Но это отдельный сервис: нужен VPS, на нём нужно поднять сам движок, настроить индексацию каталога и синхронизацию при изменении цен и остатков, обновлять и оплачивать сервер ежемесячно. На обычном хостинге сайта такое не развернуть, это отдельная статья расходов, а не бесплатная надстройка над существующим сайтом.

Синонимы и словоформы в поисковой выдаче

Опечатки - только часть проблемы. Второй частый случай: покупатель ищет товар правильным словом, но не тем, что в карточке. «Наушники» вместо «гарнитура», «свитшот» вместо «толстовка», «айфон» вместо «iPhone». Точного совпадения нет, а товар в каталоге есть.

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

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

Скорость выдачи: индексация, задержка ввода и кеш

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

Индекс вместо перебора таблиц. Поиск по подстроке с процентом в начале маски не использует обычный индекс базы, СУБД сканирует таблицу целиком. Для каталога от пары сотен товаров уже имеет смысл держать отдельную таблицу-индекс с названием, категорией и брендом товара и FULLTEXT-индексом поверх неё, а не искать по нескольким соединениям таблиц на каждое нажатие клавиши.

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

Кеш частых запросов. Топ-100 поисковых фраз обычно дают заметную долю всех обращений к поиску, и их результат имеет смысл кешировать на несколько минут вместо того, чтобы гонять один и тот же запрос к базе на каждый визит.

Готовые решения и кастомная разработка: что выбрать

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

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

Для WordPress с WooCommerce вместо самописного решения часто достаточно плагина вроде Relevanssi, он считает релевантность и частично сглаживает опечатки, но полноценную нечёткость и синонимы всё равно приходится донастраивать отдельно.

Как я подхожу к внедрению поиска на практике

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

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

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

Как отдельная доработка существующего сайта на WordPress или Tilda настройка словаря синонимов и обработки опечаток обычно укладывается в разовую задачу и оценивается по часовой ставке - от 3 000 ₽/час. Если нужен полноценный поисковый сервис с отдельным индексом, синхронизацией каталога и подбором движка под нагрузку, это уже отдельный проект по интернет-магазину - от 80 000 ₽.

Частые вопросы

Сколько стоит внедрить поиск с учётом опечаток на сайте?

Точечная доработка существующего поиска - словарь синонимов, нормализация запроса, обработка опечаток на MySQL - обычно идёт по часовой ставке от 3 000 ₽/час. Если нужен отдельный поисковый движок с индексацией каталога и сервером под него, это отдельный проект по интернет-магазину, от 80 000 ₽. Точную оценку даю после консультации, от 3 000 ₽.

Можно ли добавить умный поиск без переезда с Tilda или WordPress?

Да, платформу менять не нужно. На Tilda штатный блок поиска дополняется отдельным скриптом, который обращается к своему API поиска и подставляет результат в тот же блок каталога. На WordPress с WooCommerce обработку опечаток и синонимов можно добавить поверх стандартного поиска или существующего плагина, не трогая тему и остальной функционал сайта.

Как быстро проверить, что поиск на сайте вообще работает плохо?

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

Что делать, если поиск на большом каталоге ищет медленно?

Сначала проверить, использует ли запрос индекс базы: поиск по подстроке с процентом в начале маски его не использует и сканирует всю таблицу. Дальше - завести отдельную таблицу-индекс под поиск с FULLTEXT-индексом и добавить задержку перед отправкой запроса при вводе, около 300 мс. Если после этого скорость всё равно не устраивает при большом каталоге и высокой посещаемости, следующий шаг - отдельный поисковый движок на выделенном сервере.