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

На WordPress внутренняя страница поиска часто превращается в источник дублей: один и тот же запрос может открываться с разными параметрами, а поисковые роботы начинают обходить бесполезные URL вроде ?s=..., ?post_type=... или комбинации с фильтрами темы и плагинов. Если сайт уже получил такие страницы в индексе, простого удаления URL из Search Console обычно недостаточно — нужно одновременно убрать их из обхода, отдать корректные мета-указания и не ломать поиск для пользователей.

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

Сначала проверьте, что именно индексируется. В WordPress это не всегда только стандартный поиск по ?s=. Часто в индекс попадают:

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

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

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

  • Есть ли у страницы поиска мета-тег robots с noindex.
  • Не генерирует ли тема отдельный шаблон поиска без SEO-меток.
  • Не создаёт ли плагин фильтрации собственные параметры в URL поиска.
  • Не попадает ли поиск в XML-карту сайта.
  • Не открывается ли поиск без запроса как полноценная страница с заголовком и текстом.

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

Для этой задачи есть три нормальных подхода: SEO-плагин, код в теме или мини-плагине, и серверная логика для редких случаев. На практике чаще всего достаточно кода, если вы не хотите тащить лишний плагин только ради одной настройки.

ПодходКогда подходитПлюсМинус
SEO-плагинЕсли уже стоит Yoast, Rank Math или аналогБыстро и без кодаЗависит от конкретного плагина и его настроек
Код в functions.php или MU-плагинеЕсли нужен точечный контрольПрозрачно и предсказуемоНужно аккуратно тестировать
Серверные правилаЕсли нужно ограничить обход на уровне сайтаСнижает лишние запросыЛегко ошибиться и сломать поиск

Вариант 1: добавить noindex для страниц поиска

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

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

Такой вариант работает для стандартного поиска WordPress. Если у вас есть отдельные поисковые шаблоны или AJAX-поиск, их нужно проверять отдельно: мета-тег в HTML может вообще не участвовать в выдаче, если результаты подгружаются скриптом.

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

Страницы поиска не должны попадать в XML Sitemap. Если sitemap генерирует SEO-плагин, проверьте его настройки индексации. Если карта создаётся вручную, не добавляйте туда URL с ?s= и похожими параметрами. Для собственного генератора sitemap логика обычно сводится к фильтрации URL по признаку поискового шаблона.

<?php
function wpinfo_is_search_url( $url ) {
    $parts = wp_parse_url( $url );
    if ( empty( $parts['query'] ) ) {
        return false;
    }

    parse_str( $parts['query'], $query_args );
    return isset( $query_args['s'] ) && $query_args['s'] !== '';
}

Этот пример полезен, если вы строите собственную карту сайта или фильтруете список URL перед отправкой в XML. Он не заменяет SEO-настройки, но помогает не засорять sitemap мусорными страницами.

Вариант 3: отдать canonical на саму страницу поиска или убрать его совсем

С canonical нужно быть осторожнее. Для поиска с параметрами каноникал на саму себя часто не решает проблему, потому что URL с разными запросами всё равно остаются отдельными страницами. Для поисковых страниц обычно безопаснее сочетать noindex и follow, а не пытаться «склеить» всё в один адрес.

Если у вас SEO-плагин автоматически ставит canonical на поисковые URL, проверьте, не конфликтует ли это с вашей логикой. Иногда лучше отключить каноникал для поиска через фильтр плагина, но делать это нужно только если вы понимаете, как плагин формирует мета-теги.

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

  1. Сделайте копию файла functions.php или используйте MU-плагин.
  2. Добавьте noindex,follow для всех страниц поиска.
  3. Проверьте, не генерирует ли тема отдельный SEO-блок в шаблоне поиска.
  4. Уберите поисковые URL из sitemap и внутренних списков ссылок, если они там есть.
  5. Проверьте ответ сервера для поисковых страниц: он должен быть 200, если поиск нужен пользователям, и не должен отдавать пустой контент как полноценную посадочную страницу.
  6. После изменения отправьте на переобход только важные страницы, а не весь поиск.

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

Проверка должна быть не «на глаз», а по факту HTML и ответов сервера. Откройте несколько URL поиска и посмотрите исходный код страницы. В <head> должен появиться:

<meta name="robots" content="noindex,follow" />

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

  • в Search Console URL с параметрами больше не получают статус «проиндексировано» после повторного обхода;
  • страницы поиска не попадают в XML Sitemap;
  • поиск по сайту по-прежнему работает для посетителей;
  • в логах сервера не растёт число бесполезных запросов к пустым поисковым URL.

Если вы используете командную строку, можно быстро проверить заголовки ответа:

curl -I "https://example.com/?s=тест"

Эта команда не покажет мета-тег, но поможет увидеть код ответа и понять, не редиректит ли сайт поиск на неожиданный адрес.

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

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

Например, закрыли ?s=, но забыли про URL с дополнительными параметрами темы. В итоге в индекс всё равно попадают дубли. Решение: проверьте все варианты, которые реально генерирует сайт, а не только стандартный шаблон WordPress.

Сделали редирект всех поисковых URL на главную

Это плохая идея, если поиск нужен пользователям. Поисковик видит массовые редиректы и может воспринимать их как soft-404. Лучше оставить поиск доступным, но закрыть от индексации.

Убрали поиск из sitemap, но не добавили noindex

Это частая полумера. Sitemap — только один из сигналов. Если URL уже найден по внутренним ссылкам или внешним переходам, он всё равно может попасть в индекс.

Поставили nofollow вместо noindex

nofollow не запрещает индексацию страницы. Он лишь говорит не передавать вес по ссылкам. Для поиска нужен именно noindex,follow.

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

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

  • ограничить доступ к пустому поиску через шаблон, если он не нужен;
  • не выводить тяжёлые блоки на страницах поиска;
  • проверить, не кэширует ли плагин кэширования каждый уникальный поисковый запрос как отдельную страницу;
  • не ставить агрессивные правила в robots.txt без понимания последствий — запрет обхода не равен запрету индексации.

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

Когда лучше не закрывать поиск полностью

Если внутренняя выдача реально помогает пользователям находить контент, не превращайте её в «мертвую» страницу. В этом случае задача не в том, чтобы спрятать поиск, а в том, чтобы убрать из индекса только технические и пустые варианты. Рабочая схема обычно такая: полезный поиск остаётся доступным, а все URL с параметрами и пустыми запросами получают noindex и не попадают в sitemap.

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

Как отключить Gutenberg и вернуть классический редактор в WordPress
18.12.2025
Оптимизация изображений в WordPress для ускорения сайта
21.11.2025
Как изменить URL авторского архива в WordPress
01.12.2025
Как настроить автоматическое удаление неактивных пользователей WordPress
21.01.2026
Как изменить имя пользователя в WordPress без доступа к базе данных
26.03.2026