Страницы внутреннего поиска в WordPress часто попадают в индекс не потому, что они полезны, а потому что поисковик находит их по ссылкам, параметрам URL и шаблонным страницам. В результате в выдаче появляются пустые или почти пустые страницы с запросами вроде ?s=, которые не дают трафика и размывают качество индекса.
Если у вас уже есть статьи про архивы авторов и технические страницы, логичный следующий шаг — отдельно закрыть именно поиск. Это другой сценарий: здесь важно не сломать сам поиск на сайте и не закрыть лишнее, например страницы результатов фильтров или внутренние страницы каталога, если они реально нужны.
Когда проблема действительно есть
Сначала проверьте, что в индекс попали именно страницы поиска, а не просто похожие URL. В WordPress внутренний поиск обычно выглядит так: https://site.ru/?s=запрос. Иногда тема или плагин генерируют человекопонятные адреса вида /search/запрос/, но суть та же — это динамические страницы, которые редко должны индексироваться.
Признаки, что поиск уже засоряет выдачу
- в Google Search Console есть URL с параметром
s=или путём поиска; - в поиске по сайту находятся страницы с одинаковыми заголовками и разным запросом;
- в индексе много страниц с тонким контентом, где единственный текст — результаты поиска;
- роботам доступны страницы поиска без явного запрета, и они получают статус
200 OK.
Проверить это можно вручную. Откройте несколько URL поиска и посмотрите исходный HTML: есть ли там мета-тег robots, canonical и не закрыта ли страница от индексации на уровне заголовков.
Что именно закрывать: robots.txt, noindex или оба варианта
Здесь часто путают две задачи. robots.txt управляет обходом, а noindex — индексацией. Если запретить только обход, поисковик может ещё долго помнить старые URL в индексе. Если поставить только noindex, робот всё равно будет заходить на страницу, но не добавит её в выдачу.
Для внутренних страниц поиска обычно безопаснее сочетать оба подхода: ограничить обход через robots.txt и добавить noindex, follow на сами страницы поиска. Это не мешает пользователю искать по сайту и не ломает внутренние ссылки.
| Подход | Что делает | Когда применять |
|---|---|---|
| robots.txt | Запрещает обход URL | Как дополнительный слой, но не как единственный способ |
| noindex | Убирает страницу из индекса | Основной способ для страниц поиска |
| canonical на главную | Сигнализирует о предпочтительном URL | Обычно не подходит для поиска, может быть неверно интерпретирован |
Пошаговое решение без лишних плагинов
Если у вас есть доступ к теме или мини-плагину, лучше закрыть поиск кодом. Так вы не зависите от настроек SEO-плагина и не рискуете потерять правило при смене темы.
Шаг 1. Добавьте запрет в robots.txt
Если WordPress генерирует виртуальный robots.txt, можно добавить правило через фильтр robots_txt. Это не всегда достаточно само по себе, но как дополнительная мера работает нормально.
<?php
add_filter('robots_txt', function ($output, $public) {
$output .= "\nDisallow: /?s=";
$output .= "\nDisallow: /search/";
return $output;
}, 10, 2);
Если поиск у вас работает только через параметр ?s=, строку Disallow: /search/ можно убрать. Но не пытайтесь закрыть слишком широко, например Disallow: /?s — это уже может задеть другие параметры.
Шаг 2. Добавьте noindex на страницы поиска
Надёжнее всего повесить мета-тег robots на сам шаблон результатов поиска. В WordPress для этого подходит хук wp_head.
<?php
add_action('wp_head', function () {
if (is_search()) {
echo '<meta name="robots" content="noindex, follow">' . "\n";
}
});
Если вы используете SEO-плагин, сначала проверьте, не делает ли он это уже сам. Дублировать одинаковые мета-теги не нужно: это не ломает сайт, но создаёт шум в коде и усложняет диагностику.
Шаг 3. При необходимости закройте поиск на уровне заголовка
Для некоторых проектов удобнее отправлять X-Robots-Tag в HTTP-заголовке. Это полезно, если поиск рендерится не только как HTML-страница, но и через отдельные шаблоны или API-ответы, которые тоже не должны индексироваться.
<?php
add_action('template_redirect', function () {
if (is_search() && !headers_sent()) {
header('X-Robots-Tag: noindex, follow', true);
}
});
Этот вариант особенно удобен, если тема активно меняет <head> или вы не хотите править шаблон. Но всё равно проверьте, что заголовок реально уходит в ответе.
Если используете SEO-плагин
Во многих случаях проще закрыть поиск через настройки SEO-плагина, если он умеет управлять мета-robots для архивов и служебных страниц. Но важно смотреть не на красивую кнопку, а на фактический результат в HTML и заголовках.
У плагинов бывают разные модели: одни ставят noindex только в HTML, другие ещё и меняют canonical, третьи позволяют отдельно закрывать поиск в robots. Это нормально, пока не возникает конфликт с темой или другим SEO-инструментом.
- проверьте, не дублируется ли
noindexв коде темы и плагина; - посмотрите, не меняется ли canonical на главную страницу;
- убедитесь, что поиск не закрыт случайно для админки или AJAX-эндпоинтов;
- после сохранения настроек очистите кеш страницы и кеш CDN, если он есть.
Как проверить, что решение сработало
Проверка должна быть не формальной, а по факту ответа сервера и индексации. Сначала откройте страницу поиска в браузере и посмотрите исходный код. В <head> должен быть тег noindex, follow или соответствующий заголовок.
Затем проверьте ответ через curl или инструменты разработчика:
curl -I "https://site.ru/?s=test"
В ответе ищите строку X-Robots-Tag: noindex, follow, если вы использовали заголовок. Для HTML-варианта откройте страницу и убедитесь, что мета-тег присутствует в исходнике, а не только в DOM после JavaScript.
Дальше проверьте Search Console. Если URL уже был в индексе, он не исчезнет мгновенно: поисковику нужно время на переобход. Но после нескольких обходов статус должен смениться на исключённый или неиндексируемый.
Частые ошибки и как их исправить
Закрыли только robots.txt и ждёте мгновенного удаления
Это самая частая ошибка. robots.txt не удаляет URL из индекса, а только ограничивает обход. Если страница уже известна поисковику, она может ещё долго отображаться в выдаче без сниппета или с устаревшим описанием. Добавляйте noindex.
Поставили noindex на все страницы сайта
Иногда разработчик вешает условие слишком широко, например без проверки is_search(). В итоге под запрет попадают обычные записи, страницы или архивы. Проверяйте условие и тестируйте на нескольких типах URL.
Сломали поиск для пользователей
Запрет индексации не должен отключать сам поиск. Если после правок форма поиска перестала работать, значит вы затронули шаблон, обработчик запроса или редирект. В таком случае откатите изменения и перенесите логику в отдельный мини-плагин.
Дублируете правила в нескольких местах
Когда noindex ставит и тема, и SEO-плагин, и серверный middleware, диагностика становится сложнее. Оставьте один основной источник правила и документируйте его в коде.
Чек-лист перед публикацией правок
- страницы поиска доступны пользователю и показывают результаты;
- в исходном коде есть
noindex, followили заголовокX-Robots-Tag; - в
robots.txtнет слишком широких запретов; - canonical не указывает на случайную страницу;
- кеш страницы и CDN очищены;
- в Search Console проверен конкретный URL поиска.
Практические советы по безопасности и производительности
Не храните такие правки прямо в functions.php активной темы, если сайт часто обновляется. Лучше вынести код в небольшой mu-plugin или отдельный плагин проекта. Тогда правило не исчезнет после смены темы и его проще сопровождать.
Если у вас большой сайт, не полагайтесь только на визуальную проверку. После внедрения посмотрите логи обхода, отчёты Search Console и кеширующий слой: иногда страница поиска отдаёт старый HTML из кеша, хотя код уже исправлен. В таком случае нужно очистить не только страницу, но и объектный кеш, если он используется.
Для проектов с жёсткой SEO-гигиеной удобно держать такие технические правила в одном месте вместе с другими настройками индексации. Если нужен более широкий набор инструментов для чистки дублей и технических страниц, можно посмотреть Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже в этом случае проверка результата остаётся вашей задачей: плагин не заменяет контроль ответа сервера и индексации.