Как запретить индексацию страниц поисковой выдачи WordPress без ошибок в SEO

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

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

Когда это действительно нужно

Не стоит закрывать поиск «на всякий случай». Сначала проверьте, есть ли у вас именно техническая проблема, а не просто подозрение. Внутренние страницы поиска обычно стоит исключать из индекса, если:

• в выдаче появляются URL с пустыми или почти пустыми результатами;
• поисковые запросы генерируют много однотипных страниц;
• в Search Console видны URL с параметром s;
• боты тратят время на обход страниц, которые не должны ранжироваться;
• поиск доступен по GET-параметру и формирует отдельные URL.

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

Диагностика проблемы

Сначала убедитесь, что WordPress действительно отдаёт отдельные URL для поиска. Откройте несколько запросов и посмотрите адресную строку:

• / ?s=ключевое+слово — стандартный вариант;
• /search/ключевое-слово/ — если тема или плагин меняет структуру;
• страницы с параметрами фильтров, которые дублируют поиск.

Дальше проверьте три вещи:

1. есть ли на странице поиска мета-тег noindex;
2. не закрыта ли страница только в robots.txt — этого недостаточно для уже известных URL;
3. не конфликтует ли ваше решение с SEO-плагином, который уже управляет robots и canonical.

Если в исходном коде страницы поиска нет noindex, а в индексе уже есть такие URL, проблему нужно решать на уровне шаблона или фильтров WordPress.

Какой способ выбрать: код, плагин или настройка SEO-плагина

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

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

Пошаговое решение через код

Самый надёжный способ — повесить фильтр на robots-мета и добавить canonical на главную или на саму страницу поиска в зависимости от вашей политики индексации. Для большинства сайтов достаточно запретить индексацию и оставить переход по ссылкам внутри сайта.

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

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

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

    return $robots;
} );

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

Шаг 2. При необходимости задайте canonical

Если поисковая страница всё же должна существовать для пользователей, но не должна конкурировать в индексе, canonical обычно указывает на более стабильный URL. Чаще всего это главная или релевантная рубрика, но здесь нет универсального правила — зависит от структуры сайта.

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

    return $canonical;
}, 10, 2 );

Не используйте этот приём вслепую, если поиск нужен как отдельная посадочная страница. Canonical должен соответствовать реальной логике сайта, а не просто «убирать» URL из индекса.

Шаг 3. Уберите поиск из sitemap и внутренних ссылок, если это нужно

Поисковые URL не должны попадать в XML sitemap. Обычно WordPress сам их туда не добавляет, но если у вас кастомная генерация карты сайта или сторонний плагин, проверьте исключения. Также не стоит массово ставить ссылки на результаты поиска в меню, футер или блоки рекомендаций.

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

В Yoast SEO и Rank Math можно закрыть поиск на уровне настроек, но логика у них разная. Смотрите именно на то, что плагин отдаёт в HTML: noindex, canonical и robots-мета. Если плагин уже выставляет нужные директивы, дополнительный код не нужен.

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

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

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

• Откройте страницу поиска в браузере и проверьте исходный код.
• Убедитесь, что в <meta name="robots"> есть noindex.
• Проверьте, что страница не закрыта случайно через robots.txt вместо noindex.
• Посмотрите canonical и убедитесь, что он не указывает на мусорный URL.
• В Search Console отправьте URL на повторную проверку, если они уже были в индексе.

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

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

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

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

Поставили noindex и одновременно запретили обход

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

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

Иногда после правок разработчик случайно меняет шаблон поиска, а не только SEO-метаданные. Проверяйте, что форма поиска, страница результатов и пагинация продолжают работать. Особенно это важно, если тема переопределяет search.php.

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

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

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

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

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

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

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

Что считать успешным результатом

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

Самый надёжный порядок действий здесь простой: сначала диагностировать, потом закрыть индексирование штатным способом WordPress, затем проверить исходный код и только после этого смотреть на Search Console. Так меньше шансов случайно сломать то, что и так работало.