Внутренний поиск WordPress часто создает мусорные URL с параметром ?s=, которые не дают трафик, но могут попадать в индекс и раздувать отчет по дублям. На небольших сайтах это выглядит как мелочь, а на контентных проектах быстро превращается в набор страниц с пустыми сниппетами, низким качеством и лишней нагрузкой на краулер.
Задача здесь не в том, чтобы «спрятать все подряд», а в том, чтобы аккуратно закрыть именно результаты поиска, не трогая нормальные страницы сайта и не ломая работу формы поиска для пользователей.
Когда внутренний поиск WordPress лучше закрыть от индексации
Если поиск используется только как навигация по сайту, а не как отдельная посадочная страница, его почти всегда имеет смысл исключить из индекса. Особенно это касается случаев, когда:
- в выдаче поиска часто пустые или почти пустые страницы;
- поисковые URL отличаются только запросом, а контент на них не уникален;
- в Search Console появляются страницы вида
/ ?s=...или/search/...; - поиск генерирует много однотипных запросов от ботов;
- на сайте уже есть категории, теги и фильтры, которые лучше подходят для индексации.
Если же у вас каталог, база знаний или большой архив, где поисковая выдача реально полезна пользователю и может ранжироваться, закрывать ее бездумно не стоит. В таком случае сначала проверьте, не проще ли ограничить индексацию только пустых и служебных запросов.
Диагностика проблемы: что именно индексируется
Перед правками нужно понять, как именно WordPress отдает поиск. Стандартный вариант — URL с параметром ?s=запрос. Некоторые темы и плагины дополнительно делают «красивый» URL поиска, но логика остается той же: это служебная страница выдачи, а не отдельный контентный раздел.
Что проверить в первую очередь
- Откройте поиск на сайте и посмотрите URL в адресной строке.
- Проверьте, есть ли в исходном коде страницы мета-тег
noindex. - Посмотрите, не закрыт ли поиск уже в
robots.txtили через SEO-плагин. - В Google Search Console найдите страницы с параметром
s=в отчете по индексированию.
Если страницы поиска уже в индексе, одного robots.txt обычно недостаточно. Бот может увидеть URL, но не всегда сможет корректно понять, что вы хотите исключить его из индекса. Для надежного результата лучше сочетать несколько методов.
Пошаговое решение: как закрыть поиск WordPress
Есть три рабочих подхода: через SEO-плагин, через код темы или плагина, и через robots.txt как дополнительную меру. На практике лучше не выбирать что-то одно, а собрать решение из двух слоев: noindex для самих страниц и запрет обхода для лишних ботовых запросов, если это уместно.
Вариант 1. Добавить noindex на страницы поиска
Если у вас установлен SEO-плагин, проверьте, умеет ли он задавать noindex для страниц поиска. Это самый простой путь, потому что он не требует правки шаблонов и обычно переживает обновления темы.
Если нужен код, можно добавить мета-тег в <head> через wp_head. Пример ниже работает для обычной поисковой выдачи WordPress:
add_action('wp_head', function () {
if (is_search()) {
echo '<meta name="robots" content="noindex,follow" />' . "\n";
}
});Здесь важно именно noindex,follow: страница не должна попадать в индекс, но ссылки с нее могут быть просканированы. Если вы хотите еще и сократить обход, можно дополнительно закрыть такие URL в robots.txt, но не рассчитывайте только на это.
Вариант 2. Закрыть поиск через robots.txt
Этот способ полезен как дополнительный, когда на сайте много бесполезных запросов к поиску. Но он не заменяет noindex. Если бот не зайдет на страницу, он может не увидеть мета-тег и не всегда быстро уберет URL из индекса.
Пример правила для стандартного поиска WordPress:
User-agent: *
Disallow: /*?s=
Disallow: /search/Если у вас в теме или плагине используется только параметр ?s=, второй запрет может не понадобиться. Но на практике лучше сначала посмотреть реальные URL, которые генерирует сайт, и только потом добавлять правила.
Вариант 3. Убрать индексируемые ссылки на пустые поисковые запросы
Иногда проблема не в самой странице поиска, а в том, что тема или блоки контента создают ссылки на поисковые запросы из внутренних элементов. Например, в шаблоне могут быть ссылки на поиск по тегам, авторам или ключевым словам. Такие ссылки лучше не выводить как обычные внутренние URL, если они не несут ценности.
Если вы пишете собственный шаблон, проверьте, не формируются ли ссылки на поиск через get_search_link() или прямой конкатенацией параметра s. Для служебных ссылок можно вообще убрать их из HTML, а для пользовательского поиска оставить только форму.
Если нужен точечный контроль через код темы
Иногда SEO-плагина нет, а править robots.txt недостаточно. Тогда удобнее добавить небольшую функцию в дочернюю тему или в собственный мини-плагин. Это безопаснее, чем вносить правки прямо в родительскую тему.
add_filter('wp_robots', function ($robots) {
if (is_search()) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
});Этот вариант предпочтительнее, чем печатать мета-тег вручную, потому что WordPress сам сформирует корректный robots-массив. Но если тема или плагин уже добавляют свои правила, проверьте итоговый HTML, чтобы не получить конфликтующие директивы.
Сравнение подходов
| Способ | Плюсы | Минусы | Когда использовать |
|---|---|---|---|
| SEO-плагин | Быстро, без кода, проще сопровождать | Зависит от возможностей плагина | Если плагин уже стоит и умеет управлять robots |
Код через wp_robots | Точно, без лишних зависимостей | Нужен доступ к теме или мини-плагину | Если нужен контроль на уровне шаблона |
robots.txt | Снижает обход лишних URL | Не гарантирует исключение из индекса | Как дополнительная мера, не вместо noindex |
Проверка результата после внедрения
После правок не ограничивайтесь визуальной проверкой страницы. Нужно убедиться, что поисковики видят именно то, что вы задумали.
- Откройте страницу поиска в браузере и проверьте исходный код на наличие
noindex. - Проверьте, не отдает ли сервер кэшированную старую версию без мета-тега.
- В Search Console используйте проверку URL для нескольких поисковых страниц.
- Убедитесь, что обычные страницы сайта не получили случайный
noindex. - Посмотрите, не блокирует ли
robots.txtважные разделы по ошибке.
Если вы используете кэш-плагин или серверный кэш, очистите его после изменения кода. Иначе можно долго искать проблему в WordPress, хотя бот просто видит старую HTML-версию.
Частые ошибки и как их исправить
Закрыли только robots.txt и ждете удаления из индекса
Это самая частая ошибка. Disallow мешает обходу, но не всегда убирает URL из индекса. Добавьте noindex на сами страницы поиска и дайте поисковику переобойти их.
Поставили noindex на все страницы сайта
Такое случается, когда условие в коде написано слишком широко или вставлено не туда. Проверяйте, что функция срабатывает только на is_search(), а не на всех архивных страницах.
Сломали поиск для пользователей
Иногда после правок исчезает форма поиска, потому что разработчик путает индексацию страницы и сам механизм поиска. Закрывать нужно выдачу, а не отключать поиск как функцию.
Не учли кэш
Если на сайте стоит кэширование HTML, старые версии страниц могут продолжать отдаваться ботам. После внедрения обязательно очистите кэш на уровне плагина, сервера и CDN, если он есть.
Практические советы по безопасности и производительности
Поисковые запросы — это еще и потенциальная точка лишней нагрузки. На небольшом сайте это не критично, но если боты активно дергают ?s=, база и PHP могут получать ненужные запросы. Поэтому полезно:
- не индексировать пустые и служебные поисковые страницы;
- не выводить в поиск тяжелые поля, если они не нужны;
- ограничить количество результатов на странице поиска, если тема делает слишком дорогую выборку;
- следить, чтобы поиск не использовал лишние JOIN-запросы без необходимости;
- проверять, не генерирует ли тема дубли заголовков и мета-описаний для search results.
Если вы используете Clearfy Pro, часть задач по чистке дублей и служебных страниц можно закрыть через его настройки, но логику все равно стоит проверить вручную на конкретном сайте: плагины не угадывают структуру темы и не знают, как у вас устроен поиск.
Когда лучше не закрывать поиск полностью
Есть сайты, где поисковая выдача сама по себе полезна: большие каталоги статей, документация, архивы знаний. В таких проектах иногда имеет смысл оставить поиск доступным для обхода, но закрыть только пустые запросы, внутренние служебные страницы и результаты с нулевой ценностью. В этом случае решение должно опираться на реальные URL и поведение бота, а не на универсальную настройку «на всякий случай».
Если после внедрения вы видите, что в индексе остались старые search-URL, это нормально: поисковикам нужно время на переобход. Проверьте, что новые страницы поиска уже отдают noindex, и дождитесь повторной обработки.