Страницы внутреннего поиска в WordPress часто попадают в индекс не потому, что сайт «плохо настроен», а потому что поисковик видит множество URL с параметром ?s= и начинает обходить их как отдельные страницы. На небольшом сайте это выглядит безобидно, но на контентном проекте быстро появляются дубли, мусорные сниппеты и лишняя нагрузка на обход.
Если у вас уже есть статьи про дубли страниц и запрет индексации архивов, здесь задача точнее: нужно закрыть именно результаты внутреннего поиска, не сломав сам поиск для пользователей и не убрав из индекса полезные страницы сайта.
Когда проблема действительно есть
Проверять нужно не по ощущениям, а по фактам. Откройте сайт и выполните поиск по любому слову. Если адрес меняется на что-то вроде / ?s=слово или /search/слово/, а в коде страницы нет явного запрета на индексацию, поисковик может сохранить такие URL в базе.
Типичные признаки:
- в «Яндекс Вебмастере» или Google Search Console появляются URL с параметром поиска;
- в выдаче видны страницы поиска с пустым или нерелевантным title;
- серверные логи показывают частые заходы ботов на URL с
s=; - в отчётах по дублям много страниц, которые отличаются только поисковым запросом.
Что именно нужно закрывать
Не путайте страницу формы поиска и страницу результатов поиска. Форму можно оставить в интерфейсе, а вот URL с результатами обычно лучше не индексировать. Исключение — если у вас осознанно построен каталог с поисковыми посадочными страницами, но это уже отдельная архитектура, а не стандартный внутренний поиск WordPress.
Диагностика: как понять, какой вариант поиска у вас используется
В WordPress встречаются два распространённых сценария:
- классический поиск через параметр
?s=; - человекопонятный URL поиска, который задаёт тема или плагин.
Проверьте исходный код формы поиска и адрес после отправки запроса. Если в URL есть s, решение можно строить вокруг noindex, nofollow и заголовка X-Robots-Tag. Если поиск отдаёт HTML-страницу по красивому пути, логика та же, но нужно убедиться, что правило срабатывает именно на этот шаблон.
Ещё один важный момент: если у вас стоит SEO-плагин, он может уже добавлять мета-теги robots. В этом случае не надо дублировать всё подряд в теме и плагине — сначала посмотрите, что уже делает текущая конфигурация.
Рабочее решение: закрыть результаты поиска через код
Самый надёжный вариант — добавить запрет индексации на уровне шаблона и заголовков. Это не отменяет работу поиска, но подсказывает роботам не сохранять такие страницы в индекс.
<?php
// functions.php дочерней темы или собственный мини-плагин.
add_action( 'wp_head', function () {
if ( is_search() ) {
echo '<meta name="robots" content="noindex, nofollow, noarchive" />' . "\n";
}
}, 1 );
add_filter( 'wp_robots', function( $robots ) {
if ( is_search() ) {
$robots['noindex'] = true;
$robots['nofollow'] = true;
$robots['noarchive'] = true;
}
return $robots;
} );
Здесь есть два уровня защиты. Первый — мета-тег в <head>. Второй — фильтр wp_robots, который WordPress использует для формирования robots-правил. Если тема или плагин меняют разметку, фильтр обычно остаётся более устойчивым.
Если нужен ещё и заголовок для ботов
Для некоторых конфигураций полезно добавить HTTP-заголовок X-Robots-Tag. Это особенно удобно, если поисковые роботы иногда обходят страницу без полноценного рендера HTML.
<?php
add_action( 'template_redirect', function () {
if ( is_search() && ! headers_sent() ) {
header( 'X-Robots-Tag: noindex, nofollow, noarchive', true );
}
} );
Этот вариант не заменяет мета-тег, а дополняет его. На практике я бы оставлял оба механизма, если нет конфликта с уже установленным SEO-плагином.
Сравнение подходов
| Способ | Плюсы | Минусы | Когда выбирать |
|---|---|---|---|
| SEO-плагин | Быстро, без кода | Зависит от настроек и версии плагина | Если у вас уже есть единый SEO-стек |
| Код в теме | Контроль и предсказуемость | Нужно следить за обновлениями темы | Если нужен точечный фикс |
| Мини-плагин | Не зависит от темы | Нужно один раз создать и поддерживать | Если решение должно пережить смену темы |
Если сайт живёт долго и тема может меняться, мини-плагин обычно практичнее, чем правка functions.php. Для одноразового проекта допустим и код в дочерней теме, но только не в родительской.
Пошаговая настройка без лишних рисков
- Проверьте, есть ли уже запрет индексации в SEO-плагине.
- Если запрета нет, добавьте
noindexчерезwp_robots. - При необходимости добавьте
X-Robots-Tagна уровне ответа сервера. - Очистите кеш страницы и CDN, если они используются.
- Переобойдите URL поиска в инструменте проверки страницы.
Если вы используете кеширующий плагин, после изменений обязательно сбросьте кеш. Иначе вы можете смотреть на старую версию страницы и думать, что код не сработал.
Как проверить, что решение сработало
Проверка должна быть не только визуальной. Откройте страницу поиска и убедитесь в трёх вещах:
- в исходном коде есть
<meta name="robots" content="noindex, nofollow, noarchive" />или эквивалентный набор правил; - в ответе сервера присутствует заголовок
X-Robots-Tag, если вы его добавляли; - страница поиска по-прежнему показывает результаты пользователю, а не отдаёт ошибку или редирект на главную.
Дополнительно можно проверить через инструменты разработчика в браузере: вкладка Network покажет заголовки ответа, а View Source — итоговую разметку. Если у вас есть доступ к Search Console или Вебмастеру, отправьте URL на переобход и посмотрите, как система видит robots-правила.
Частые ошибки и как их исправить
1. Закрыли не только результаты поиска, но и саму форму
Такое бывает, если правило написали слишком широко, например по всем URL с s= без проверки контекста. Пользовательская форма поиска должна работать, а закрывать нужно именно страницу результатов.
2. Дублируют запрет в нескольких местах
Если SEO-плагин уже ставит noindex, а вы добавили ещё один блок в тему, обычно ничего страшного не произойдёт. Но иногда плагины формируют конфликтующие robots-правила. В таком случае оставьте один источник истины: либо плагин, либо код.
3. Не сбрасывают кеш
После правки шаблона или фильтра старый HTML может продолжать отдаваться из кеша. Это особенно заметно на сайтах с серверным кешем и CDN. Сначала сбросьте кеш, потом проверяйте.
4. Путают noindex и запрет обхода
noindex говорит не индексировать страницу, но не всегда запрещает её обход. Если вам нужно именно снизить нагрузку на обход, можно дополнительно ограничить ссылки на поиск во внутренней перелинковке и не генерировать лишние URL поиска в меню и виджетах.
Что ещё стоит сделать для чистоты индекса
Закрытие поиска — это только один слой. Если на сайте много технического мусора, проверьте ещё и:
- страницы пагинации поиска, если они создаются темой;
- пустые результаты поиска с одинаковыми title;
- ссылки на поиск в футере и сайдбаре, которые создают бесконечные комбинации запросов;
- автоматические внутренние ссылки на URL поиска из старых шаблонов.
Если нужен более широкий аудит дублей и технических страниц, удобно сначала собрать список URL с параметрами и только потом решать, что закрывать через robots, а что — редиректить или удалять из шаблонов. Для этого в WordPress хорошо работает связка из проверки шаблонов, Search Console и логов сервера.
Практика по безопасности и производительности
Не делайте редирект всех поисковых URL на главную. Это плохая замена noindex: робот получает нерелевантный ответ, а пользователь — неожиданный переход. Если поиск на сайте нужен, он должен продолжать работать.
Также не стоит закрывать поиск через robots.txt как единственный метод. Это не гарантирует удаление URL из индекса, если на них уже есть внешние ссылки. Лучше использовать мета-robots или заголовок ответа, а robots.txt — только как дополнительную меру, если вы понимаете последствия.
Для сайтов с большим количеством запросов полезно ещё и ограничить генерацию мусорных поисковых URL в шаблонах: не выводить пустую форму поиска в местах, где она не нужна, и не подставлять в ссылки заранее заполненные параметры без необходимости. Это уменьшает количество бесполезных обходов и делает структуру сайта чище.
