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

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

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

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

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

Типичные признаки проблемы

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

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

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

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

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

1. Откройте поиск на сайте и выполните 2-3 разных запроса.
2. Посмотрите адрес в браузере: есть ли ?s=, дополнительные параметры, редиректы.
3. Проверьте исходный код страницы поиска: есть ли уже noindex в <meta name="robots">.
4. Выполните в Google запрос site:example.ru inurl:?s= или аналогичный для своего домена.
5. Если используете Search Console, откройте отчёт по индексированию и посмотрите, какие поисковые URL попали в индекс.

Если страницы поиска уже индексируются, одного robots.txt часто недостаточно. Робот может увидеть URL, но не понять, что страница не нужна в индексе. Для надёжного результата обычно нужен noindex.

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

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

Вариант 1. Закрыть поиск через SEO-плагин

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

Но здесь важно не путать: некоторые плагины умеют закрывать только архивы, а не поисковые результаты. Поэтому после изменения настроек обязательно смотрите исходный код страницы поиска и мета-тег robots.

Вариант 2. Добавить noindex,follow через код

Если нужен точный контроль, можно добавить фильтр в functions.php дочерней темы или в небольшой mu-plugin. Для классического WordPress это самый прямой способ.

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

    return $robots;
} );

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

Если тема или старый плагин уже выводит свой robots meta, проверьте, не конфликтует ли он с этим фильтром. В современных версиях WordPress wp_robots — нормальный путь, а не самодельные вставки в header.php.

Вариант 3. Подстраховать robots.txt

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

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

Этот пример нужно адаптировать под ваш формат URL. Если поиск у вас работает только через параметр ?s=, строка Disallow: /?s= может помочь, но не стоит рассчитывать на неё как на единственный барьер. Для индексации важнее именно noindex.

Если поиск сделан через плагин или нестандартный шаблон

Иногда проблема не в стандартном поиске WordPress, а в плагине поиска, который создаёт отдельные URL, AJAX-результаты или страницы с параметрами сортировки. Тогда нужно смотреть не только на robots meta, но и на то, как формируется ссылка.

Что делать в таких случаях

• проверьте, есть ли у плагина настройка noindex для результатов поиска;
• убедитесь, что AJAX-ответы не попадают в публичные URL;
• если поиск создаёт отдельные страницы, закройте именно шаблон результата, а не форму поиска;
• уберите лишние параметры из URL, если они не нужны для пользователя;
• не закрывайте CSS, JS и API-эндпоинты, которые нужны для работы интерфейса.

Если вы используете кастомный шаблон поиска в теме, проверьте файл search.php. Частая ошибка — закрыть только сам шаблон, но оставить индексируемыми URL с параметрами, которые этот шаблон генерирует.

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

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

Что проверить сразу

1. Откройте страницу поиска в браузере и посмотрите исходный код: должен быть noindex.
2. Проверьте ответ сервера через DevTools или curl, если нужно убедиться в заголовках и редиректах.
3. Убедитесь, что форма поиска по-прежнему отправляет запросы и выдача открывается для пользователя.
4. В Search Console отправьте URL на проверку, если он уже был в индексе.
5. Через несколько дней проверьте, уменьшилось ли число страниц поиска в отчётах.

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

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

Если сайт отдаёт HTML-страницу, дополнительно посмотрите её содержимое и убедитесь, что в <head> есть корректный robots meta. Если у вас стоит кэш, проверяйте не только главную копию, но и страницу после очистки кэша.

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

1. Закрыли в robots.txt, но не добавили noindex

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

2. Поставили noindex на весь сайт

Иногда фильтр пишут слишком грубо и он срабатывает не только на is_search(), но и на другие шаблоны. Проверьте условие и не расширяйте его без необходимости.

3. Сломали AJAX-поиск

Если плагин поиска использует AJAX, не закрывайте его endpoint в robots.txt и не режьте скрипты. Закрывать нужно именно публичные страницы результатов, а не технические запросы интерфейса.

4. Оставили индексируемыми параметры сортировки и фильтров

Иногда поиск генерирует URL с orderby, post_type или другими параметрами. Если они не нужны для SEO, их тоже стоит нормализовать или закрыть отдельно, иначе мусорные варианты продолжат появляться.

5. Проверили только в браузере, но не в индексе

То, что страница выглядит правильно, ещё не значит, что поисковик уже убрал её из базы. После внедрения нужно дождаться переобхода и проверить отчёты индексации.

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

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

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

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

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