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

Страницы внутреннего поиска в WordPress часто создают мусор в индексе: пустые выдачи, дубли с разными параметрами запроса, тонкие страницы без полезного контента. При этом сам поиск на сайте должен продолжать работать для пользователей и для админов. Здесь важно не смешивать две задачи: скрыть search-страницы от индексации и не сломать сам поиск.

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

Когда search-страницы действительно нужно закрывать

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

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

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

Диагностика: что именно индексируется сейчас

Перед правками проверьте, какие URL уже попали в индекс и как они отдаются сервером. Это поможет выбрать способ: noindex, canonical или дополнительный запрет в robots.txt.

Проверка URL поиска в браузере и в исходнике

Откройте несколько вариантов поиска:

• https://site.ru/?s=тест
• https://site.ru/search/тест/ — если на сайте есть ЧПУ-поиск через тему или плагин;
• поиск с пустым запросом, если тема его не блокирует.

Посмотрите исходный код страницы и заголовки ответа. Важно понять, есть ли уже noindex, какой canonical указан и не отдает ли страница код 200 для пустого поиска.

Что проверить в Search Console

В отчёте по индексированию посмотрите:

• есть ли страницы с параметром s= в индексе;
• не отмечены ли они как «Просканировано, но не проиндексировано»;
• не растёт ли число URL с поисковыми запросами после запуска новых фильтров или виджетов.

Если search-страницы уже в индексе, одного robots.txt обычно недостаточно: поисковик может продолжать хранить URL в базе, даже если не сможет его повторно обойти.

Что лучше: noindex, robots.txt или canonical

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

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

Пошаговое решение через код темы или мини-плагин

Если не хотите зависеть от SEO-плагина, можно добавить правило в мини-плагин или в functions.php дочерней темы. Для production-проекта мини-плагин предпочтительнее: он не исчезнет при смене темы.

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

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

    return $robots;
} );

Этот вариант работает в современных версиях WordPress, где используется API robots. Он не трогает обычные страницы сайта и срабатывает только на результатах поиска.

2. Добавьте X-Robots-Tag для серверной страховки

Если хотите усилить сигнал, можно отправлять заголовок X-Robots-Tag для search-страниц. Это полезно, когда тема или плагин выводят нестандартный шаблон и вы не уверены, что meta robots попадёт в нужное место.

<?php
add_action( 'template_redirect', function() {
    if ( is_search() && ! headers_sent() ) {
        header( 'X-Robots-Tag: noindex, follow', true );
    }
} );

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

3. Ограничьте индексацию в robots.txt как дополнительный слой

Если у вас есть доступ к настройке robots.txt, можно добавить директиву для поисковых URL. Это не заменяет noindex, но уменьшает лишний обход.

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

Этот вариант не универсален для всех конфигураций, потому что WordPress может использовать разные структуры поиска. Если у вас ЧПУ-поиск или параметры через плагин, проверьте реальные URL и добавьте только те шаблоны, которые действительно используются.

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

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

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

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

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

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

• страница поиска открывается для пользователя и показывает результаты;
• в исходнике есть noindex или в ответе присутствует X-Robots-Tag: noindex, follow;
• обычные страницы сайта не получили этот же тег по ошибке;
• поиск по сайту продолжает работать в шапке, виджете или блоке темы.

Проверка через curl

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

curl -I "https://site.ru/?s=тест"

В ответе ищите строку вида:

X-Robots-Tag: noindex, follow

Если заголовка нет, а в HTML тоже нет noindex, значит правило не сработало или было добавлено не в тот хук.

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

Закрыли search-страницы только в robots.txt

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

Поставили noindex на весь сайт

Такое случается, когда условие написано слишком широко: например, без проверки is_search() или с ошибкой в логике шаблона. После этого поисковики могут начать игнорировать и важные страницы. Проверяйте, что правило срабатывает только на search-URL.

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

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

Использовали canonical на главную без анализа

Для результатов поиска это часто выглядит как искусственная подмена смысла страницы. Поисковик может проигнорировать сигнал или начать путаться в канонических адресах. Если цель — убрать search-страницу из индекса, noindex обычно честнее и проще.

Чек-лист перед публикацией правок

• Проверил, какие именно search-URL есть на сайте.
• Добавил noindex, follow только для is_search().
• При необходимости добавил X-Robots-Tag для серверной страховки.
• Не закрыл обычные страницы и архивы по ошибке.
• Проверил заголовки через браузер или curl.
• Убедился, что поиск для пользователей работает как раньше.
• Проверил Search Console на повторное появление search-URL в индексе.

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

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

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