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

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

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

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

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

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

• отчёт «Страницы» в Google Search Console — есть ли в индексе URL с ?s=;
• серверные логи или аналитика — приходят ли боты на страницы поиска;
• исходный код страницы — есть ли уже noindex, canonical и не конфликтуют ли они между собой;
• настройки SEO-плагина — иногда поиск уже закрыт, но шаблон темы добавляет лишний canonical.

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

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

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

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

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

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

Вариант 2: через код в WordPress

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

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

    return $robots;
} );

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

Вариант 3: если тема выводит свой canonical

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

<?php
add_filter( 'get_canonical_url', function( $canonical, $post ) {
    if ( is_search() ) {
        return '';
    }

    return $canonical;
}, 10, 2 );

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

Пошаговая схема внедрения

1. Проверьте, как сейчас выглядит HTML страницы поиска: есть ли meta name="robots" и какой там набор директив.
2. Определите, кто управляет SEO-метками: плагин, тема или кастомный код.
3. Добавьте правило только для is_search().
4. Очистите кэш страницы и объектный кэш, если он есть.
5. Переобойдите URL в Search Console после обновления.

Если у вас есть отдельная страница поиска с красивым URL, логика та же: закрывать нужно именно её, а не весь сайт. Для этого иногда удобнее использовать условие по конкретному шаблону или по is_page(), если поиск вынесен на отдельную страницу.

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

Проверка должна быть не по ощущениям, а по факту в HTML и в ответе сервера.

• Откройте страницу поиска в браузере и посмотрите исходный код: должен быть noindex.
• Проверьте, что страница не получила редирект на главную или 404.
• Убедитесь, что ссылки внутри поиска остаются доступны для обхода, если вам нужен follow.
• В Search Console используйте проверку URL и посмотрите, как Google видит страницу после переобхода.

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

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

Закрыли не только поиск, но и полезные архивы

Это случается, когда правило написано слишком широко: например, по шаблону URL, а не по условию is_search(). Исправление простое — сузить логику до внутреннего поиска или отдельной страницы поиска.

Добавили noindex, но оставили конфликтующий canonical

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

Плагин и тема выводят разные robots-метки

Такое бывает, когда SEO-плагин уже добавил noindex, а тема печатает свой meta robots в header.php. В итоге в HTML появляется две мета-строки, и поведение становится непредсказуемым. Нужно оставить только один источник правды.

Страница всё ещё в индексе после правки

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

Что учесть для безопасности и производительности

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

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

<?php
/**
 * Plugin Name: Search Noindex
 */
add_filter( 'wp_robots', function( array $robots ) {
    if ( is_search() ) {
        $robots['noindex'] = true;
        $robots['follow']   = true;
    }

    return $robots;
} );

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

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