Как запретить индексацию внутренних поисковых страниц в WordPress

Автор: Дарья Николаева | Опубликовано: 30.08.2026

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

Решение зависит от того, как у вас устроен поиск: через стандартный ?s=, через отдельный шаблон темы, через AJAX или через плагин. Ниже — рабочий сценарий для WordPress без выдуманных хуков и без ломки поиска для пользователей.

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

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

в выдаче есть URL вида / ?s=запрос или /search/запрос/;
поисковик индексирует страницы с пустым результатом;
один и тот же запрос доступен по нескольким адресам: с параметрами, со слешем, с кодировкой;
в отчётах много страниц с низкой ценностью и одинаковым шаблоном title;
внутренний поиск открывается по GET-параметрам, а не через отдельный контролируемый маршрут.

Что проверить до правок

Откройте несколько поисковых URL вручную и посмотрите, что отдаёт сервер и что видит робот:

есть ли заголовок noindex;
не закрыт ли поиск случайно через robots.txt так, что страница всё равно уже в индексе;
не создаёт ли тема отдельный архив поиска с дублирующим canonical;
не генерирует ли плагин SEO свои правила поверх ваших.

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

Какой способ выбрать: плагин, код или шаблон

Подход	Когда подходит	Плюс	Минус
SEO-плагин	Если уже используете Yoast, Rank Math или похожий инструмент	Быстро и без правки темы	Нужно проверить, не конфликтует ли с шаблоном поиска
Код в теме или mu-plugin	Если нужен точечный контроль	Прозрачно и предсказуемо	Нужно аккуратно тестировать после обновлений
robots.txt	Только как дополнительная мера	Просто закрыть обход	Не решает уже проиндексированные URL

Если задача — именно убрать внутренний поиск из индекса, самый надёжный вариант: поставить noindex, follow на страницы поиска и оставить их доступными для пользователей. Так вы не ломаете UX, но даёте поисковику понятный сигнал.

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

Ниже пример для стандартного поиска WordPress. Его удобно добавить в functions.php дочерней темы или, лучше, в маленький mu-plugin, чтобы не потерять правку при обновлении темы.

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

    return $robots;
});

add_filter('wpseo_robots', function ($robots) {
    if (is_search()) {
        return 'noindex,follow';
    }

    return $robots;
});

add_filter('rank_math/frontend/robots', function (array $robots) {
    if (is_search()) {
        $robots['index'] = 'noindex';
        $robots['follow'] = 'follow';
    }

    return $robots;
});

Здесь есть два слоя. Первый — штатный фильтр WordPress wp_robots. Второй и третий — на случай, если на сайте стоит Yoast SEO или Rank Math и они перезаписывают robots-мета. Не обязательно держать все три блока, но на реальных проектах это часто экономит время на поиске конфликта.

Если поиск у вас не стандартный

Некоторые темы и плагины выводят поиск по отдельному шаблону, например /search/term/. В этом случае полезно добавить canonical на саму страницу поиска или вообще отдавать noindex через шаблон:

<?php
if (is_search()) {
    echo '<meta name="robots" content="noindex,follow" />' . "\n";
}

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

Что делать с robots.txt

Закрывать поиск в robots.txt можно, но только как дополнительную меру. Например, чтобы уменьшить обход мусорных URL, если поисковик уже слишком активно ходит по параметрам:

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

Проблема в том, что robots.txt не удаляет уже проиндексированные страницы. Если URL уже в поиске, сначала нужен noindex или корректный canonical, а потом — переобход. Иначе вы просто запретите роботу увидеть сигнал на удаление.

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

После правки не ограничивайтесь просмотром исходника в браузере. Проверьте несколько вещей отдельно:

Откройте поисковый URL и убедитесь, что в HTML есть noindex,follow.
Проверьте заголовки ответа через DevTools или curl -I, если у вас есть доступ к серверу.
Посмотрите canonical: он не должен указывать на нерелевантную страницу.
В Search Console отправьте URL на проверку переобхода, если он уже был в индексе.

Пример проверки через консоль:

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

В ответе вы не увидите noindex, если он задан только в HTML, но сможете проверить статус, редиректы и кеширование. Сам HTML лучше смотреть через curl без -I или прямо в исходнике страницы.

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

Закрыли поиск в robots.txt, но страницы остались в индексе. Это нормальная ситуация. Добавьте noindex и дождитесь переобхода.
Поставили noindex только в теме, а SEO-плагин перезаписал мета-тег. Проверьте настройки Yoast SEO или Rank Math и уберите конфликтующий шаблон.
Закрыли весь поиск, хотя он нужен пользователям. Не отключайте сам функционал. Закрывайте только индексацию, а не доступ.
Canonical указывает на главную или на случайную страницу. Это часто делает тема. Исправьте шаблон поиска или отключите лишнюю логику canonical.
Поиск отдаёт пустые страницы с 200 OK. Если это массово, подумайте о редиректе пустых запросов на страницу поиска без параметра или на страницу с подсказкой.

Когда лучше не трогать поиск кодом

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

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

Практический чек-лист перед публикацией правки

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

Если нужен более широкий контроль над дублями, мета-данными и технической чисткой сайта, в экосистеме WPShop есть Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже с плагином полезно понимать, где именно у вас генерируется индексируемый поиск и кто пишет robots-мета.

В итоге задача сводится не к «запретить всё», а к тому, чтобы оставить поиск рабочим для людей и убрать его из индекса там, где он создаёт мусор. На WordPress это обычно решается одной аккуратной правкой и нормальной проверкой результата.