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

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

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

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

• URL вида /?s=запрос;
• страниц поиска с пустой выдачей;
• поиска по коротким и нерелевантным запросам;
• сайтов, где поиск генерирует много почти одинаковых страниц.

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

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

Перед правками проверьте, какие URL уже попали в индекс и как они выглядят для поисковика. Обычно достаточно трёх проверок:

1. Выполнить поиск по сайту в Google с оператором site:example.com inurl:?s=.
2. Открыть несколько страниц поиска вручную и посмотреть исходный код: есть ли meta name="robots" и какой у него content.
3. Проверить, не отдает ли тема или SEO-плагин каноникал на главную страницу вместо текущего поиска.

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

Что выбрать: noindex, robots.txt или оба варианта

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

Пошаговое решение без плагина

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

1. Добавьте noindex для страниц поиска

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

    return $robots;
} );

Этот код использует стандартный фильтр wp_robots, который есть в современных версиях WordPress. Он не ломает вывод на обычных страницах и срабатывает только для поиска.

2. Ограничьте обход в robots.txt

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

<?php
add_filter( 'robots_txt', function( string $output, bool $public ) {
    if ( ! $public ) {
        return $output;
    }

    $output .= "\nDisallow: /?s=";
    $output .= "\nDisallow: /search/";

    return $output;
}, 10, 2 );

Здесь важно не переборщить. Если на сайте есть отдельная страница поиска вроде /search/, проверьте, не используется ли она как полезный раздел. Запрещайте только те URL, которые действительно являются техническими.

3. Уберите лишние ссылки на поиск из шаблона

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

Если используется SEO-плагин

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

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

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

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

• Откройте страницу поиска и проверьте исходный код: должен быть noindex.
• Посмотрите заголовки ответа сервера: страница должна отдавать обычный 200 OK, если вы не делали редирект.
• Проверьте robots.txt по адресу /robots.txt и убедитесь, что там нет лишних правил.
• В Search Console отправьте URL на проверку и посмотрите, как робот читает страницу.

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

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

Закрыли поиск в robots.txt, но URL всё равно в индексе

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

Поставили редирект с поиска на главную

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

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

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

Добавили несколько конфликтующих правил

Если SEO-плагин ставит noindex, тема добавляет свой canonical, а robots.txt ещё и запрещает обход, поисковику становится сложнее понять приоритет. Уберите дублирование: один источник отвечает за robots-мета, другой — за ограничение обхода, и не больше.

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

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

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

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

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

• Проверен текущий статус страниц поиска в индексе.
• Добавлен noindex, follow только для is_search().
• Не сломан обычный поиск по сайту.
• В robots.txt нет лишних запретов на полезные разделы.
• Canonical не указывает на нерелевантную страницу.
• После правок страница поиска открывается с 200 OK и корректным robots-мета.

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

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