Поиск по сайту не работает? Как научить его понимать людей и не платить за ИИ

Посетитель вводит слово в строку поиска, видит «ничего не найдено» и решает, что у вас этого нет, хотя оно есть. Большинство таких сбоев исправляется без ИИ и без платных сервисов. Разбираем, что люди вводят на самом деле, что и в каком порядке строить, как мы сделали собственный поиск на обычном MySQL на трёх языках, какие ошибки нашли в нём наши проверки и когда правильный выбор это Algolia, Elasticsearch, Meilisearch или векторный поиск.

КОРОТКО

Что умеет хороший поиск по сайту

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

Проблема встречается даже там, где бюджеты велики. В бенчмарке Baymard Institute за 2026 год, более 170 интернет-магазинов и приложений, поиск оценён как «посредственный или хуже» на 46% сайтов для компьютера, 58% мобильных сайтов и 64% приложений (Baymard, обновлено в апреле 2026). Это магазины, за которыми стоят команды, а у сервисного сайта часто есть только строка, пришедшая вместе с CMS.

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

ЧТО ВВОДЯТ ЛЮДИ

Что посетители вводят в строку

Люди ищут своими словами, а набирать текст долго и легко ошибиться (Nielsen Norman Group, 2014). Страницы написаны вашими словами. Почти любой сбой поиска это разрыв между двумя словарями, и разновидностей у него немного.

Пятую строку владельцы недооценивают чаще других. По данным Baymard за 2026 год, запросы не о товарах, например об условиях возврата, вызывали проблемы на 66% изученных сайтов, больше всех остальных типов запросов в той статье, против 20% у простых запросов по типу товара. Человек, который ищет на вашем сайте телефон, уже решил с вами поговорить, а поиск отвечает ему статьёй из блога.

Каждый пустой поиск это посетитель, который своими словами сказал, чего хотел.

ПОЧЕМУ СТАНДАРТНЫЙ ОШИБАЕТСЯ

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

Стандартный поиск рассчитан на блог. Самый наглядный пример WordPress, потому что его код открыт: каждое слово ищется через LIKE '%слово%' в трёх колонках (заголовок, отрывок, содержимое), и должны найтись все слова (справочник разработчика WordPress, ноябрь 2026). Отсюда и симптомы, на которые жалуются владельцы:

• Только точные буквы: опечатка или синоним не находят ничего.
• Куски слов: %кот% находит и «который», и «некоторые», поэтому короткий запрос выдаёт длинный и странный список.
• Один язык: запрос на другом языке ищет буквы, которых нет в текущей версии страницы.
• Только эти колонки: характеристики товаров, дополнительные поля и текст страниц из шаблонов, часто это ваши цены и услуги, остаются вне досягаемости.
• Тупик: примерно 50% интернет-магазинов устроены так, что страница «ничего не найдено» раздражает людей и может увести их во внешний поисковик (Baymard, обновлено в феврале 2025).

Другие платформы начинают с лучшей позиции. Shopify сообщает, что поиск в его магазинах по умолчанию учитывает опечатки и использует связанные слова и понятия (Shopify Help Center, ноябрь 2026), поэтому магазину на Shopify стоит сначала посмотреть на данные о товарах, а покупать что-то потом. Если платформа уже переросла свои плагины, поиск обычно один симптом из нескольких, об этом мы писали в статье Когда бизнес перерастает WordPress?

Старый короткий путь, строка на движке Google, тоже сузился. Custom Search JSON API закрыт для новых клиентов, у действующих есть время до 1 января 2027 года, а в качестве альтернативы Google называет Vertex AI Search (Google for Developers, ноябрь 2026).

ПОРЯДОК РАБОТ

Что строить и в каком порядке

Первой идёт самая дешёвая и самая полезная работа. На закрытой платформе этот же список становится перечнем настроек и приложений.

1. Записывайте каждый поиск: запрос, язык, число результатов, чем поиск помог. Это час-два работы (наша оценка), и лог подскажет, что должно быть в остальных пунктах.
2. Охватите всё, что люди читают: статьи, услуги, проекты, ответы FAQ, авторов, вакансии и страницы из шаблонов.
3. Ищите по началу слова и требуйте все значимые слова: одно это убирает много мусора.
4. Сначала заголовок: страница со всем запросом в заголовке должна обходить страницу, где эти слова встречаются в сороковом абзаце. Решите, какой тип страницы выигрывает при равенстве.
5. Добавьте группы синонимов из лога: начните с 10 или 20 групп, которые в нём уже видны, на всех ваших языках.
6. Добавьте карточки лучшего ответа: цены, контакты, вакансии, каждая отрасль, с которой вы работаете.
7. Замените пустую страницу: другая раскладка, ближайшее слово, другой язык и строка о том, что было сделано.
8. Добавьте результаты по мере ввода, в последнюю очередь, потому что это умножает все проблемы выше.

