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

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

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

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

Не каждый URL поиска нужно запрещать одинаково. На небольшом сайте это может быть просто технический шум, а на контентном проекте — сотни адресов с разными запросами, которые не несут ценности для индексации. Особенно это заметно, если поиск доступен по GET-параметру ?s= и на сайте есть автогенерация ссылок на результаты поиска из шаблона или виджетов.

Типичные признаки

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

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

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

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

• поиск через форму на сайте;
• страница с пустым запросом;
• страница с редким запросом;
• URL с дополнительными параметрами, если они есть.

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

<?php
// Быстрая проверка в шаблоне или через временный mu-plugin.
if ( is_search() ) {
    error_log( 'Search URL: ' . home_url( add_query_arg( null, null ) ) );
}

Этот приём не для продакшена, а для диагностики. Он помогает увидеть, какие именно адреса формируются в реальности, а не в теории.

Рабочие способы закрыть поиск от индексации

Есть три нормальных подхода: через SEO-плагин, через код темы или плагина, и через серверные заголовки/robots. На практике чаще всего достаточно первого или второго варианта. Ниже — без лишней экзотики.

Вариант 1: noindex через WordPress-хук

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

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

    return $robots;
} );

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

Вариант 2: запрет через SEO-плагин

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

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

Вариант 3: robots.txt как дополнительный слой

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

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

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

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

1. Определите, какой формат поиска используется: ?s= или ЧПУ.
2. Проверьте, есть ли уже noindex в исходном коде страницы поиска.
3. Выберите один основной способ: SEO-плагин или код через wp_robots.
4. Если нужно, добавьте robots.txt как вторичную меру, но не вместо noindex.
5. Очистите кеш страницы и кеш CDN, если он есть.
6. Переобойдите URL в Search Console и проверьте ответ сервера и мета-теги.

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

Проверка должна быть не «вроде исчезло», а по конкретным признакам. Откройте страницу поиска в браузере и посмотрите исходный код. На ней должен быть мета-robots с noindex, если вы выбрали этот путь. Затем проверьте заголовки ответа и кеш, чтобы убедиться, что старая версия страницы не отдается из CDN.

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

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

В Search Console полезно посмотреть:

• есть ли URL поиска в отчёте по индексированию;
• не растёт ли число «Просканировано, но не проиндексировано» для поисковых страниц;
• не появились ли новые варианты URL с параметрами, которые вы не закрыли.

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

Закрывают поиск только в robots.txt

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

Ставят noindex на все страницы с параметрами

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

Не чистят кеш после правки

Если на сайте есть page cache, серверный кеш или CDN, старая версия страницы поиска может продолжать отдаваться ещё какое-то время. После изменений очищайте все уровни кеширования, иначе проверка будет ложной.

Дублируют правила в теме и плагине

Когда noindex добавляет и тема, и SEO-плагин, и ещё robots.txt закрывает тот же URL, потом сложно понять, что именно сработало. Лучше оставить один основной источник правил и один вспомогательный.

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

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

Если вы правите код, делайте это в дочерней теме или через mu-plugin, а не в ядре темы. Тогда обновление не затрёт изменения. Для сайтов с активной редакцией это особенно важно: технические правки должны быть воспроизводимыми и не зависеть от ручного редактирования файлов в админке.

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