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

Автор: Наталья Громова | Опубликовано: 04.09.2026

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

Проблема обычно не в одном месте. Иногда поиск отдает индексируемый шаблон, иногда тема выводит лишний title и meta robots, иногда в sitemap случайно попадают страницы с параметрами. Ниже — практический разбор, как это проверить и закрыть без побочных эффектов.

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

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

Отдельный риск — когда поисковая страница возвращает 200 OK, содержит полноценный шаблон и не закрыта от индексации. Для робота это обычная страница, хотя по смыслу она не должна быть посадочной.

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

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

Проверьте реальные URL

Откройте в браузере несколько вариантов поиска и посмотрите, как формируется адрес:

/?s=тест — стандартный поиск WordPress;
/search/тест/ — если тема или плагин переписали URL;
/?s=тест&post_type=page — поиск с параметрами;
страницы с пагинацией поиска, если тема ее включает.

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

Что смотреть в админке и в коде

Если у вас установлен SEO-плагин, проверьте его настройки для архивов и поисковых страниц. Но не полагайтесь только на интерфейс: тема может переопределять шаблон, а плагин — не трогать конкретный тип URL.

Полезно быстро проверить, как WordPress генерирует поиск на уровне шаблона. Если тема использует search.php, именно там часто и прячется ошибка: лишний index, неправильный canonical или отсутствие noindex.

<?php
// Временно вставьте в search.php или проверьте через шаблон.
if ( is_search() ) {
    echo '<meta name="robots" content="noindex,follow">';
}

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

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

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

Подход	Когда подходит	Минус
SEO-плагин	Если нужен быстрый и понятный способ без правки темы	Зависит от конкретной реализации шаблона
Код в теме или mu-plugin	Если нужен точечный контроль над `noindex` и canonical	Нужно следить за обновлениями и конфликтами
Серверный редирект/правило	Если нужно жестко убрать мусорные URL	Можно сломать внутренний поиск и аналитику

Вариант 1: закрыть через `wp_robots`

Это самый аккуратный способ для современных версий WordPress. Фильтр wp_robots позволяет добавить noindex без ручной правки шаблона.

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

    return $robots;
} );

Если тема уже выводит свой meta robots, проверьте, не дублируется ли тег. Должен остаться один корректный вариант.

Вариант 2: убрать поиск из sitemap и каноникал

Поисковые страницы не должны попадать в XML-карту сайта. Если SEO-плагин или кастомный код добавляют их туда, это нужно отключить отдельно. Канонический URL на поисковой странице обычно не нужен: если страница закрыта от индексации, canonical на нее саму не решает проблему.

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

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

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

<?php
add_action( 'template_redirect', function() {
    if ( is_search() && ! get_search_query() ) {
        wp_safe_redirect( home_url( '/' ), 302 );
        exit;
    }
} );

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

Пошаговая настройка без поломки сайта

Найдите все варианты поисковых URL в логах, Search Console и через ручную проверку.
Проверьте, не генерирует ли тема отдельный шаблон поиска с индексируемыми мета-тегами.
Добавьте noindex,follow через wp_robots или настройку SEO-плагина.
Исключите поисковые URL из sitemap, если они туда попали.
Для пустого поиска поставьте редирект или отдельную логику ответа.
После правок проверьте исходный код, заголовки ответа и статус URL в Search Console.

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

Проверка должна быть не по ощущениям, а по факту. Откройте страницу поиска и убедитесь, что в HTML есть noindex. Затем проверьте заголовки ответа через DevTools или curl.

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

В ответе должно быть видно, что страница отдает ожидаемый статус, а не случайный редирект или ошибку. Если вы используете noindex в HTML, откройте исходник и найдите строку с robots. Если закрытие сделано через HTTP-заголовок, убедитесь, что он реально присутствует.

В Search Console изменения не всегда видны сразу. Но если страница была переобходена, со временем статус должен смениться на исключенную или неиндексируемую. Для быстрой проверки используйте инспекцию URL и посмотрите, как Google видит страницу сейчас.

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

Поставили noindex, но оставили страницу в sitemap. Поисковик получает противоречивые сигналы. Уберите URL из карты сайта.
Сделали 301 на главную для всех поисковых запросов. Пользователь теряет поиск, а робот получает неочевидную логику. Используйте редирект только для пустого запроса или мусорных параметров.
Закрыли URL в robots.txt и забыли про индексацию уже найденных страниц. Robots.txt не удаляет URL из индекса сам по себе. Нужен noindex или корректный ответ сервера.
Тема выводит два meta robots. Это бывает после ручной правки шаблона и установки SEO-плагина одновременно. Оставьте один источник управления.
Проверили только главную страницу поиска, а не все варианты параметров. Индексироваться может не только ?s=, но и URL с дополнительными параметрами.

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

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

Если вы правите код, лучше вынести логику в mu-plugin, а не в тему. Тогда настройка не слетит при обновлении дизайна. И не забывайте тестировать на staging: редиректы и robots-правила легко ломают поиск, если в URL есть нестандартные параметры.

Для сайтов, где нужно одновременно чистить дубли, управлять индексированием и убирать технический мусор, иногда удобнее использовать специализированный набор настроек вроде Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже в этом случае сначала проверьте, что именно генерирует ваш шаблон поиска, а уже потом включайте готовую опцию.

Что делать, если поиск нужен пользователям, но не нужен в индексе

Это нормальная ситуация. Поиск может оставаться рабочим для посетителей, но при этом быть закрытым для роботов. В таком режиме важно не ломать UX: форма поиска должна возвращать релевантные результаты, а пустые запросы — не создавать мусорные страницы.

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

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