Если код пока менять нельзя, первый шаг можно начать сегодня в Google Analytics 4. Расширенная статистика отправляет событие view_search_results с поисковым запросом, когда в адресе страницы есть параметр q, s, search, query или keyword (Справка Google Analytics, ноябрь 2026). Числа результатов в этом событии нет, так что запросы без результатов требуют отдельной настройки. Люди ещё и вставляют в строку поиска адреса почты, а Google запрещает передавать в Analytics персональные данные, в том числе в параметрах адреса (Справка Google Analytics, ноябрь 2026), поэтому включите редактирование данных.

Заведите файл из 30 или 50 реальных запросов со страницей, которую вы ожидаете для каждого, на каждом языке, и запускайте его после каждого изменения. Это часть регрессионной работы, описанной в статье Сколько тестирования нужно сайту или приложению перед запуском?

НАШ СЛУЧАЙ

Как устроен наш собственный поиск

Наш сайт работает на Laravel и MySQL, а весь поиск это один контроллер примерно на 600 строк PHP и небольшой скрипт для списка подсказок, на английском, русском и украинском. Никакие внешние сервисы не вызываются.

Совпадения. У статей, проектов и услуг есть индексы InnoDB FULLTEXT, запросы к ним идут в логическом режиме. Каждое слово запроса превращается в обязательную группу из него самого и его синонимов, у каждого звёздочка в конце, так что запрос «сайт цена» выглядит примерно как +(сайт* вебсайт* website* web*) +(цена* стоимост* cost* ...). Плюс значит, что группа обязательна, звёздочка значит, что слово может так начинаться (руководство MySQL 8.4). Всё, кроме букв и цифр, сначала убирается, потому что случайный символ может сработать как оператор. Слова короче трёх букв отбрасываются, если остаётся что-то ещё, потому что минимальный размер токена в MySQL по умолчанию равен 3 (руководство MySQL 8.4).

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

Синонимы. 27 групп, написанных вручную на трёх языках, например группа из слов сайт, website, web и веб. Большинство записей это основы слов, так одна строка покрывает большинство падежей. Короткие термины до трёх букв совпадают только как целые слова: 2 ноября 2026 года в английской версии сайта запрос car вывел карточку автомобильной отрасли, а careers вывел вакансии.

Ранжирование. Баллы настолько просты, что их можно прочитать вслух:

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

НИЧЕГО НЕ НАЙДЕНО

Когда результатов нет

Пустой результат запускает лестницу шагов, и страница сообщает, что было сделано.

Другая раскладка. Человек печатает по-русски, а клавиатура осталась на английской, и получается абракадабра: ctj вместо «сео». Таблица соответствий переводит запрос в другую раскладку и пробует снова, даже если сверху есть опечатка. В Заливе та же таблица пишется для пары арабский и английский. Мы её не строили, потому что на нашем сайте нет арабской версии, но для сайта на двух этих языках это первый кандидат.

Ближайшее слово. Каждое слово от четырёх букв из наших заголовков попадает в словарь, который кэшируется на час. Слово запроса, которого там нет, сравнивается со словарём по расстоянию Левенштейна, то есть числу замен одной буквы между двумя словами: одна замена для слов до пяти букв, две для более длинных, при равенстве выигрывает более частое слово. Функция levenshtein() в PHP, судя по заметкам пользователей в руководстве, работает с байтами и может посчитать одну кириллическую букву за две замены, поэтому расстояние мы считаем по буквам сами. 2 ноября 2026 года запрос development с двумя переставленными буквами в английской версии вернул «Did you mean» и услуги по разработке.

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

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

ЛОГ ПОИСКА

Лог пустых запросов это бесплатный отчёт для бизнеса

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

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

В магазине тот же лог показывает отсутствующие товары и характеристики, которых нет в каталоге, об этом статья Intelligent Product Discovery: поиск, фильтры и конфигураторы для сложных каталогов. Чтение лога входит и в наш юзабилити аудит, от $1 500.

«Ничего не найдено» это единственный отчёт, который клиенты пишут бесплатно.

Большинству сайтов должно хватать получаса в месяц (наша оценка): исправьте три строки, а через месяц посмотрите, сдвинулись ли эти запросы.

ГДЕ ЛОМАЕТСЯ

Что нашли наши проверки

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

