Как закрыть страницы поиска в WordPress от индексации без поломки внутреннего поиска

Страницы поиска в WordPress часто попадают в индекс сами по себе: у них есть уникальные URL с параметром ?s=, но ценности для поиска они обычно не несут. Проблема в том, что закрыть их «в лоб» можно так, что сломается поиск по сайту, появятся лишние редиректы или поисковик продолжит видеть мусорные URL через ссылки в шаблоне.

Ниже — рабочие способы для типового сайта на WordPress: от простого noindex до точечной доработки шаблона и заголовков. Без лишней магии, только то, что реально можно проверить после внедрения.

Когда страницы поиска становятся проблемой

Сценарий обычно один и тот же: пользователь вводит запрос, WordPress показывает URL вида / ?s=запрос или /search/запрос/, а в панели вебмастера начинают копиться страницы с тонким или дублирующимся контентом. Если на сайте много внутренних ссылок на поиск, такие URL могут быстро расползаться по индексу.

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

Что именно нужно проверить до изменений

какой формат URL у поиска: ?s=, /search/ или кастомный;
есть ли в шаблоне ссылки на поиск в шапке, футере, сайдбаре;
не используется ли поиск как часть навигации по контенту;
есть ли у поисковой выдачи отдельный шаблон search.php;
не закрыт ли уже поиск через robots.txt или SEO-плагин.

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

Сначала стоит понять, откуда поисковик вообще узнает о страницах поиска. Чаще всего причина не в самом WordPress, а в шаблоне темы или плагине: ссылки на поиск открыты для обхода, а на страницах нет noindex или канонического URL.

Проверка занимает несколько минут:

Откройте страницу поиска в браузере и посмотрите исходный код.
Найдите тег <meta name="robots".
Проверьте заголовок ответа на наличие X-Robots-Tag.
Посмотрите, не стоит ли на странице каноникал на саму себя или на главную без логики.
Проверьте, не генерирует ли тема отдельные SEO-метки для поиска.

Если у вас есть доступ к консоли, полезно посмотреть заголовки ответа:

curl -I https://example.com/?s=test

В ответе важно увидеть либо X-Robots-Tag: noindex, либо корректный <meta name="robots" content="noindex,follow"> в HTML. Если ничего нет, поисковик будет решать сам, и это обычно не в вашу пользу.

Рабочие способы закрыть поиск от индексации

Есть три нормальных подхода: через SEO-плагин, через код в теме или через заголовок ответа сервера. Выбор зависит от того, насколько у вас контролируемый проект и есть ли уже SEO-обвязка.

Способ	Когда подходит	Плюсы	Минусы
SEO-плагин	Если уже используется Yoast, Rank Math или аналог	Быстро, без правки темы	Зависит от настроек и версии плагина
Код в теме	Если нужен точечный контроль	Прозрачно, не тянет лишние зависимости	Нужно следить за обновлениями темы
X-Robots-Tag	Если нужен жесткий запрет на уровне ответа	Работает даже без изменения HTML	Нужно аккуратно настроить сервер

Вариант 1. Добавить noindex через код

Если вы не хотите зависеть от плагина, можно добавить мета-роботы только для страниц поиска. Для классической темы это делается через wp_head:

add_action('wp_head', function () {
    if (is_search()) {
        echo '<meta name="robots" content="noindex,follow">' . "\n";
    }
});

Этот вариант простой и понятный. follow оставляет поисковику возможность переходить по ссылкам со страницы поиска, если они там есть. Если вам это не нужно, можно использовать noindex,nofollow, но в большинстве случаев это избыточно.

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

Вариант 2. Отдать X-Robots-Tag в заголовке

Этот способ полезен, если вы хотите закрыть поиск независимо от HTML-шаблона. Он особенно удобен на сайтах, где часть страниц отдается не через стандартный шаблон темы, а через кастомные контроллеры или кэш-прокси.

add_action('template_redirect', function () {
    if (is_search()) {
        header('X-Robots-Tag: noindex, follow', true);
    }
});

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

Вариант 3. Настроить SEO-плагин

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

После настройки откройте страницу поиска и проверьте:

есть ли noindex в HTML или заголовке;
не пропал ли сам поиск для пользователя;
не изменился ли canonical на нерелевантный URL;
не появились ли ошибки в консоли браузера или логах сервера.

Пошаговое решение для типового сайта

Если нужен практический порядок действий, я бы делал так:

Проверить, как именно выглядит URL поиска на сайте.
Убедиться, что поиск нужен пользователям и его не надо отключать полностью.
Добавить noindex,follow через код или SEO-плагин.
Проверить исходный код и заголовки ответа.
Очистить кэш страницы, объекта и CDN, если он есть.
Переобойти проблемные URL в панели вебмастера и посмотреть, ушли ли они из индексации.

Если у вас есть доступ к файлам темы, лучше вынести код в дочернюю тему или в небольшой mu-plugin. Так изменения не потеряются после обновления.

<?php
/**
 * Plugin Name: Search Noindex for WordPress
 */
add_action('wp_head', function () {
    if (is_search()) {
        echo '<meta name="robots" content="noindex,follow">' . "\n";
    }
});

Такой мини-плагин удобен тем, что его легко отключить и проверить влияние отдельно от темы.

Как проверить, что решение сработало

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

в исходном коде есть noindex;
в заголовках ответа нет противоречащих директив;
поиск по сайту по-прежнему работает для обычного пользователя.

Если используете Search Console или аналогичный инструмент, не ждите мгновенного исчезновения URL. Сначала поисковик должен заново обойти страницу и увидеть новые директивы. До этого в отчётах может сохраняться старая информация.

Хорошая практическая проверка — открыть несколько запросов разной длины и с разными символами, например латиницу, кириллицу и запрос с пробелом. Иногда проблема проявляется только на части URL, если тема или плагин по-разному кодируют параметры.

Частые ошибки и как их исправить

Закрыли поиск через robots.txt

Это частая ошибка. Если запретить обход через robots.txt, поисковик может не увидеть noindex на самой странице. В итоге URL может продолжать жить в индексе как «известный, но не просканированный». Для удаления из индекса лучше использовать директивы на самой странице или в заголовке ответа.

Поставили noindex на все страницы сайта

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

Оставили старый кэш

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

Сломали поиск редиректом на главную

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

Что учесть для безопасности и производительности

Сам по себе noindex почти не влияет на скорость, но код в wp_head и template_redirect должен быть минимальным. Не добавляйте туда тяжёлые запросы к базе или проверки внешних сервисов. Для такой задачи это лишнее.

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

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

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