Страницы внутреннего поиска в WordPress часто попадают в индекс не потому, что сайт «плохо настроен», а потому что поисковик видит у них уникальные URL с параметром ?s=. Для пользователя это полезный инструмент, для SEO — источник мусорных страниц, пустых выдач и дублей с разными запросами. Если на сайте есть активный поиск, лучше сразу решить, что делать с такими URL: закрыть от индексации, оставить для пользователей или отдать поисковику только полезные результаты.
Ниже — рабочий сценарий для типичного сайта на WordPress: что проверить, какие варианты выбрать и как не сломать поиск для живых посетителей.
Когда проблема действительно есть
Сначала стоит убедиться, что речь именно о страницах поиска, а не о нормальных архивных URL. В WordPress внутренний поиск обычно выглядит так: / ?s=запрос. Если поисковик уже начал их обходить, в отчётах можно увидеть такие признаки:
- в индексе появляются URL с параметром
s; - в Search Console растёт число страниц с низкой ценностью;
- в логах сервера заметны частые запросы к поиску по случайным фразам;
- на сайте есть страницы поиска без контента или с сообщением «ничего не найдено».
Отдельный сигнал — когда по запросу в поиске находятся страницы вида example.com/?s=... вместо нормальных материалов. Это почти всегда лишний шум.
Что именно нужно закрывать
Не стоит смешивать несколько задач в одну. У внутреннего поиска есть три разных аспекта:
- индексация — попадание URL в поиск;
- обход — сканирование роботами;
- поведение для пользователя — поиск должен продолжать работать на сайте.
Если просто запретить URL в robots.txt, это не всегда убирает их из индекса. Если поставить только noindex, робот может всё равно тратить ресурсы на обход. Поэтому лучше выбрать способ под задачу, а не один универсальный «запретить всё».
Какой способ выбрать: robots, noindex или код
Для WordPress есть несколько рабочих вариантов. На практике чаще всего используют комбинацию: оставить поиск доступным пользователям, но отдать роботам noindex, follow и при необходимости закрыть часть URL от обхода через robots.txt.
| Способ | Что делает | Когда подходит | Ограничение |
|---|---|---|---|
noindex на страницах поиска | Не даёт страницам попадать в индекс | Почти всегда для внутреннего поиска | Робот может ещё какое-то время обходить URL |
robots.txt | Запрещает обход | Если поиск генерирует много мусорных запросов | Не гарантирует удаление уже проиндексированных URL |
| Код в теме/плагине | Точный контроль над заголовками и мета-тегами | Если нужен предсказуемый результат без лишних плагинов | Нужно аккуратно тестировать после обновлений |
Если сайт небольшой, обычно достаточно noindex и корректного ответа для страниц поиска. Если поиск активно генерирует нагрузку, добавляют ограничение в robots.txt и при необходимости ставят фильтр на заголовок X-Robots-Tag.
Пошаговое решение через код
Самый надёжный вариант — явно сказать WordPress, что страницы поиска не должны индексироваться. Это можно сделать без плагинов, через wp_head. Такой способ не ломает сам поиск: пользователи по-прежнему получают результаты, а робот видит запрет на индексацию.
<?php
add_action( 'wp_head', function () {
if ( is_search() ) {
echo '<meta name="robots" content="noindex, follow" />' . "\n";
}
} );Этого часто достаточно, но лучше добавить ещё и HTTP-заголовок. Он полезен, если поисковик не сразу учитывает мета-тег или если часть страниц отдается без полноценного <head>.
<?php
add_action( 'send_headers', function () {
if ( is_search() && ! headers_sent() ) {
header( 'X-Robots-Tag: noindex, follow', true );
}
} );Оба фрагмента можно разместить в дочерней теме или в небольшом mu-plugin. Для production-сайта mu-plugin удобнее: он не зависит от смены темы.
Если нужно ограничить ещё и обход
Когда внутренний поиск создаёт много бесполезных URL, можно добавить правило в robots.txt. Но делать это стоит осознанно: если страницы уже в индексе, одного запрета на обход мало.
User-agent: *
Disallow: /?s=
Disallow: /search/
Обратите внимание: формат зависит от того, как именно у вас устроен поиск. В WordPress по умолчанию чаще используется ?s=, а не отдельный путь /search/. Если на сайте есть ЧПУ-поиск через плагин или кастомный роут, правило нужно подстроить под реальный URL.
Диагностика после внедрения
Проверять нужно не только наличие мета-тега, но и фактический ответ сервера. Иначе можно получить ситуацию, когда в шаблоне всё выглядит правильно, а робот всё равно видит старую версию страницы из кеша.
- Откройте страницу поиска в браузере, например
/?s=test. - Посмотрите исходный код страницы и убедитесь, что там есть
<meta name="robots" content="noindex, follow" />. - Проверьте заголовки ответа через DevTools,
curl -Iили любой HTTP-клиент. - Убедитесь, что страница не редиректится на главную без причины.
- Через несколько дней проверьте отчёты индексации в Search Console.
Пример быстрой проверки через консоль:
curl -I "https://example.com/?s=test"В ответе стоит увидеть X-Robots-Tag: noindex, follow, если вы добавили заголовок. Если его нет, значит код не сработал или его перехватывает кеш/прокси.
Частые ошибки и как их исправить
Закрыли поиск в robots.txt, но URL остались в индексе
Это нормальная ситуация. robots.txt запрещает обход, но не удаляет уже известные поисковику страницы. Чтобы убрать их из индекса, нужен noindex и время на переобход. Если URL критично много, можно ускорить процесс через удаление устаревших страниц в Search Console, но это уже отдельная операция.
Поставили редирект всех поисковых URL на главную
Так делать не стоит. Пользовательский поиск перестаёт работать, а робот получает неочевидный сигнал. Если запрос не дал результатов, лучше оставить страницу поиска с сообщением «ничего не найдено» и noindex, чем подменять её главной страницей.
Сломали кеш и видят старую версию
Если на сайте есть page cache, CDN или серверный кеш, он может отдавать старый HTML без новых мета-тегов. После правки очистите:
- кеш плагина;
- серверный кеш, если он есть;
- CDN-кеш;
- браузерный кеш для проверки.
Если проблема повторяется, проверьте, не исключена ли страница поиска из обработки кешем по ошибке.
Использовали плагин SEO, но он не закрывает поиск
Некоторые SEO-плагины умеют ставить noindex на поиск, но настройки могут быть выключены или переопределены шаблоном темы. В таком случае проще проверить итоговый HTML и заголовки, чем гадать по интерфейсу плагина. Если нужен более широкий контроль над дублями и технической чисткой, иногда удобнее собрать это в одном инструменте вроде Clearfy Pro: https://wpshop.ru/plugins/clearfy.
Практические советы по безопасности и производительности
Внутренний поиск — это не только SEO-вопрос. Поисковые запросы могут создавать лишнюю нагрузку, особенно если на сайте много контента и нет нормального кеширования. Если запросы часто повторяются, имеет смысл:
- ограничить обход мусорных URL через
robots.txt; - не отдавать тяжёлые шаблоны на пустые поисковые запросы;
- проверить, не индексируются ли страницы с параметрами сортировки и фильтров вместе с поиском;
- не выводить на странице поиска лишние блоки, которые тянут десятки запросов к базе.
Если у вас кастомная тема, полезно отдельно проверить, не добавляет ли она в search.php дополнительные запросы к базе для каждого результата. Иногда именно шаблон, а не сам поиск, становится узким местом.
Как понять, что решение сработало
Хороший результат выглядит так:
- страницы
/?s=...открываются для пользователя; - в исходном коде есть
noindex, follow; - в заголовках ответа есть
X-Robots-Tag, если вы его добавляли; - новые URL поиска не появляются в индексе;
- старые URL постепенно исчезают из отчётов после переобхода.
Если этого не происходит, проверьте три вещи в таком порядке: кеш, фактический HTML и заголовки ответа. В большинстве случаев проблема находится именно там, а не в самом коде.
Когда нужен не только запрет индексации, но и общая чистка технических дублей, удобнее решать задачу системно: закрывать поиск, архивы, параметры и лишние служебные страницы по одному сценарию, а не точечными правками в разных местах темы.