Ловушка стоп-слов. На английской версии нашего сайта запрос "how much does a custom website cost" не вернул в первых строках нашу же статью с этим заголовком (по-русски она называется Сколько стоит кастомный сайт в 2026 году?). Без слова how статья сразу вышла первой, прямо под карточкой цен. Руководство MySQL, как мы его понимаем, объясняет почему: how входит в список стоп-слов InnoDB по умолчанию, поэтому его нет в индексе, но слово с оператором усечения остаётся в логическом запросе, даже если это стоп-слово. Получается, +(how*) требует слово, начинающееся на how, самого how в индексе нет, и проходит что-нибудь вроде however. В том же списке what, when, where, who и предлоги вроде for и with (руководство MySQL 8.4). Это слова, с которых начинаются вопросы. Мы исправили это в тот же день: стоп-слова убраны из обязательной части запроса и остались только для сравнения с заголовками, так что статья теперь идёт сразу под карточкой цен. Наши проверочные вопросы на русском и украинском прошли нормально, потому что список по умолчанию в основном английский. Если у вашего сайта есть английская версия, а в Заливе это обычное дело, проверьте её отдельно.

Лестница начиналась только с нуля. Запрос ctj перестал давать ноль результатов, потому что наша статья о product discovery приводит именно этот пример, а теперь и эта. Запрос находил эти статьи, и исправление раскладки не запускалось. Так же могло повести себя русское слово на английской версии сайта: одна случайная статья, где оно есть, и никакого перехода к другим языкам. Условие мы изменили в тот же день: если запроса нет ни в одном заголовке, исправление раскладки и другие языки тоже запускаются и берут верх, только когда в их результатах запрос стоит в заголовке. Запрос ctj снова ведёт к «сео».

У поиска по началу слова есть цена. Правило целых слов для коротких терминов управляет карточками и синонимами. Результаты всё равно совпадают с любым словом, начинающимся так же, поэтому под карточкой автомобильной отрасли появляется термин глоссария Cart abandonment.

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

ВЫБОР ДВИЖКА

MySQL, Algolia, Elasticsearch, Meilisearch или векторы

В документации Laravel о встроенном поисковом движке на базе данных сказано, что для большинства приложений этого достаточно, а к отдельным движкам она отправляет за терпимостью к опечаткам, фасетами, векторным поиском и геопоиском в большом масштабе (документация Laravel 13, ноябрь 2026). Цены ниже проверены в ноябре 2026 года и будут меняться.

Посчитайте для своего трафика. Algolia берёт плату за поисковый запрос, а её библиотека InstantSearch по умолчанию отправляет запрос на каждое нажатие клавиши; она советует задержку примерно 200 мс (документация Algolia, ноябрь 2026). Допустим, один поиск стоит пяти запросов с учётом задержки, это наше допущение. При 20 000 поисков в месяц выходит 100 000 запросов, около $45 на Grow или $158 на Grow Plus. При 200 000 поисков это миллион запросов, около $495 или $1 733. Сама Algolia называет свои оценки ориентировочными. Для многих средних компаний важнее другой вопрос: копия каталога на чужом сервисе и то, что будет, когда изменится договор.

Проверьте языки до подписания. Для рынка Залива важен арабский. В Elasticsearch есть встроенные анализаторы для русского и арабского, арабский с нормализацией и выделением основы (документация Elastic, ноябрь 2026). Meilisearch описывает отдельную обработку кириллицы и арабского письма, включая отделение артикля (документация Meilisearch, ноябрь 2026).

Векторный поиск дёшево индексировать и легко переоценить. По $0,02 за миллион токенов эмбеддинги тысячи страниц примерно по 1 500 токенов обойдутся примерно в три цента (наш расчёт). Настоящие затраты это ещё один сервис и вызов модели на каждый запрос. К тому же он промахивается там, где люди вводят самое точное: артикулы, жаргон, даты и имена лучше работают с поиском по словам, а гибридный поиск Microsoft запускает оба параллельно (Microsoft Learn, обновлено в сентябре 2026). В Laravel семантический поиск на движке базы данных требует PostgreSQL с pgvector, а в главе о типах данных MySQL 8.4 векторного типа нет. Наше правило: сначала посмотрите лог пустых запросов. Если в нём описания, а не названия, поиск по смыслу может окупиться. Если в нём опечатки и другие слова для того же самого, не окупится. Когда посетителю нужен разговор, а не список, это работа для ИИ-ассистента на сайте.

Отдельной цены на поиск в нашем прайсе нет. Мы встраиваем его в веб-приложение, от $25 000, или в интернет-магазин, от $25 000, где у него общая модель данных с фильтрами и фасетной навигацией, а на готовом сайте начинаем с чтения лога. Все наши цены на странице цен.

Сначала прочитайте лог: чаще всего он сам выбирает движок.

FAQ

Источники

• Baymard Institute: E-commerce search query types, бенчмарк 2026 года
• Baymard Institute: страницы "No Results"
• Руководство MySQL 8.4: логический полнотекстовый поиск
• Документация Meilisearch: настройки терпимости к опечаткам
• Algolia: цены