Страницы внутреннего поиска WordPress часто попадают в индекс не потому, что сайт «плохой», а потому что поисковые роботы находят много URL с параметром ?s=. Для пользователя это почти всегда мусор: дубли, пустые выдачи, страницы с низкой ценностью и нестабильным контентом. При этом сам поиск на сайте должен продолжать работать для людей и для админов.
Ниже — рабочая схема, которая не ломает поиск, не трогает обычные страницы и позволяет проверить, что закрытие действительно сработало.
Когда это вообще проблема
Сначала стоит убедиться, что речь именно о поисковых URL, а не о другой причине дублей. В WordPress поисковая страница обычно выглядит так: https://site.ru/?s=запрос. Иногда к ней добавляются дополнительные параметры, если тема или плагин расширяют поиск.
Проблема заметна по нескольким признакам:
- в индексе есть страницы с
?s=и почти одинаковыми заголовками; - в Search Console растёт число «Просканировано, но не проиндексировано» для URL поиска;
- в логах сервера поисковые роботы часто запрашивают пустые или бессмысленные поисковые запросы;
- в выдаче всплывают страницы поиска вместо нормальных посадочных страниц.
Что не стоит делать
Не закрывайте поиск только через robots.txt, если хотите убрать уже найденные URL из индекса. Запрет в robots мешает сканированию, но не гарантирует удаление из индекса. И не ставьте глобальный noindex на весь сайт через «на всякий случай» — это частая ошибка, после которой начинают выпадать нормальные страницы.
Диагностика: какие URL реально индексируются
Перед изменениями проверьте, какие именно адреса попали в индекс и как они выглядят. Это можно сделать вручную и через инструменты вебмастера.
- Откройте поиск по сайту в браузере и посмотрите формат URL.
- В Search Console используйте проверку URL для нескольких поисковых страниц.
- Посмотрите исходный код страницы поиска: есть ли уже
noindexили canonical на другую страницу.
Если тема или SEO-плагин уже добавляет meta robots noindex, возможно, проблема не в индексации, а в том, что canonical указывает не туда или поиск генерирует лишние параметры. Тогда сначала исправляют шаблон, а не добавляют ещё один слой запрета.
Пошаговое решение
Вариант 1: закрыть поиск через SEO-плагин
Если у вас уже стоит плагин для SEO, проверьте, умеет ли он ставить noindex на страницы поиска. Это самый безопасный путь для большинства сайтов: не нужно править тему, и правило переживает обновления.
Плюс такого подхода — он обычно добавляет корректный meta robots прямо в шаблон страницы. Минус — не все плагины одинаково гибкие, а часть настроек спрятана глубоко в интерфейсе.
Вариант 2: добавить noindex кодом
Если нужен точечный контроль без лишних зависимостей, можно добавить мета-тег через wp_head. Это работает для обычной поисковой страницы WordPress и не требует правки шаблона.
<?php
add_action( 'wp_head', function () {
if ( is_search() ) {
echo '<meta name="robots" content="noindex,follow">' . "\n";
}
} );Здесь важно именно noindex,follow: страница не должна попадать в индекс, но ссылки с неё могут быть обработаны. Для внутреннего поиска это обычно разумнее, чем noindex,nofollow.
Вариант 3: убрать URL поиска из сканирования через robots.txt
Это дополнительная мера, а не замена noindex. Она полезна, если робот активно ходит по поисковым URL и создаёт лишнюю нагрузку.
User-agent: *
Disallow: /*?s=
Disallow: /?s=Но не рассчитывайте, что одна только директива решит вопрос с уже проиндексированными страницами. Для удаления из индекса нужен именно noindex или последующее естественное выпадение после переобхода.
Когда нужен редирект, а не noindex
Если на сайте есть старые поисковые URL с мусорными параметрами, которые больше не используются, их можно перенаправить на главную или на чистую страницу поиска. Но это стоит делать осторожно: редирект не должен ломать реальные поисковые запросы пользователей.
Например, если у вас есть устаревший параметр search вместо стандартного s, можно перенаправить только его:
<?php
add_action( 'template_redirect', function () {
if ( isset( $_GET['search'] ) && ! isset( $_GET['s'] ) ) {
wp_safe_redirect( home_url( '/' ), 301 );
exit;
}
} );Такой код не трогает штатный поиск WordPress и убирает только старый мусорный параметр.
Сравнение подходов
| Способ | Что делает | Когда подходит | Ограничение |
|---|---|---|---|
| SEO-плагин | Ставит noindex и иногда canonical | Если нужен быстрый и поддерживаемый вариант | Зависит от настроек плагина |
Код в wp_head | Даёт точечный контроль над meta robots | Если нужен минимальный и прозрачный способ | Нужно следить за темой и обновлениями |
robots.txt | Ограничивает сканирование | Как дополнительная мера | Не гарантирует удаление из индекса |
Проверка результата после внедрения
После изменений не ограничивайтесь визуальной проверкой. Нужно убедиться, что робот видит именно то, что вы задумали.
- Откройте несколько URL вида
/?s=тести проверьте исходный код страницы. - Убедитесь, что в
<head>есть<meta name="robots" content="noindex,follow">. - Проверьте, что обычные страницы сайта не получили этот тег по ошибке.
- В Search Console отправьте URL на повторную проверку, если они уже были в индексе.
- Посмотрите серверные логи через несколько дней: число обращений к поисковым URL должно снижаться, если они больше не нужны роботам.
Если у вас включён кэш, очистите его после правок. Иначе вы можете проверять старую версию страницы и решить, что код не работает.
Частые ошибки и как их исправить
Ошибка: закрыли поиск только в robots.txt
Такой вариант не убирает уже известные URL из индекса. Исправление простое: добавьте noindex на саму страницу поиска и оставьте robots.txt как дополнительный фильтр.
Ошибка: поставили noindex на весь сайт через общий шаблон
Это часто случается, когда условие написано слишком широко. Например, проверяют не is_search(), а какой-то общий флаг. В результате поисковики перестают индексировать обычные записи и страницы.
Ошибка: забыли про кэш
Если стоит серверный кэш, page cache или CDN, старый HTML может жить дольше, чем вы ожидаете. После правки очистите кэш плагина, объектный кэш и CDN, если он используется.
Ошибка: редиректят все поисковые запросы на главную
Это ухудшает UX и может выглядеть как soft 404. Для штатного поиска WordPress лучше использовать noindex, а не массовый редирект.
Безопасность и производительность
Сам по себе код для noindex безопасен, если он добавлен в дочернюю тему или через небольшой mu-plugin. Не правьте ядро и не вносите изменения в файлы основной темы, которые потом перезапишутся обновлением.
Если на сайте много мусорных поисковых запросов, полезно посмотреть, кто их генерирует. Иногда это не люди, а боты или внутренние ссылки с ошибками. В таком случае закрытие индексации — только часть решения, а вторую часть составляет поиск источника лишних URL.
Для сайтов, где SEO и чистка дублей уже стоят в приоритете, удобно держать такие настройки в одном месте. Например, в Clearfy Pro есть инструменты для технической чистки WordPress и управления дублями, но даже с плагином всё равно стоит проверить итоговый HTML и поведение Search Console вручную: автоматическая настройка не отменяет валидацию.
Мини-чек-лист перед публикацией
- Проверил, что закрываются только URL поиска, а не весь сайт.
- Убедился, что в HTML есть
noindex,follow. - Очистил кэш плагина, сервера и CDN.
- Проверил несколько URL вручную в браузере и в Search Console.
- Оставил robots.txt как дополнительную, а не единственную меру.
Если после внедрения поисковые страницы всё ещё появляются в индексе, обычно причина одна из трёх: робот видит старую версию из кэша, noindex не попал в шаблон, либо URL уже давно в индексе и ему нужно время на переобход. В таких случаях помогает не «усиление запрета», а нормальная проверка цепочки: шаблон, кэш, ответ сервера, индексация.