Страницы внутреннего поиска в WordPress часто попадают в индекс сами по себе: у них есть уникальные URL с параметром ?s=, они генерируют тонкие страницы без ценности для поиска и быстро плодят дубли. Если сайт уже начал собирать такие URL в отчётах, лучше не ограничиваться одним robots.txt: поисковики могут видеть ссылку, а пользовательский поиск при этом должен продолжать работать.
Когда это действительно проблема
Сценарий обычно выглядит одинаково: в Search Console появляются URL вида / ?s=запрос, в логах видны переходы на страницы поиска, а в выдаче всплывают пустые или почти пустые результаты. Для небольшого сайта это ещё терпимо, но на контентных проектах такие страницы начинают размывать качество индекса и отнимать краулинговый бюджет.
Проверить, что проблема есть, можно быстро:
- выполните поиск по сайту в Google с оператором
site:example.com inurl:?s=; - посмотрите отчёт по страницам в Search Console;
- откройте несколько URL поиска вручную и проверьте, есть ли у них индексируемый HTML без явного
noindex; - убедитесь, что поиск нужен пользователям и его нельзя просто отключить.
Что именно нужно закрывать
Важно не перепутать внутренний поиск и обычные страницы сайта. Закрывать нужно именно результаты поиска по параметру s. Саму форму поиска, блоки поиска в шапке и виджеты трогать не надо. Если на сайте есть отдельная страница поиска с красивым URL, логика может отличаться, но для стандартного WordPress чаще всего речь идёт о запросах вида ?s=.
Почему одного robots.txt недостаточно
Disallow в robots.txt мешает обходу, но не гарантирует исключение из индекса, если URL уже известен поисковику. Для уже найденных страниц нужен либо noindex, либо корректный ответ сервера/мета-тег, либо редирект в тех сценариях, где поиск вообще не должен быть публичным. Поэтому лучше использовать связку из нескольких мер.
Рабочая схема: noindex для результатов поиска и запрет обхода
Самый безопасный вариант для обычного сайта — оставить поиск доступным пользователям, но добавить для его страниц noindex, follow и при необходимости закрыть их в robots.txt. Так поисковик видит, что индексировать страницу не нужно, но может перейти по ссылкам внутри результатов, если они есть.
Шаг 1. Добавить мета robots для страниц поиска
Вставьте код в functions.php дочерней темы или в собственный мини-плагин. Он добавит noindex, follow только для результатов поиска.
add_filter('wp_robots', function (array $robots) {
if (is_search()) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
});Если у вас старая тема, которая не выводит wp_head() или переопределяет robots вручную, сначала проверьте шаблон. В современных темах этот фильтр работает штатно.
Шаг 2. Закрыть обход в robots.txt, если это уместно
Это не обязательный шаг, но для шумных сайтов помогает снизить количество обходов. Добавьте правило через фильтр WordPress, чтобы не редактировать файл руками при каждом деплое.
add_filter('robots_txt', function ($output, $public) {
$output .= "\nUser-agent: *\nDisallow: /?s=\nDisallow: /search/\n";
return $output;
}, 10, 2);Здесь есть нюанс: если у вас поиск работает только через параметр ?s=, строка Disallow: /?s= может быть не идеальной для всех роботов, потому что robots.txt не всегда одинаково трактует параметры. Поэтому воспринимайте этот шаг как дополнительный, а не основной. Основной контроль — это noindex.
Шаг 3. Убедиться, что тема не ставит каноникал на главную
Некоторые темы и SEO-плагины для страниц поиска ставят странный canonical, например на главную или на саму страницу поиска без учёта запроса. Это может мешать обработке. Для поиска canonical обычно должен либо отсутствовать, либо быть осмысленным и не уводить на нерелевантный URL. Если SEO-плагин уже управляет canonical, не дублируйте логику в теме.
Сравнение подходов
| Подход | Плюсы | Минусы | Когда использовать |
|---|---|---|---|
| Только robots.txt | Просто, быстро | Не убирает уже известные URL из индекса | Как дополнительная мера |
noindex, follow | Корректно для индексации | Нужно проверить, что тег реально выводится | Основной вариант для обычного поиска |
| Редирект на главную | Жёстко убирает URL | Ломает пользовательский поиск | Только если поиск не нужен публично |
Если поиск вообще не должен быть публичным
На некоторых сайтах внутренний поиск используют только сотрудники или редакторы. Тогда проще не индексировать результаты, а отдавать 404/403 или редиректить на безопасную страницу. Но это уже другой сценарий: пользовательский поиск исчезает, и это надо делать осознанно.
Если задача именно скрыть поиск от внешнего мира, а не просто убрать из индекса, можно ограничить доступ по роли или по IP на уровне сервера. В WordPress это лучше решать не шаблоном, а инфраструктурой или отдельным плагином безопасности. Иначе легко сломать админский поиск, AJAX-запросы и интеграции.
Проверка результата после внедрения
После правки не ограничивайтесь визуальной проверкой страницы. Нужны три проверки:
- Откройте URL поиска в браузере и посмотрите исходный код страницы: в
<head>должен бытьnoindex. - Проверьте, что поиск по сайту всё ещё работает и выдаёт результаты пользователю.
- В Search Console отправьте URL на повторную проверку и посмотрите, как меняется статус через некоторое время.
Если используете командную строку, можно быстро проверить заголовки и HTML:
curl -I "https://example.com/?s=test"
curl -s "https://example.com/?s=test" | grep -i "robots\|canonical"В ответе ищите либо мета-тег robots, либо заголовки, если они добавляются на уровне сервера. Если ничего нет, значит фильтр не сработал или тема не выводит стандартные хуки WordPress.
Частые ошибки и как их исправить
Ошибка 1. Закрыли поиск в robots.txt, но не добавили noindex
В этом случае URL могут продолжать жить в индексе, если поисковик уже знает о них. Исправление простое: добавьте wp_robots или настройку SEO-плагина, которая ставит noindex именно на search pages.
Ошибка 2. Поставили noindex на все страницы сайта
Такое бывает, когда условие написано слишком широко, например без is_search(). Проверьте логику фильтра и не используйте глобальные настройки без точного условия.
Ошибка 3. Редиректнули поиск на главную
Это ломает UX: пользователь вводит запрос и попадает не туда, куда ожидал. Если поиск нужен, редирект не подходит. Если не нужен, лучше отключить его полностью и убрать форму из темы.
Ошибка 4. SEO-плагин и тема спорят между собой
Один код добавляет noindex, другой — canonical на главную, третий — собственный robots. В итоге поисковик получает противоречивые сигналы. Оставьте один источник правды: либо SEO-плагин, либо код в теме, но не оба сразу.
Что ещё стоит проверить для производительности и безопасности
Если внутренний поиск часто используется, он может нагружать базу данных. На больших сайтах имеет смысл проверить, не создаёт ли запрос слишком тяжёлые SQL-операции, особенно если тема добавляет поиск по метаполям или таксономиям. В таком случае лучше ограничить область поиска, добавить релевантные индексы на уровне MySQL или использовать более подходящий поисковый движок.
С точки зрения безопасности внутренний поиск тоже стоит держать под контролем: не выводите в результатах лишние приватные типы записей, черновики и служебные страницы. Если в теме есть кастомный поиск через pre_get_posts, проверьте, что он не открывает лишние типы контента.
Когда лучше не писать код вручную
Если на сайте уже стоит SEO-плагин с понятными настройками для search pages, проще использовать его. Например, в экосистеме WPShop есть Clearfy Pro, который закрывает типовые задачи по чистке сайта и управлению дублями. Но даже в этом случае полезно понимать, что именно делает плагин: иногда настройка в интерфейсе не заменяет проверку исходного HTML и индексации.
Главный критерий простой: после изменений страница поиска должна остаться рабочей для пользователя, но перестать быть целевой страницей для индекса. Если это условие выполнено, задача решена правильно.