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

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

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

Типичный сценарий выглядит так: в индексе появляются страницы с запросами, которые не должны ранжироваться, в Search Console растёт число URL с параметром s, а в логах видно, что поисковые боты регулярно заходят на результаты поиска. Это не всегда критично, но на небольших и средних сайтах такие страницы часто создают шум: расходуют краулинговый бюджет, плодят дубли и мешают анализу реальных посадочных страниц.

Что именно нужно проверить в первую очередь

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

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

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

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

Пошаговое решение: закрываем поиск от индексации правильно

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

Вариант 1: добавить noindex через WordPress-хуки

Если не хотите трогать шаблон search.php, можно добавить мета-robots через wp_head. Этот способ не ломает вывод страницы, но даёт поисковикам сигнал не индексировать результаты поиска.

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

Такой код лучше размещать в дочерней теме или в небольшом mu-plugin, а не в основной теме, если она часто обновляется. Если на сайте уже есть SEO-плагин, проверьте, не выводит ли он собственный noindex для поиска — двойная логика иногда приводит к путанице при отладке.

Вариант 2: запретить индексирование через robots.txt

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

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

Используйте этот вариант только если у вас действительно есть постоянный путь поиска вида /search/. Для стандартного WordPress-поиска с параметром ?s= robots.txt работает ограниченно, потому что директива не всегда покрывает все варианты параметров. Поэтому основная ставка всё равно должна быть на noindex в HTML-ответе.

Вариант 3: вернуть 404 или 410 для пустого поиска

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

<?php
add_action( 'template_redirect', function () {
    if ( is_search() ) {
        $query = get_search_query( false );

        if ( $query === '' ) {
            global $wp_query;
            $wp_query->set_404();
            status_header( 404 );
            nocache_headers();
            include get_query_template( '404' );
            exit;
        }
    }
} );

Этот вариант стоит применять осторожно: если у вас есть реальные пользователи, которые иногда попадают на пустой поиск, лучше не ломать UX без необходимости. Для большинства сайтов достаточно noindex,follow и нормальной обработки запросов.

Что делать с каноникалом и пагинацией поиска

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

Проверьте, не добавляет ли SEO-плагин canonical на главную или на базовую страницу сайта для всех поисковых URL. Это бывает полезно в некоторых конфигурациях, но иногда создаёт странные сигналы для поисковиков, особенно если поисковый шаблон отдаёт уникальный контент и пагинацию.

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

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

• Откройте URL поиска с реальным запросом и посмотрите исходный код страницы.
• Убедитесь, что в <head> есть <meta name="robots" content="noindex,follow" />.
• Проверьте, что страница отдаёт код 200, если вы не планировали 404.
• Посмотрите, не конфликтует ли canonical с URL поиска.
• В Search Console отправьте проверку URL и дождитесь повторного обхода.

Для быстрой проверки можно использовать curl:

curl -I "https://example.com/?s=тест"

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

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

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

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

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

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

Закрывают поиск через 404 без анализа

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

Дублируют правила в теме, плагине и SEO-модуле

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

Не проверяют кэш

Если на сайте есть page cache, CDN или серверный кэш, изменения в wp_head могут не попасть в выдачу сразу. После правки очистите все уровни кэша и проверьте HTML заново.

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

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

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

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