Страницы внутреннего поиска в WordPress часто становятся мусорным трафиком для индекса: у них нет уникальной ценности, они плодят тонны URL с параметрами и иногда создают дубли по одному и тому же запросу. Типичный пример — ?s=, а если на сайте стоит расширенный поиск, к нему добавляются фильтры, сортировки и пагинация. В итоге поисковик тратит обход на служебные страницы, а в отчётах вы видите странные URL, которые не должны ранжироваться.
Задача здесь не в том, чтобы «сломать поиск», а в том, чтобы аккуратно убрать его страницы из индекса, сохранив работу формы поиска для пользователей и ботов на уровне обхода сайта.
Когда это действительно проблема
Проверять нужно не по ощущениям, а по фактам. Если в индексе уже есть страницы вида / ?s=запрос, это видно в site:-проверках, в Google Search Console и в логах обхода. Ещё один признак — в отчётах появляются URL с одинаковым шаблоном, но разными поисковыми фразами. Такие страницы почти всегда содержат мало контента, быстро меняются и не дают стабильной поисковой ценности.
Что именно искать в диагностике
- URL с параметром
sв индексе или в отчётах обхода. - Дубли страниц поиска с разными запросами, но одинаковой структурой.
- Страницы поиска, которые отдают
200 OKи имеют обычный meta robots безnoindex. - Ссылки на поиск в шаблоне, которые генерируют индексируемые URL без ограничений.
Если у вас стоит плагин SEO, сначала проверьте его настройки: иногда нужный флаг уже есть, но не включён. Если плагина нет, решение можно сделать кодом в теме или в небольшом mu-plugin.
Как закрыть страницы поиска от индексации
Есть два рабочих подхода: через SEO-плагин и через код. Первый удобнее, если вы не хотите править тему. Второй полезен, когда нужен точный контроль без лишних зависимостей.
| Подход | Плюсы | Минусы |
|---|---|---|
| SEO-плагин | Быстро, без правки кода, проще поддерживать | Зависит от конкретного плагина и его настроек |
| Код в теме / mu-plugin | Точный контроль, не зависит от интерфейса плагина | Нужно аккуратно тестировать после обновлений |
| robots.txt | Просто запретить обход | Не всегда убирает URL из индекса, если они уже известны поисковику |
Вариант 1: добавить noindex для страниц поиска
Для WordPress можно повесить noindex,follow на результаты поиска. Это не мешает пользователю пользоваться поиском, но сигнализирует поисковым системам, что индексировать такие страницы не нужно.
add_filter('wp_robots', function ($robots) {
if (is_search()) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
});Этот вариант работает на современных версиях WordPress, где используется фильтр wp_robots. Если у вас SEO-плагин уже управляет robots meta, проверьте, не конфликтует ли он с этим кодом. Обычно достаточно оставить один источник управления.
Вариант 2: отдать X-Robots-Tag для поиска
Если нужно закрыть не только HTML-страницу, но и любые ответы, связанные с поиском, можно добавить HTTP-заголовок. Это полезно, когда шаблон страницы формируется нестандартно или когда вы хотите продублировать правило на уровне ответа сервера.
add_action('send_headers', function () {
if (is_search()) {
header('X-Robots-Tag: noindex, follow', true);
}
});Такой способ не заменяет meta robots, но может быть хорошим дополнительным слоем. Главное — не ставить его без проверки, если на сайте есть кэш на уровне сервера или CDN: заголовок должен реально доходить до клиента.
Вариант 3: запретить обход в robots.txt
Иногда добавляют правило Disallow для поисковых URL. Это снижает нагрузку на обход, но не решает вопрос индексации полностью. Если URL уже известен поисковику, он может оставаться в выдаче без сниппета. Поэтому robots.txt стоит использовать как дополнительную меру, а не как единственную.
User-agent: *
Disallow: /?s=
Disallow: /search/Для WordPress это не универсальная панацея: формат URL поиска зависит от структуры сайта и настроек ЧПУ. Перед правкой robots.txt проверьте, какой именно адрес генерирует ваша форма поиска.
Пошаговое решение без лишнего риска
- Проверьте, какие URL поиска реально индексируются:
?s=,/search/или кастомный путь. - Определите, кто управляет meta robots: SEO-плагин, тема или ваш код.
- Добавьте
noindex,followдля страниц поиска. - При необходимости продублируйте ограничение через
X-Robots-Tag. - Обновите robots.txt только как вспомогательную меру.
- Очистите кэш сайта и CDN, если он есть.
Если на сайте используется плагин вроде Clearfy Pro, проверьте, нет ли там уже готовой настройки для закрытия служебных страниц и удаления дублей: иногда проще включить штатную опцию, чем поддерживать собственный код. Но если вы уже ведёте SEO-логику в теме, не смешивайте два источника правил без необходимости.
Как проверить, что решение сработало
Проверка должна быть в двух плоскостях: ответ сервера и видимость для поисковика. Сначала откройте страницу поиска в браузере и посмотрите исходный код: в <head> должен появиться noindex или соответствующий HTTP-заголовок. Затем проверьте ответ через curl.
curl -I 'https://example.com/?s=тест'В ответе ищите X-Robots-Tag: noindex, follow, если вы добавляли заголовок. Для meta robots откройте HTML и проверьте, что на странице поиска нет индексирующего robots-тега. После этого отправьте URL на повторную проверку в Google Search Console и посмотрите, как меняется статус страницы.
Если сайт большой, полезно ещё раз пройтись по логам обхода или по отчётам сканирования в SEO-инструменте: число запросов к страницам поиска должно снижаться, а в индексе — исчезать служебные URL.
Частые ошибки и как их исправить
Закрыли поиск в robots.txt, но URL остались в индексе
Это ожидаемо. Robots.txt ограничивает обход, а не гарантирует удаление из индекса. Если URL уже известен поисковику, нужен noindex или удаление через инструменты вебмастера.
Поставили noindex, но страница всё равно индексируется
Чаще всего причина в кэше: старый HTML или заголовок продолжает отдаваться из CDN или кеширующего плагина. Сначала сбросьте кэш, потом проверьте ответ повторно. Ещё одна причина — конфликт с SEO-плагином, который перезаписывает robots meta.
Сломали внутренний поиск для пользователей
Так бывает, если вместо noindex вы запретили саму обработку URL или закрыли слишком широкий путь в серверных правилах. Не блокируйте доступ к странице поиска, если она нужна посетителям. Закрывать нужно индексацию, а не функциональность.
Сделали правило только для ?s=, но забыли о кастомном поиске
На некоторых сайтах поиск вынесен в отдельный путь или работает через AJAX. В этом случае одного правила для ?s= недостаточно. Сначала посмотрите, какой URL реально формируется, и только потом добавляйте ограничение.
Практические советы по безопасности и производительности
Если вы добавляете код в functions.php, лучше вынести его в mu-plugin. Так правило не пропадёт при смене темы и не потеряется после обновления шаблона. Для небольших правок это надёжнее, чем править родительскую тему.
Не плодите несколько одинаковых механизмов сразу: если SEO-плагин уже ставит noindex, а вы ещё и вручную добавили заголовок, это обычно не критично, но усложняет поддержку. Лучше оставить один основной источник и один резервный, если он действительно нужен.
И ещё момент по производительности: если поиск на сайте активно используется и генерирует много запросов, подумайте не только об индексации, но и о нагрузке на базу. Иногда полезно ограничить частоту тяжёлых поисковых запросов, добавить более релевантный поиск по заголовкам или подключить отдельный поисковый движок. Но это уже отдельная задача — не смешивайте её с закрытием от индексации.
Если вам нужен более широкий контроль над служебными страницами, дублями и технической чисткой сайта, в экосистеме WPShop есть Clearfy Pro: https://wpshop.ru/plugins/clearfy?utm_source=wpelement.ru&utm_medium=article&utm_campaign=kak-zakryt-ot-indeksacii-stranicy-poiskovogo-poiska-v-wordpress. Его имеет смысл рассматривать именно как инструмент для технической гигиены, а не как замену пониманию того, какие URL вы закрываете и почему.