Внутренний поиск WordPress часто создает мусорные URL, которые не нужны в индексе: страницы с пустыми запросами, дубли с параметрами, бесконечные комбинации фильтров и сортировок. Если их не контролировать, поисковик начинает тратить обход на технические страницы, а в отчётах появляются странные URL без трафика.
Задача здесь не в том, чтобы «запретить всё подряд», а в том, чтобы аккуратно закрыть именно страницы результатов поиска и при этом не сломать навигацию по сайту, canonical и аналитику.
Когда проблема действительно есть
Сначала проверьте, что в индексе или в обходе поисковика уже появились URL вида ?s=, /search/ или страницы с параметрами поиска. На небольшом сайте это может быть незаметно, но на контентном проекте такие адреса быстро расползаются.
Признаки, которые видно без догадок
- в Google Search Console в отчёте по страницам есть URL с параметром
s; - в логах сервера много запросов к поисковым страницам с разными query string;
- поисковая выдача показывает внутренние страницы поиска вместо нормальных посадочных;
- на сайте есть темы или плагины, которые генерируют отдельный шаблон поиска с индексируемым заголовком и мета-тегами.
Если поиск используется только как внутренняя функция для посетителя, а не как отдельная посадочная страница, индексировать его обычно не нужно.
Что именно закрывать: noindex, robots.txt или canonical
Для внутренних страниц поиска чаще всего нужен noindex,follow. Это оставляет ссылкам возможность передавать сигнал обхода, но запрещает попадание страницы в индекс. robots.txt подходит не всегда: если вы запретите обход, поисковик может не увидеть мета-тег noindex на самой странице.
Canonical на страницу поиска обычно не решает задачу сам по себе. У поисковой страницы нет полноценного канонического аналога, поэтому canonical здесь — не основной инструмент, а вспомогательный. Если у вас есть отдельная страница каталога или архива, на которую логично сводить поиск, тогда можно рассматривать canonical, но это уже частный сценарий.
| Подход | Когда использовать | Ограничение |
|---|---|---|
noindex,follow | Для внутренних страниц поиска | Нужно, чтобы поисковик мог обойти страницу |
robots.txt | Для грубого отсечения техстраниц | Не всегда позволяет передать noindex |
| canonical | Если есть явная замена поисковой странице | Не подходит как единственная мера |
Пошаговое решение через код
Если тема или SEO-плагин не дают нужного результата, проще и надёжнее добавить правило в код темы или в небольшой mu-plugin. Ниже вариант, который добавляет noindex,follow на стандартную страницу поиска WordPress.
<?php
add_action( 'wp_head', function () {
if ( is_search() ) {
echo '<meta name="robots" content="noindex,follow" />' . "\n";
}
}, 1 );
Этот код работает на фронтенде и не трогает обычные страницы. Если у вас уже есть SEO-плагин, проверьте, не выводит ли он свой robots meta tag. Два конкурирующих тега в head — частая причина путаницы.
Если нужно ещё и убрать внутренний поиск из sitemap или из выдачи плагина, это делается отдельно. Не смешивайте задачи: noindex отвечает за индекс, а sitemap — за подсказку поисковику.
Если поиск живёт на отдельном URL
Некоторые темы и плагины делают красивый адрес вроде /search/term/. В таком случае логика та же: определяйте шаблон поиска и выводите noindex,follow на уровне шаблона или через хук wp_head. Главное — не полагаться на название URL, а проверять условие is_search().
<?php
add_filter( 'wp_robots', function ( array $robots ) {
if ( is_search() ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
} );
Этот вариант лучше, если вы используете современную сборку WordPress и хотите не печатать мета-тег вручную. Фильтр wp_robots штатный, и он не конфликтует с ядром так грубо, как самодельный вывод в wp_head.
Если нужен запрет только для пустого поиска
Иногда закрывать весь поиск не хочется: например, у вас есть полезные результаты по каталогу материалов, а проблема только в запросах без смысла. Тогда можно отдать 404 или редиректить пустой поиск на главную или на страницу поиска с подсказкой. Но это надо делать аккуратно, чтобы не сломать пользовательский сценарий.
<?php
add_action( 'template_redirect', function () {
if ( is_search() ) {
$query = trim( get_search_query( false ) );
if ( $query === '' ) {
wp_safe_redirect( home_url( '/' ), 302 );
exit;
}
}
} );
Такой редирект имеет смысл только для пустого запроса. Если вы начнёте редиректить все поисковые страницы, пользователи потеряют возможность искать по сайту, а поисковик увидит цепочки редиректов вместо нормального ответа.
Проверка результата после внедрения
После изменения не ограничивайтесь просмотром исходника. Нужна проверка на уровне ответа сервера и на уровне индексации.
- Откройте страницу поиска в браузере и проверьте исходный код: должен быть
noindex,followили массив robots сnoindex. - Проверьте, что обычные страницы сайта не получили этот тег случайно.
- В Search Console отправьте проверку URL через инспекцию и посмотрите, как робот видит страницу.
- Если использовали редирект для пустого поиска, убедитесь, что он отдаёт корректный код ответа и не создаёт цепочку.
Для быстрой проверки на сервере удобно использовать curl:
curl -I "https://example.com/?s=test"
В ответе вы не увидите meta-тег, но сможете проверить код ответа, редиректы и заголовки. Сам HTML лучше смотреть отдельным запросом без -I.
Частые ошибки и как их исправить
Закрыли поиск в robots.txt и забыли про noindex
Это самая типичная ошибка. Если страница уже закрыта от обхода, поисковик может не увидеть мета-тег noindex. В итоге URL может ещё долго висеть в индексе как «известный, но не просканированный». Для внутренних поисковых страниц безопаснее сначала дать роботу увидеть страницу с noindex, а уже потом при необходимости ограничивать обход.
Поставили canonical на главную без логики
Так делают часто, когда хотят «собрать вес». Но у поисковой страницы нет прямого аналога, и canonical на главную выглядит для поисковика как слабый сигнал. Если контент не является посадочной страницей, лучше использовать noindex,follow и не пытаться искусственно склеивать разные сущности.
Два SEO-плагина одновременно управляют robots
Если один плагин выводит meta robots, а второй добавляет свой фильтр, итоговый HTML может быть противоречивым. В таком случае оставьте один источник правды: либо SEO-плагин, либо код в теме, либо mu-plugin. Иначе вы будете ловить случайные конфликты после обновлений.
Редиректят все поисковые запросы на главную
Это ломает UX и может ухудшить поведение сайта в аналитике. Редирект имеет смысл только для пустого поиска или для совсем мусорных запросов, которые вы явно определили по правилам. Универсальный редирект для всех ?s= — плохая идея.
Что ещё стоит проверить на сайте
Если вы уже занялись внутренним поиском, посмотрите и на соседние технические страницы: архивы автора, служебные таксономии, страницы пагинации поиска, пустые результаты и URL с параметрами сортировки. Часто проблема не в одном поиске, а в связке из нескольких технических шаблонов.
Для проектов, где много дублей и технических страниц, удобно держать под рукой инструменты для чистки SEO-настроек и управления мета-тегами. Но даже без плагинов базовую задачу можно решить штатными хуками WordPress и проверить результат вручную.
Если нужен практичный набор для технической чистки сайта, посмотрите Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но ставить его имеет смысл только тогда, когда вы понимаете, какие именно технические страницы хотите контролировать.