Страницы внутреннего поиска в WordPress часто попадают в индекс сами по себе: пользователь вводит запрос, получает URL вида ?s=, а поисковик видит десятки или сотни слабых страниц с почти одинаковым шаблоном. Это не всегда критично, но на небольших и средних сайтах такой мусор быстро размывает качество индекса и мешает нормальной обходке важных URL.
Ниже разберём рабочую схему: что именно закрывать, чем отличается noindex от robots.txt, как не сломать поиск на сайте и как проверить, что страницы действительно перестали индексироваться.
Когда внутренний поиск нужно закрывать от индексации
Не каждый сайт обязан прятать поиск. Но если результаты поиска создают отдельные URL и эти страницы не несут самостоятельной ценности, их лучше убрать из индекса. Типичный сценарий: в выдаче появляются URL с параметром ?s=, а в Search Console растёт число «Просканировано, но не проиндексировано» или «Дубликат, Google выбрал другой канонический URL».
Признаки проблемы
- в индексе есть страницы вида
/ ?s=запросили/search/запрос/; - поиск по сайту генерирует много однотипных URL;
- в отчётах Search Console видны слабые или дублирующиеся страницы;
- боты тратят время на обход бесполезных результатов вместо важных материалов.
Если поиск используется как отдельный контентный раздел, например на крупном каталоге с фильтрацией, подход может быть другим. Но для обычного корпоративного сайта, блога или медиа внутренний поиск почти всегда лучше закрыть.
Что именно закрывать: robots.txt, noindex или canonical
Здесь часто путают инструменты. robots.txt запрещает обход, но не гарантирует удаление из индекса, если URL уже известен поисковику. noindex говорит не индексировать страницу, но для этого бот должен иметь возможность её открыть. canonical для страниц поиска обычно не решает задачу, потому что у результата поиска нет нормального канонического аналога.
| Подход | Что делает | Когда уместен | Ограничение |
|---|---|---|---|
robots.txt | Запрещает обход | Дополнительная мера | Не удаляет уже известные URL из индекса |
noindex | Просит не индексировать страницу | Основной вариант для поиска | Страница должна быть доступна для обхода |
canonical | Указывает предпочтительный URL | Для дублей с одной сущностью | Для поиска обычно не подходит |
Практически правильная схема для WordPress — отдать поисковым страницам noindex,follow, а при необходимости дополнить это запретом в robots.txt. Так вы не мешаете обходу сайта, но убираете мусор из индекса.
Пошаговое решение для WordPress
1. Проверьте, как у вас формируется поиск
В WordPress стандартный поиск обычно работает через параметр ?s=. Некоторые темы и плагины меняют его на ЧПУ-адреса вроде /search/term/. Это важно, потому что закрывать нужно именно тот вариант, который реально генерируется на сайте.
Откройте несколько поисковых URL вручную и посмотрите исходный код страницы. Если в <head> уже есть noindex, возможно, тема или SEO-плагин это делает автоматически. Если нет — добавьте правило сами.
2. Добавьте noindex для страниц поиска
Самый надёжный способ — через хук wp_robots. Он есть в современных версиях WordPress и позволяет корректно добавить директивы без правки шаблонов.
add_filter( 'wp_robots', function( $robots ) {
if ( is_search() ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
} );Этот код можно добавить в functions.php дочерней темы или в небольшой mu-plugin. Если на сайте уже используется SEO-плагин, сначала проверьте, не делает ли он то же самое, чтобы не получить конфликт логики.
3. При необходимости закройте обход в robots.txt
Если поисковые URL активно сканируются и создают нагрузку, можно дополнительно запретить их обход. Но делайте это только как дополнительную меру, а не вместо noindex.
User-agent: *
Disallow: /?s=
Disallow: /search/С параметром ?s= есть нюанс: в robots.txt такие правила не всегда работают одинаково у разных ботов, а сам файл не умеет «понимать» параметры как PHP. Поэтому не рассчитывайте на него как на единственный механизм.
4. Если используете SEO-плагин, проверьте его настройки
Во многих SEO-плагинах есть отдельная опция для закрытия страниц поиска от индексации. Это удобнее, чем писать код, если на сайте уже есть централизованное управление мета-тегами. Но важно убедиться, что плагин не только ставит noindex, но и не ломает шаблон поиска.
Если у вас стоит Clearfy Pro, в нём есть инструменты для технической чистки и управления дублями. В таком случае логично сначала проверить, не решается ли задача штатной настройкой, а код использовать только если нужен точечный контроль.
Как проверить, что решение сработало
Проверка должна быть не на глаз, а по факту. Сначала откройте страницу поиска в браузере и посмотрите исходный код: в блоке robots должна быть директива noindex. Затем проверьте заголовки ответа, если вы добавляли серверную логику или используете плагин, который меняет мета-теги на уровне шаблона.
- Откройте URL поиска и найдите
<meta name="robots"или директивы, которые выводит тема/плагин. - Проверьте, что страница не получает статус
404или500после изменений. - В Search Console отправьте URL на проверку и посмотрите, как бот видит страницу.
- Через несколько обходов проверьте, исчез ли URL из отчётов об индексировании.
Если страница всё ещё индексируется, обычно причина одна из трёх: noindex не выводится на реальной странице поиска, бот не может её обойти из-за robots.txt, либо на сайте есть другой плагин, который перезаписывает мета-теги.
Частые ошибки и как их исправить
Закрыли только robots.txt, но не добавили noindex
Это самая частая ошибка. Если URL уже известен поисковику, запрет обхода не гарантирует удаление из индекса. Исправление простое: оставьте robots.txt как дополнительную меру, но обязательно добавьте noindex.
Поставили noindex на все страницы сайта
Иногда правило пишут слишком широко и случайно закрывают архивы, записи или даже главную. Проверяйте условие is_search() и не используйте универсальные фильтры без проверки контекста.
Сломали поиск в теме
Если тема выводит результаты через нестандартный шаблон, а вы вмешались в pre_get_posts или переписали запрос, можно случайно нарушить сам поиск. Для задачи индексации обычно не нужно менять SQL-запросы — достаточно управлять мета-роботами.
Использовали canonical как замену noindex
Для страниц поиска это слабое решение. Каноникал не объясняет поисковику, что страница бесполезна как отдельный документ. Если цель — убрать мусор, используйте именно noindex.
Что делать, если поиск уже в индексе
Если поисковые URL уже попали в индекс, не ждите мгновенного удаления. Сначала убедитесь, что на страницах стоит noindex, потом проверьте, не блокирует ли robots.txt обход раньше, чем бот увидит директиву. После этого можно ускорить переобход через Search Console, но без фанатизма: поисковик всё равно будет обновлять индекс по своему графику.
Если на сайте много технического мусора, имеет смысл посмотреть шире: убрать лишние архивы, закрыть служебные страницы, проверить пагинацию и дубли мета-тегов. Для этого часто удобнее использовать один инструмент технической оптимизации, чем собирать набор разрозненных правок вручную.
Практические советы по безопасности и производительности
Не правьте functions.php основной темы напрямую: после обновления изменения пропадут. Лучше использовать дочернюю тему или небольшой mu-plugin. Если на сайте несколько SEO- и кэш-плагинов, после внедрения очистите кэш страницы и объектный кэш, иначе вы будете проверять старую версию HTML.
Если сайт большой, не добавляйте тяжёлую логику в каждый запрос. Для задачи с поиском достаточно одного лёгкого фильтра, без дополнительных запросов к базе и без проверки внешних сервисов.
<?php
/**
* Plugin Name: Noindex for search pages
*/
add_filter( 'wp_robots', function( $robots ) {
if ( is_search() ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
} );Такой mu-plugin легко отключить, он не зависит от темы и не требует редактирования шаблонов. Для технических задач это обычно надёжнее, чем держать правку в теме, которую потом обновят или заменят.
Когда лучше решить задачу плагином, а когда кодом
Если на сайте уже есть SEO-плагин с понятной настройкой для поисковых страниц, используйте его. Если нужна точечная логика только для поиска, а не для всех архивов, код в mu-plugin даёт больше контроля и меньше лишних зависимостей.
| Вариант | Плюсы | Минусы |
|---|---|---|
| SEO-плагин | Быстро, без кода, удобно для редактора | Может конфликтовать с темой или другим SEO-слоем |
| Код в mu-plugin | Точный контроль, не зависит от темы | Нужна аккуратность и доступ к файлам |
| Только robots.txt | Просто внедрить | Недостаточно для удаления уже известных URL |
Если нужен более широкий набор технических правок — например, чистка дублей, управление служебными страницами и техническими мета-тегами — такие задачи обычно удобнее собирать в одном инструменте, а не размазывать по теме и нескольким плагинам. Но даже в этом случае проверка результата остаётся обязательной: откройте реальный URL, посмотрите HTML и убедитесь, что поисковик видит именно то, что вы задумали.