Внутренний поиск WordPress часто создаёт мусорные URL вида ?s=..., которые поисковики могут обходить и, в некоторых конфигурациях, индексировать. На небольшом сайте это выглядит безобидно, но на контентном проекте такие страницы быстро превращаются в источник дублей, пустых результатов и лишней нагрузки на обход. Проблема не в самом поиске, а в том, что он почти всегда генерирует множество бесполезных страниц с одинаковой логикой и слабой ценностью для индекса.
Ниже разберём, как закрыть такие страницы от индексации, не ломая поиск для пользователей и не создавая конфликтов с кэшем, SEO-плагинами и темой.
Когда это действительно проблема
Сначала стоит понять, есть ли у вас вообще повод вмешиваться. Если сайт маленький и поисковые URL не попадают в индекс, можно ограничиться наблюдением. Но если в Search Console уже есть страницы поиска, а в логах или аналитике видно, что боты регулярно ходят по запросам, лучше закрыть их явно.
Типичные признаки
- в индексе появляются URL с параметром
?s=; - в отчётах Search Console растёт количество «Просканировано, но не проиндексировано»;
- поисковые страницы получают дубли title и description;
- на сайте есть фильтры, сортировки или AJAX-поиск, которые создают похожие URL;
- после включения кэша поведение поиска стало нестабильным для пользователей или ботов.
Важно не путать закрытие от индексации и запрет на обход. Для внутренних поисковых страниц обычно достаточно noindex, а не жёсткого запрета в robots.txt. Если закрыть всё через robots, поисковик может не увидеть директиву noindex на самой странице и продолжит учитывать URL как отдельный объект.
Что лучше: плагин, код или robots.txt
Для WordPress есть три рабочих подхода. У каждого свой компромисс: плагин быстрее внедрить, код даёт точечный контроль, robots.txt кажется простым, но часто решает задачу хуже остальных.
| Подход | Когда подходит | Минус |
|---|---|---|
| SEO-плагин | Если уже используется Yoast SEO, Rank Math или похожий плагин | Нужно проверить, не конфликтует ли настройка с темой и кэшем |
| Код в теме или mu-plugin | Если нужен контроль без лишних зависимостей | Нужно аккуратно тестировать после обновлений |
robots.txt | Только как дополнительная мера | Не гарантирует исключение URL из индекса |
Если у вас уже стоит SEO-плагин, сначала проверьте его настройки. Если нет — проще и надёжнее добавить небольшой код, чем городить отдельный плагин ради одной директивы.
Пошаговое решение через код
Самый предсказуемый вариант — добавить noindex,follow для страниц поиска. Это не мешает пользователю пользоваться поиском, но подсказывает роботам не включать такие URL в индекс.
Добавьте код в functions.php дочерней темы или, лучше, в небольшой mu-plugin. Так он не потеряется при обновлении темы.
<?php
add_action( 'wp_head', function () {
if ( is_search() ) {
echo '<meta name="robots" content="noindex,follow" />' . "\n";
}
}, 1 );Если у вас установлен SEO-плагин, он может уже выводить robots meta. В таком случае не дублируйте тег вручную, а настройте источник директивы в одном месте. Два разных meta robots на странице — частая причина путаницы.
Если нужно закрыть только пустые результаты поиска
Иногда полезно индексировать страницы поиска с реальными результатами, но закрыть пустые выдачи. Это уже более тонкая настройка, и она имеет смысл только если вы точно понимаете структуру сайта и поисковый трафик.
<?php
add_action( 'wp_head', function () {
if ( is_search() && ! have_posts() ) {
echo '<meta name="robots" content="noindex,follow" />' . "\n";
}
}, 1 );Такой вариант полезен, если поиск на сайте иногда выдаёт релевантные страницы, но пустые запросы создают шум. Однако на практике чаще закрывают весь внутренний поиск целиком, чтобы не плодить нестабильные URL.
Как сделать это через SEO-плагин
Если вы используете Yoast SEO или Rank Math, проверьте, не решается ли задача штатно. В большинстве случаев можно закрыть архивы поиска и задать robots-директиву без кода. Это удобнее для редактора, но важно понимать, где именно хранится настройка.
Плюс плагина в том, что он обычно учитывает другие SEO-настройки сайта: canonical, sitemap, robots meta. Минус — если на сайте уже есть кастомные фильтры, плагин может не покрыть все сценарии, и тогда код всё равно понадобится.
Что делать с robots.txt
robots.txt можно использовать как дополнительный слой, но не как единственный способ. Для внутренних поисковых URL он не решает задачу полностью. Если робот уже знает URL, запрет на обход не равен исключению из индекса.
Тем не менее, если на сайте много мусорных параметров, можно ограничить обход некоторых шаблонов. Делайте это осторожно и только после проверки, что вы не перекрываете полезные страницы.
User-agent: *
Disallow: /?s=
Disallow: /*?s=Этот фрагмент не универсален для всех конфигураций, поэтому после правки обязательно проверьте, как именно ваш сервер и WordPress отдают URL с параметрами. На некоторых сайтах лучше вообще не трогать robots.txt, а ограничиться noindex.
Проверка результата после внедрения
После изменения нужно убедиться, что страница поиска действительно отдаёт нужную директиву и не конфликтует с другими мета-тегами.
- Откройте страницу поиска в браузере, например
https://site.ru/?s=test. - Посмотрите исходный код страницы и найдите
meta name="robots". - Проверьте, что нет второго conflicting-тега от SEO-плагина или темы.
- В Search Console отправьте URL на проверку и посмотрите, как Google видит страницу.
- Через несколько дней проверьте отчёт по индексированию и список просканированных URL.
Если используете кэш-плагин, очистите кэш после изменения. Иначе вы можете смотреть старую версию страницы и решить, что код не сработал.
Что должно быть видно в исходнике
Для закрытой страницы поиска ожидаем что-то вроде:
<meta name="robots" content="noindex,follow" />Если SEO-плагин выводит canonical на саму страницу поиска, это не всегда ошибка, но canonical и noindex должны быть согласованы. Когда один инструмент говорит «не индексировать», а другой явно указывает страницу как каноническую, поисковик может интерпретировать сигнал не так, как вы ожидаете.
Частые ошибки и как их исправить
- Закрыли поиск только в
robots.txt. Исправление: добавьтеnoindexна саму страницу, а robots используйте только как вспомогательную меру. - Вставили два разных robots meta. Исправление: оставьте один источник директив — либо код, либо SEO-плагин.
- Добавили код в родительскую тему. Исправление: перенесите в дочернюю тему или mu-plugin, иначе обновление всё затрёт.
- Не очистили кэш. Исправление: сбросьте серверный и плагинный кэш, затем перепроверьте HTML.
- Закрыли не только поиск, но и полезные страницы фильтрации. Исправление: проверьте условие
is_search()и не подменяйте его общими правилами для всех URL с параметрами.
Безопасность и производительность
Само по себе закрытие поиска от индексации не ускорит сайт магически, но уменьшит количество бесполезных обходов. Это особенно заметно на проектах, где внутренний поиск часто вызывается ботами и парсерами. Если поисковая форма ещё и тяжёлая, имеет смысл проверить, не создаёт ли она лишнюю нагрузку на базу данных.
Практически полезно:
- ограничить частоту запросов к поиску на уровне сервера или WAF, если сайт атакуют ботами;
- не отдавать в поиск слишком широкий набор пост-типов без необходимости;
- проверить, не индексируются ли ещё и страницы тегов, авторов или внутренних фильтров;
- держать SEO-логику в одном месте, а не размазывать по теме и нескольким плагинам.
Если вам нужен более системный контроль над дублями, мета-тегами и технической чисткой сайта, иногда проще собрать это в одном инструменте, чем поддерживать разрозненные правки. Например, Clearfy Pro от WPShop закрывает часть типовых SEO-задач и чистки сайта, но его всё равно нужно настраивать осознанно, а не включать всё подряд.
Когда лучше не трогать внутренний поиск
Есть редкие случаи, когда страницы поиска могут быть полезны для индексации: например, если сайт строится вокруг каталогов, а поисковые запросы фактически отражают устойчивые пользовательские намерения. Но это уже отдельная SEO-стратегия, и её нельзя переносить на обычный блог или корпоративный сайт.
Если вы не уверены, начните с закрытия всего внутреннего поиска через noindex,follow, затем посмотрите на поведение в Search Console и логи обхода. Это безопаснее, чем пытаться индексировать всё подряд и потом разгребать мусорные URL.