Поиск по сайту ничего не находит: как проверить его на небольшой учебной выборке

Ready4site

Все названия товаров, запросы, ошибки и результаты в статье – учебные. Это пример воспроизводимого теста, а не аудит реального магазина, пользовательская статистика или обещание улучшения конверсии.

Сначала соберите маленький эталонный каталог

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

• T-101 – Шуруповерт аккумуляторный 12 В; опубликован, в наличии.

• T-102 – Набор бит 32 шт.; опубликован, в наличии.

• T-103 – Сверло по дереву 6 мм; опубликован, в наличии.

• T-104 – Дрель ударная 750 Вт; опубликована, в наличии.

• T-105 – Перчатки рабочие; опубликованы, в наличии.

• T-106 – Лобзик электрический; опубликован, в наличии.

• T-107 – Пила ручная; опубликована, в наличии.

• T-108 – Шуруповерт аккумуляторный 12 В, старая карточка; снята с публикации и заменена товаром T-101.

У карточки T-108 оставляем одинаковое или почти одинаковое название намеренно: так можно проверить, не возвращает ли поиск архивную версию вместо действующего товара. В реальном магазине старую запись безопаснее заменить синтетическим тестовым объектом или отключить тестовую среду от публичной выдачи.

Зафиксируйте условия до первого прогона

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

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

Контрольная таблица запросов

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

Порядок проверки: от простого к составному

1. Убедитесь, что тестовый запрос вообще отправляется

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

2. Проверьте товар до поискового движка

Найдите тестовый товар в каталоге по ID: опубликован ли он, заполнены ли индексируемые поля, разрешен ли показ для выбранного магазина и региона? Затем проверьте, обновился ли индекс после изменения карточки. Для поисковой системы «товар существует в базе» и «товар доступен в текущей выдаче» – разные проверки.

3. Разделите совпадение и порядок

Если ожидаемый товар есть, но стоит слишком низко, это отдельный вопрос ранжирования. Сначала добейтесь, чтобы контрольный товар находился, затем оценивайте его позицию. На восьми карточках можно вручную сверить полный набор ID; на большой выборке заранее задают допустимую глубину просмотра и считают долю запросов, где ожидаемый товар попал в нее. Не меняйте одновременно поля поиска, фильтры и сортировку – иначе будет трудно понять, какая правка повлияла на результат.

4. Проверяйте словоформы, опечатки и синонимы отдельно

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

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

5. Отдельно пройдите пустую выдачу и устаревшие данные

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

Как локализовать сбой

Полезно идти по цепочке и каждый раз менять только одну гипотезу. Для конкретного поискового запроса проверьте:

• Ввод: строка отправлена целиком, пробелы и регистр обрабатываются предсказуемо.

• Анализ запроса: не удаляет ли нормализация значимую часть слова или единицы измерения.

• Индекс: есть ли в нем нужный ID, название и дата последнего обновления.

• Фильтры: не исключают ли товар регион, наличие, категория или статус публикации.

• Выдача: совпал ли товар, не оказался ли за пределом страницы, не затер ли его сортировочный или пагинационный механизм.

• Интерфейс: правильно ли ответ отображен и не остался ли старый пустой экран после получения результата.

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

После каждой правки запускайте регрессию

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

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

Что смотреть после запуска

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

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

Учебный пример и технические факты

Каталог «Домашняя мастерская», ID T-101–T-108, поисковые формулировки, ожидаемые результаты и описанные сбои придуманы для статьи. Они не получены из аналитики Ready4site или другого магазина. Проверенная техническая часть ограничена общими положениями: поисковые системы могут по-разному анализировать слова, применять словари нормализации и синонимов, а некоторые реализации поддерживают нечеткое совпадение по ограниченному числу изменений символов. Наличие и поведение этих функций нужно проверять в документации именно той платформы и конфигурации, которая используется в магазине.

Практический результат такого теста – не магическое «умный поиск», а короткий список повторяемых проверок: что магазин обязан находить, чего не должен показывать и как подтвердить, что исправление сохранило остальные сценарии.

Схема. Последовательность проверки внутреннего поиска