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

Внутренний поиск WordPress часто создаёт страницы, которые поисковики начинают обходить и индексировать как отдельные URL. Для сайта это обычно лишний шум: в индексе появляются страницы вида ?s=, а иногда ещё и пагинация поиска, пустые результаты и дубли с разными параметрами. Сам поиск при этом продолжает работать для пользователей, но SEO-сигнал размазывается.

Задача здесь не в том, чтобы «спрятать всё подряд», а в том, чтобы аккуратно закрыть именно поисковые страницы от индексации, при этом не поломать навигацию и не создать конфликтов с кешем, каноникалами и плагинами SEO.

Когда это действительно проблема

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

  • в выдаче есть URL с параметром ?s= и пустым или почти пустым сниппетом;
  • поисковик индексирует страницы поиска по редким запросам, которые не несут ценности;
  • один и тот же результат доступен через разные параметры и создаёт дубли;
  • внутренний поиск отдаёт 200 OK даже на заведомо пустые запросы, и бот воспринимает это как обычную страницу.

Как быстро диагностировать

Начните с простого ручного теста. Откройте поиск на сайте и посмотрите, какой URL формируется после отправки запроса. Обычно это /?s=текст или что-то похожее, если тема или плагин меняли шаблон ссылок. Затем проверьте ответ сервера и мета-теги.

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

Если страница отдаёт 200 OK и не содержит noindex, поисковик может рассматривать её как полноценную посадочную. Это не всегда ошибка, но для большинства сайтов внутренний поиск не должен попадать в индекс.

Ещё один полезный тест — посмотреть исходный код страницы поиска и найти:

  • <meta name="robots" content="noindex,follow">;
  • канонический URL;
  • нет ли лишних параметров в ссылках пагинации;
  • не подмешивает ли SEO-плагин свой robots-мета-тег поверх вашего кода.

Что лучше: robots.txt, noindex или код

Для страниц поиска WordPress обычно не хватает одного только robots.txt. Он может ограничить обход, но не гарантирует исключение URL из индекса, особенно если на него уже есть внешние или внутренние ссылки. Поэтому рабочая схема чаще строится вокруг noindex на самих страницах и аккуратной настройки robots.txt как дополнительного слоя.

ПодходЧто делаетПлюсыМинусы
robots.txtЗапрещает обходПросто внедритьНе всегда убирает URL из индекса
noindexПросит не индексировать страницуНадёжнее для SEO-задачиНужно правильно отдать мета-тег или заголовок
Код в теме/плагинеТочечно управляет логикойГибко и без лишних плагиновТребует аккуратности и теста после обновлений

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

Пошаговое решение через код

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

add_filter('wp_robots', function (array $robots): array {
    if (is_search()) {
        $robots['noindex'] = true;
        $robots['follow']  = true;
    }

    return $robots;
});

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

Если вам нужно дополнительно убрать страницы поиска из sitemap или внутренних ссылок, это уже отдельная задача. Не смешивайте её с noindex: сначала закройте индексацию, потом проверьте, нет ли лишних ссылок на поисковые URL в шаблоне, виджетах и хлебных крошках.

Если нужен более жёсткий вариант

Иногда владельцы сайтов хотят не просто noindex, а ещё и отдавать 404 или 410 для пустых поисковых запросов. Делать это стоит осторожно: если пользовательский поиск используется активно, жёсткий ответ может ухудшить UX и сломать аналитику. Но для технического мусора вроде пустого запроса это допустимо.

add_action('template_redirect', function () {
    if (!is_search()) {
        return;
    }

    $query = get_search_query(false);

    if ($query === '') {
        status_header(404);
        nocache_headers();
        include get_query_template('404');
        exit;
    }
});

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

Настройка robots.txt: когда она помогает, а когда нет

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

User-agent: *
Disallow: /?s=
Disallow: /*?s=

На практике такой вариант не всегда универсален: разные боты по-разному трактуют шаблоны, а некоторые URL могут иметь дополнительные параметры. Поэтому после правки robots.txt обязательно проверьте, что:

  • поиск по сайту для людей не сломался;
  • страницы поиска всё ещё отдают корректный HTML;
  • в индексе не осталось старых URL, которые нужно убрать через noindex или удаление ссылок;
  • SEO-плагин не генерирует конфликтующие директивы.

Проверка результата после внедрения

После изменения не ограничивайтесь просмотром кода в браузере. Нужна проверка на уровне ответа сервера и итогового HTML.

  1. Откройте страницу поиска с реальным запросом.
  2. Посмотрите исходный код и убедитесь, что есть noindex,follow.
  3. Проверьте заголовки ответа через curl -I или DevTools.
  4. Убедитесь, что канонический URL не указывает на нерелевантную страницу.
  5. Проверьте, не попала ли страница в sitemap.

Пример проверки robots-мета через командную строку:

curl -s "https://example.com/?s=test" | grep -i "robots\|canonical"

Если вы используете SEO-плагин, проверьте его интерфейс и исходный код одновременно. Иногда настройка в админке выглядит корректной, но на фронтенде остаётся старый кэш или другой плагин подменяет мета-теги.

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

Закрыли только robots.txt

Это самая частая ошибка. Бот может перестать обходить страницу, но уже найденный URL останется в индексе. Исправление: добавьте noindex на саму страницу поиска и дайте поисковику переобойти URL.

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

Такое случается, если фильтр написан слишком широко и не ограничен is_search(). В результате поисковик теряет нормальные страницы. Исправление: проверьте условие и тестируйте на нескольких типах URL.

Не учли кэш

После правки код может быть правильным, но в браузере и на CDN всё ещё отдаётся старая версия. Исправление: очистите кеш плагина, серверный кеш и, если есть, CDN.

SEO-плагин конфликтует с вашим кодом

Если плагин уже управляет robots-мета, ваш фильтр может не дать ожидаемого результата. Исправление: оставьте один источник правды. Либо настройка в плагине, либо код, но не оба варианта одновременно без проверки.

Путают noindex и disallow

noindex управляет индексацией, Disallow — обходом. Это разные вещи. Если цель — убрать URL из выдачи, одного Disallow часто недостаточно.

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

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

Полезно также проверить, не создаёт ли поиск утечки информации: иногда в результаты попадают черновики, приватные типы записей или служебные страницы. Это уже не SEO, а вопрос доступа к контенту. Для таких случаев лучше отдельно ограничить выдачу через pre_get_posts или настройки типа записей.

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

Когда нужен быстрый способ убрать дубли и служебные страницы без ручной сборки набора правил, можно посмотреть в сторону инструментов вроде Clearfy Pro, но только если его функции действительно закрывают вашу задачу и не конфликтуют с текущим SEO-стеком.

Главный критерий успеха здесь простой: страницы поиска перестают быть отдельной SEO-единицей, но остаются рабочими для пользователя. Если после правки поиск открывается, а в исходнике есть noindex,follow и нет новых дублей в индексе, значит настройка сделана правильно.

Как отключить архивы дат в WordPress и убрать дубли страниц
13.09.2026
Как закрыть дубли страниц авторов в WordPress через robots.txt и noindex
03.09.2026
Как отключить XML-RPC в WordPress и проверить, что он действительно закрыт
06.09.2026
Как закрыть страницы поиска WordPress от индексации и убрать дубли в выдаче
10.09.2026
Как отключить XML sitemap в WordPress и заменить его своим вариантом
10.09.2026