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

Автор: Людмила Лебедева | Опубликовано: 07.09.2026

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

Ниже — рабочий сценарий: как найти проблемные URL, закрыть именно страницы результатов поиска, проверить, что ничего важного не сломалось, и не повторить типичные ошибки.

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

Сначала не трогайте код, а проверьте, что именно индексируется. В Google Search Console и Яндекс.Вебмастере ищите URL с параметром ?s= или похожими шаблонами. Часто это страницы вида / ?s=запрос, /search/запрос/ или URL с дополнительными параметрами сортировки и фильтрации.

Проблема обычно проявляется так:

в индексе есть десятки или сотни страниц поиска;
в выдаче видны пустые или почти пустые результаты;
в логах краулера много запросов к однотипным URL;
в отчётах по дублям появляются страницы, которые не должны ранжироваться.

Что именно закрывать

Закрывать нужно не сам поиск, а только страницы результатов поиска. Форма поиска, AJAX-поиск, фильтры в админке и внутренние механики темы должны остаться рабочими. Если у вас есть отдельная страница поиска с полезным контентом, например каталогом или справочником, её надо разбирать отдельно, а не закрывать по шаблону.

Пошаговое решение через `robots.txt` и `noindex`

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

Если вы правите тему или дочернюю тему, добавьте фильтр в functions.php или в небольшой mu-plugin. Пример ниже ставит noindex,follow только для страниц поиска:

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

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

Для более аккуратного варианта можно использовать фильтр WordPress на robots-мета:

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

    return $robots;
} );

Если у вас старый SEO-плагин, который управляет robots сам, проверьте его настройки. В некоторых случаях проще включить noindex для поисковых страниц в интерфейсе плагина, чем дублировать логику кодом.

Когда имеет смысл добавить правило в `robots.txt`

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

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

Но не ставьте сюда слишком широкие правила. Запрет вида Disallow: /?s может задеть другие параметры, если у вас нестандартная маршрутизация. И ещё раз: если URL уже в индексе, robots.txt сам по себе не гарантирует удаление.

Сравнение подходов

Подход	Плюсы	Минусы	Когда использовать
Код через `wp_robots`	Точно ставит noindex на поиск	Нужно проверить конфликт с SEO-плагином	Когда нужен контролируемый и предсказуемый вариант
`robots.txt`	Снижает обход мусорных URL	Не удаляет уже известные страницы из индекса	Как дополнительная мера
Настройки SEO-плагина	Без кода, удобно для редактора	Зависит от плагина и его возможностей	Если сайт уже живёт на SEO-плагине

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

После внедрения откройте несколько URL поиска вручную и проверьте исходный код страницы. В <head> должен появиться noindex. Если используете SEO-плагин, убедитесь, что он не выводит второй конфликтующий robots-тег.

Дальше проверьте:

страница поиска открывается и показывает результаты;
в исходнике есть noindex,follow или эквивалент;
в robots.txt нет правила, которое случайно блокирует нужные разделы;
в Search Console URL-ы поиска постепенно уходят из отчётов по индексированию;
в логах сервера нет ошибок после правки темы или mu-plugin.

Если хотите проверить быстро через консоль, можно посмотреть HTML страницы и найти robots-мета:

curl -sL 'https://example.com/?s=test' | grep -i robots

Для локальной проверки этого достаточно. На проде лучше ещё открыть страницу в браузере без кэша и посмотреть, не подменяет ли мета-теги кэш-плагин.

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

Ставят только `Disallow` в `robots.txt`

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

Закрывают слишком широкий шаблон

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

Конфликтуют SEO-плагин и код темы

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

Закрывают страницу поиска, но оставляют индексируемые результаты AJAX

Иногда поиск отдаёт данные через API или отдельный endpoint. Если он доступен по публичному URL и индексируется, его тоже нужно отдельно оценить. Исправление: проверьте не только шаблон поиска, но и все публичные адреса, которые он использует.

Практические советы по безопасности и производительности

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

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

Для безопасности не открывайте поиск на запись в базу без фильтрации. Сам по себе поиск в WordPress обычно безопасен, но сторонние плагины иногда добавляют сложные SQL-запросы. Любые кастомные изменения лучше держать в дочерней теме или отдельном mu-plugin, а не править ядро темы напрямую.

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

Проверили реальные URL поиска на сайте.
Добавили noindex именно для страниц поиска.
Не сломали форму поиска и вывод результатов.
Не создали конфликт с SEO-плагином.
Проверили исходный код страницы и отчёты в Search Console.
Убедились, что robots.txt не блокирует нужные разделы.

Если нужен более широкий контроль над дублями, мета-тегами и технической чисткой сайта, часть задач можно закрывать через Clearfy Pro: https://wpshop.ru/plugins/clearfy?utm_source=wp-lessons.ru&utm_medium=article&utm_campaign=zakryt-ot-indeksacii-stranitsy-poiskovoy-vydachi-wordpress

Изучение WordPress: детальные уроки и нужные советы.