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

Страницы вида ?s=запрос часто становятся мусорными URL в индексе: поисковики видят их как отдельные страницы, а на сайте они не несут самостоятельной ценности. Но закрывать их «в лоб» через robots.txt или массовый noindex без проверки — плохая идея: можно случайно задеть полезные посадочные, внутренний поиск по каталогу или страницы фильтрации, если они завязаны на похожую логику.

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

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

Речь не о любой странице с результатами поиска, а именно о стандартных URL WordPress с параметром s. Обычно это страницы, которые:

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

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

Диагностика: как понять, что проблема именно в поисковых URL

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

Что проверить в Search Console и логах

В Google Search Console откройте отчёт по страницам и найдите URL с параметром s=. Если они уже в индексе, обычно видно один из сценариев:

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

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

Быстрая проверка на сайте

Откройте исходный код страницы поиска и найдите мета-тег robots. Если его нет, WordPress сам по себе не запрещает индексацию таких страниц. Также проверьте, не добавляет ли SEO-плагин свои правила для поиска — иногда настройка уже есть, но она отключена.

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

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

Если задача — именно убрать страницы поиска из индекса, надёжнее использовать noindex, а не только Disallow в robots.txt. Блокировка в robots не даёт поисковику увидеть директиву noindex, если страница уже известна.

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

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

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

    return $robots;
} );

Этот вариант не трогает обычные страницы сайта и не вмешивается в шаблоны. Добавлять код лучше не в functions.php активной темы, а в небольшой mu-plugin или в собственный плагин, чтобы настройка не исчезла после смены темы.

Если нужен старый совместимый вариант

На проектах со старым стеком иногда используют фильтр wp_head. Он тоже рабочий, но менее аккуратный, чем wp_robots.

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

Используйте его только если по какой-то причине нельзя опереться на wp_robots. Дублировать оба варианта одновременно не нужно.

Что делать, если поиск сделан через плагин

Некоторые темы и плагины подменяют стандартный поиск WordPress на AJAX-форму или отдельную страницу результатов. Тогда проверяйте не только is_search(), но и то, как формируется URL. Если поиск уходит на отдельный путь, логика закрытия может быть другой: иногда достаточно настроить сам плагин, иногда нужен отдельный шаблон с noindex.

Практический ориентир простой: если URL меняется и остаётся уникальным для каждого запроса, он почти всегда кандидат на noindex. Если же поиск используется как внутренний инструмент и не должен попадать в выдачу, не пытайтесь «спрятать» его через JavaScript — это не решает задачу индексации.

Чек-лист после внедрения

• Откройте страницу поиска и проверьте исходный код.
• Убедитесь, что в <head> есть noindex для поисковых URL.
• Проверьте, что обычные страницы сайта не получили этот тег.
• Сделайте запрос в Search Console на повторную проверку после обновления страницы.
• Посмотрите, не остались ли в индексе старые URL поиска — их удаление может занять время.

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

Самая надёжная проверка — открыть страницу поиска в браузере и посмотреть исходный код. В идеале вы должны увидеть:

<meta name="robots" content="noindex, nofollow" />

Если используете SEO-плагин, проверьте, не конфликтует ли он с вашим кодом. Иногда плагин переопределяет robots-мета или добавляет свои директивы. После этого проверьте URL через инструмент проверки в Search Console: там должно быть видно, что страница не предназначена для индексации.

Дополнительно можно проверить ответ сервера:

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

Здесь важно не столько наличие X-Robots-Tag, сколько то, что страница отдаёт корректный HTML и не редиректит на неожиданный URL.

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

Закрыли поиск через robots.txt и ждёте удаления из индекса

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

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

Такое бывает, когда код добавляют без проверки условия is_search(). В результате поисковик перестаёт индексировать весь сайт. Перед выкладкой обязательно тестируйте на staging или хотя бы на одной тестовой странице.

Сломали поиск для пользователей

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

Дублируете директивы в нескольких местах

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

Безопасность и производительность: что учесть

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

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

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

В итоге задача сводится к одному: закрыть именно поисковые страницы, оставить поиск рабочим для посетителей и не создавать лишних конфликтов с SEO-плагинами и шаблонами. После внедрения обязательно проверьте исходный код, Search Console и поведение формы поиска — это быстрее, чем потом разбирать последствия в индексе.