Человек вводит название услуги, нажимает «Найти» и получает пустой экран. Формально поиск завершился. На практике разговор с сайтом оборвался именно там, где посетитель яснее всего обозначил свой интерес. Мы предлагаем проектировать этот момент не как ошибку пользователя, а как отдельный сценарий: что человек поймёт и что сможет сделать дальше?
Сначала определите, где именно ищет сайт
Поле с лупой часто обещает больше, чем выполняет. Если оно просматривает только названия статей, а не услуги, документы и весь текст страниц, это должно быть понятно рядом с полем. «Поиск в журнале» точнее универсального «Поиск», когда другие материалы не входят в его область. Для небольшого сайта хорошо упорядоченный архив статей иногда полезнее сложной формы, которая скрывает свои ограничения.
Перед разработкой составьте несколько обычных запросов: точное название, общая тема, другое написание, слово, которого на сайте нет. Определите, какие материалы должны появиться в каждом случае. Это редакционная договорённость, а не обещание, что алгоритм догадается о любом намерении.
Сохраните запрос и разделите разные состояния
После поиска текст стоит оставить в поле. Человек сможет изменить одно слово, а не набирать всё заново. Пустой запрос, загрузка, отсутствие совпадений и техническая ошибка требуют разных сообщений. «Ничего не найдено» не должно маскировать недоступный сервер: в такой ситуации мы ещё не знаем, существуют ли результаты.
Для поиска с фильтрами покажите активные ограничения. Ноль материалов в выбранной категории не означает, что их нет на всём сайте. Предложите отдельное действие «Сбросить фильтры», которое не стирает введённый текст. Так посетитель понимает, что именно изменится после нажатия.
Предложите несколько честных путей вместо стены советов
Лаконичный экран без результатов может содержать сам запрос, объяснение границ поиска и два следующих шага: изменить формулировку или открыть тематический раздел. Не нужно сразу показывать десятки случайных карточек. Если вы предлагаете близкие темы, назовите их рекомендациями, а не точными совпадениями.
Условный пример для студии: по слову «перезапуск» ничего нет, но доступны разделы о поддержке и обновлении сайта. Их можно предложить как альтернативный маршрут, не подменяя ответ и не объявляя найденным то, что не соответствует запросу. Названия ссылок должны объяснять содержание, как в нашем материале про понятные ссылки.
Поле ввода не является готовым поисковым механизмом
MDN описывает input type="search" как поле для ввода поискового запроса. Сам тип поля не создаёт индекс и не определяет, как сопоставлять слова с материалами. Эту логику нужно реализовать отдельно. Полю также нужно понятное название: пример внутри пустого поля не стоит делать единственным объяснением его назначения.
Если результаты обновляются без перезагрузки, краткое сообщение об их количестве или отсутствии нужно сделать доступным вспомогательным технологиям без принудительного переноса фокуса. Именно такие сообщения W3C рассматривает в пояснении критерия 4.1.3. Это не означает, что весь список результатов нужно озвучивать как одно сообщение.
Проверьте путь, а не только наличие лупы
Пройдите сценарий на узком экране и с клавиатуры: введите запрос, запустите поиск, исправьте его, сбросьте фильтр, откройте результат и вернитесь. Убедитесь, что кнопки не исчезают за экранной клавиатурой, длинные названия не перекрывают соседние элементы, а сообщения не скачут перед глазами после каждого символа.
Отдельно проверьте запросы на языках сайта и не скрывайте границы между языковыми разделами. Хороший поиск не обязан угадывать всё. Его практическая ценность в том, что человек видит границы ответа, не теряет сделанного и понимает следующий шаг даже при нулевом результате.