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

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

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

Какие URL обычно нужно закрывать

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

Отдельно стоит смотреть на:

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

Диагностика: как понять, что проблема уже есть

Начните не с правок, а с проверки факта индексации. Это экономит время: иногда поисковые страницы уже закрыты, но в индексе висят старые копии.

Что смотреть в Search Console

Откройте отчёт по индексированию страниц и найдите URL с параметром s= или путём поиска. Если там есть страницы с пометкой «Просканировано, но не проиндексировано» или «Исключено тегом noindex», это нормально только если вы действительно ставили запрет осознанно. Если же поиск индексируется, а вы этого не планировали, нужно править шаблон или заголовки ответа.

Проверка на самом сайте

Посмотрите исходный код страницы поиска. В идеале там должен быть либо <meta name="robots" content="noindex,follow">, либо заголовок X-Robots-Tag с тем же смыслом. Если ничего нет, поисковик может индексировать такие страницы по умолчанию.

<?php
// Быстрая проверка в шаблоне или через временный mu-plugin.
if ( is_search() ) {
    error_log( 'Search page detected: ' . home_url( add_query_arg( null, null ) ) );
}

Что выбрать: noindex, robots.txt или оба варианта

Для поисковых страниц WordPress чаще всего нужен noindex,follow. Это означает: страницу не индексировать, но ссылки с неё можно обходить. Полностью запрещать обход через robots.txt стоит не всегда: если бот не может зайти на страницу, он не увидит мета-тег noindex и может дольше держать URL в индексе по старым данным.

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

Если у вас нет SEO-плагина, который умеет управлять robots-мета на уровне шаблона, проще и надёжнее добавить правило в тему или в небольшой mu-plugin. Для WordPress это стандартный путь: не трогаем ядро, не завязываемся на хрупкие правки в шаблонах.

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

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

    return $robots;
} );

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

2. Если нужно, закройте только конкретные параметры

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

<?php
add_filter( 'wp_robots', function( array $robots ) {
    if ( is_search() ) {
        $query = get_search_query( false );

        if ( $query === '' || mb_strlen( trim( $query ) ) < 3 ) {
            $robots['noindex'] = true;
            $robots['follow']  = true;
        }
    }

    return $robots;
} );

Такой подход полезен, если у вас есть нормальная страница поиска с длинными запросами, но вы не хотите плодить индекс на пустых и бессмысленных страницах.

3. При необходимости добавьте ограничение в robots.txt

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

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

Но не копируйте это вслепую. Если у вас поиск реализован через красивый путь /search/ и он нужен пользователям, запрещать его в robots.txt нельзя. Сначала проверьте, как именно устроены URL на вашем сайте.

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

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

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

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

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

• Откройте страницу поиска в браузере и убедитесь, что в <head> есть noindex.
• Проверьте ответ сервера через curl -I, если используете X-Robots-Tag.
• В Search Console отправьте URL на повторную проверку, если он уже был в индексе.
• Убедитесь, что обычные страницы сайта не получили случайный noindex.

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

В ответе ищите либо заголовок X-Robots-Tag, либо проверяйте HTML-код страницы. Если страница отдаёт 200 OK, но в коде нет запрета на индексацию, значит правило не сработало или подключено не в том месте.

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

Закрыли поиск в robots.txt и забыли про noindex

Это самая частая ошибка. Бот не видит страницу, но URL может ещё долго висеть в индексе. Исправление: вернуть доступ для обхода и добавить noindex на саму страницу.

Поставили noindex на весь сайт через общий фильтр

Такое бывает, если условие написано слишком широко, например без проверки is_search(). В результате поисковик перестаёт индексировать и обычные страницы. Исправление: сузить условие и проверить, что фильтр срабатывает только на нужных шаблонах.

Сломали поиск в теме

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

Оставили дубли с разными параметрами

Если поисковый URL может открываться и с ?s=, и через красивый путь, поисковик увидит два разных адреса. Исправление: выбрать один канонический вариант, а второй либо редиректить, либо закрывать от индексации.

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

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

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

Если у вас есть возможность централизовать технические настройки, это обычно лучше, чем держать часть правил в теме, часть в плагине SEO, а часть в robots.txt. Чем меньше разрозненных мест, тем проще потом отлавливать конфликты.

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

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

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