Как настроить noindex для страниц поисковой выдачи в WordPress

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

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

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

Сначала стоит убедиться, что речь именно о страницах поиска, а не о других дублях. Типичный признак — в индексе появляются URL с параметром s, а в Search Console или в логах обхода видны запросы к адресам вроде /?s=wordpress или /search/?s=.... Иногда такие страницы получают статус 200 OK, имеют уникальный title и даже попадают в sitemap через сторонний плагин или кастомный шаблон.

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

  • Есть ли у сайта внутренний поиск и индексируются ли его результаты.
  • Какие именно URL попадают в индекс: с параметром ?s= или отдельный путь /search/.
  • Не добавляет ли тема или плагин мета-теги для страниц поиска автоматически.
  • Не попадают ли страницы поиска в XML sitemap.

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

Какой подход выбрать

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

ПодходПлюсыМинусы
SEO-плагинБыстро, без кодаНе всегда отдельно управляет поиском
Код в теме или mu-pluginТочно под вашу логикуНужно аккуратно тестировать
robots.txtПросто добавитьНе решает индексацию надёжно

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

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

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

<?php
add_action( 'wp_head', function () {
    if ( is_search() ) {
        echo '<meta name="robots" content="noindex,follow" />' . "\n";
    }
}, 1 );

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

2. Добавьте canonical на саму поисковую страницу

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

<?php
add_filter( 'wpseo_canonical', function ( $canonical ) {
    if ( is_search() ) {
        $canonical = home_url( add_query_arg( null, null ) );
    }

    return $canonical;
} );

Если у вас не Yoast SEO, а другой SEO-плагин, фильтр будет другим. В таком случае лучше не пытаться угадать чужой API, а либо использовать настройки плагина, либо оставить только wp_head-мета-тег и проверить итоговый HTML.

3. При необходимости закройте поиск от обхода в robots.txt

Это дополнительная мера, а не основная. Она полезна, если поисковые роботы активно тратят ресурсы на параметры поиска, но не стоит рассчитывать только на неё.

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

Учтите: для параметров в robots.txt поведение поисковиков может отличаться. Если вы уже поставили noindex, robots.txt нужен скорее как вспомогательный слой, а не как единственная защита.

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

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

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

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

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

  1. Откройте страницу поиска в браузере, например /?s=test.
  2. Посмотрите исходный код страницы и убедитесь, что есть <meta name="robots" content="noindex,follow" />.
  3. Проверьте, не выводится ли на странице второй robots-тег от SEO-плагина с конфликтующим значением.
  4. Убедитесь, что страница не возвращает 404 или 301, если поиск должен работать для пользователей.
  5. Через Search Console отправьте URL на проверку и посмотрите, как робот видит страницу.

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

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

Добавили только robots.txt

Это самая частая ошибка. Поисковик может всё равно оставить URL в индексе, если он уже известен и на него есть ссылки. Исправление простое: добавьте noindex в HTML-ответ.

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

Иногда разработчик пишет условие слишком широко, например проверяет только наличие параметра s в URL. В результате под правило попадают другие страницы с query string. Лучше использовать is_search(), а не ручной парсинг URL без необходимости.

Конфликт двух SEO-решений

Если один плагин ставит noindex, а другой — index,follow, итоговый HTML становится непредсказуемым. В таких случаях оставьте один источник мета-роботов и проверьте, кто реально печатает тег в <head>.

Кэш не обновился

После изменения кода старый HTML может продолжать отдаваться из кэша страницы или CDN. Очистите серверный кэш, объектный кэш и CDN, если он есть. Без этого проверка будет бессмысленной.

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

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

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

Как добавить поддержку WebP в WordPress без плагинов
11.12.2025
Динамический фильтрованный список записей WordPress с WP_Query и AJAX
11.12.2025
Как найти и убрать дубли страниц в WordPress: диагностика, каноникал и редиректы
18.08.2026
Как автоматизировать обновление кэшируемых данных в WordPress
24.03.2026
Как создать динамические формы в WordPress с помощью AJAX
15.12.2025