Страницы внутреннего поиска в WordPress часто создают мусорный индекс: запросы вида ?s= могут появляться в поиске, хотя для пользователя это не посадочные страницы и не полезный контент. Проблема особенно заметна на сайтах с большим количеством материалов, где поисковый робот легко находит десятки тысяч комбинаций запросов.
Если такие URL уже попали в индекс, одной правкой robots.txt обычно не обойтись. Нужен набор мер: запрет обхода, отдача noindex для страниц поиска и проверка, что шаблон темы не генерирует лишние ссылки и каноникалы.
Когда это действительно проблема
Сначала стоит понять, что именно индексируется. В WordPress внутренний поиск обычно выглядит так: https://site.ru/?s=seo или https://site.ru/page/2/?s=seo. Если робот видит такие страницы, он может считать их отдельными документами. На небольшом сайте это не критично, но на ресурсе с активным поиском и большим архивом появляются дубли, пустые выдачи и страницы с тонким контентом.
Признаки, что поиск уже засоряет индекс
- в Google Search Console есть URL с параметром
s; - в выдаче находятся страницы поиска по запросам, которые не должны ранжироваться;
- в логах видно частые обходы URL с
?s=; - страницы поиска получают каноникал на самих себя или на главную без логики.
Если у вас уже есть статья про дубли от пагинации, не смешивайте её с этой задачей: здесь речь именно о поисковой выдаче сайта, а не о листингах рубрик или архивов.
Диагностика: что проверить перед правками
Перед тем как закрывать поиск, посмотрите, как тема и плагины сейчас формируют мета-теги. Иногда SEO-плагин уже умеет ставить noindex на search results, а проблема возникает только из-за неправильного каноникала или открытого обхода в robots.txt.
- Откройте страницу поиска вручную, например
/?s=test. - Посмотрите исходный код и найдите
meta name="robots". - Проверьте
link rel="canonical". - Убедитесь, что в
robots.txtнет противоречивых правил. - Проверьте, не генерирует ли тема ссылки на внутренний поиск в меню, хлебных крошках или блоках рекомендаций.
Если на странице поиска стоит только Disallow в robots.txt, это не гарантирует удаление URL из индекса. Поисковик может знать адрес по внешним ссылкам или по старому обходу. Для уже известных страниц нужен именно noindex или корректная отдача 404/410 в нужных сценариях.
Пошаговое решение
1. Закройте обход страниц поиска в robots.txt
Это базовый слой, который уменьшает лишний обход. Для WordPress можно добавить правило вручную в корневой robots.txt:
User-agent: *
Disallow: /?s=
Disallow: /search/
Если у вас поиск работает только через параметр ?s=, достаточно первого правила. Но не рассчитывайте на него как на единственную меру: robots.txt запрещает обход, а не индексацию уже известных URL.
2. Добавьте noindex для страниц поиска через код
Надёжнее всего отдать noindex, follow для результатов поиска. В WordPress это можно сделать через фильтр wp_robots. Такой способ работает без привязки к конкретному SEO-плагину и не ломает шаблон.
<?php
add_filter( 'wp_robots', function( array $robots ) {
if ( is_search() ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
} );
Код можно добавить в дочернюю тему или в небольшой mu-plugin. Если у вас уже стоит SEO-плагин, проверьте, не конфликтует ли он с этим фильтром. Обычно WordPress корректно объединяет значения, но дублировать логику в нескольких местах не стоит.
3. Убедитесь, что каноникал не ведёт на саму поисковую выдачу
На страницах поиска канонический URL должен быть осмысленным. В большинстве случаев безопаснее оставить noindex и не пытаться искусственно канонизировать поиск на главную. Если SEO-плагин ставит каноникал на саму страницу поиска, это не помогает убрать её из индекса.
Если вы используете Yoast SEO или Rank Math, проверьте их настройки для архивов и search results. В ряде конфигураций они уже умеют закрывать поиск, но после кастомизации темы это поведение может быть сломано шаблоном.
4. При необходимости отключите поиск на уровне шаблона
Если внутренний поиск вам не нужен вообще, можно не только закрыть его от индексации, но и корректно обработать запросы. Например, вместо пустой выдачи показывать страницу с подсказкой или перенаправлять пользователя в каталог материалов.
<?php
add_action( 'template_redirect', function() {
if ( is_search() && ! is_admin() ) {
wp_safe_redirect( home_url( '/' ), 302 );
exit;
}
} );
Такой вариант подходит не всем. Если поиск реально используется посетителями, редирект на главную ухудшит UX. Тогда лучше оставить поиск для людей, но закрыть его от индексации.
Сравнение подходов
| Подход | Что делает | Плюсы | Минусы |
|---|---|---|---|
| robots.txt | Запрещает обход URL поиска | Просто внедрить, снижает нагрузку | Не убирает уже известные URL из индекса |
| noindex через wp_robots | Просит поисковик не индексировать страницу | Работает точечно и предсказуемо | Нужно проверить, не конфликтует ли с SEO-плагином |
| Редирект или отключение поиска | Убирает сам сценарий | Самый жёсткий способ | Может сломать пользовательский сценарий |
Как проверить, что решение сработало
После правок не ограничивайтесь просмотром HTML. Нужно проверить и ответ сервера, и поведение поисковика.
- Откройте
/?s=testи убедитесь, что в коде естьnoindex. - Проверьте, что
robots.txtотдается без ошибок и содержит нужные директивы. - В Search Console запросите проверку конкретного URL поиска.
- Посмотрите, не остались ли старые страницы поиска в отчёте об индексировании.
- Если был редирект, проверьте код ответа через
curl -Iили DevTools.
curl -I "https://site.ru/?s=test"
В ответе вы должны увидеть либо 200 OK с мета-тегом noindex, либо редирект, если вы выбрали этот сценарий. Если страница продолжает индексироваться, проверьте, не переопределяет ли тему или плагин robots-мета вручную.
Частые ошибки и как их исправить
Только Disallow в robots.txt
Это самая частая ошибка. Запрет обхода не равен удалению из индекса. Если URL уже известен поисковику, он может остаться в выдаче без содержимого или с устаревшим сниппетом. Добавляйте noindex и следите за статусом URL в Search Console.
Конфликт с SEO-плагином
Иногда SEO-плагин уже ставит свои правила, а кастомный код добавляет вторые. В итоге в коде страницы появляется несколько мета-тегов robots или некорректный canonical. Решение простое: оставьте один источник правды. Либо настройка плагина, либо код в теме, но не оба сразу без проверки.
Редирект всех поисковых запросов на главную
Это выглядит как быстрый способ убрать мусор, но на практике ломает поиск для пользователей и может ухудшить поведенческие сигналы. Если поиск нужен, лучше закрыть его от индексации, а не прятать функциональность.
Игнорирование параметров в ссылках
Если тема или виджет формирует ссылки с дополнительными параметрами, поисковик может видеть разные варианты одного и того же поиска. Проверьте шаблоны, хлебные крошки и блоки, где может появляться URL с ?s=.
Практические советы по безопасности и производительности
Внутренний поиск может быть источником лишней нагрузки, особенно если запросы не кешируются и сайт большой. Полностью кешировать поисковую выдачу обычно не стоит, но можно сократить количество обходов и убрать её из индекса. Это уменьшит число бесполезных запросов от роботов и снизит шум в аналитике.
Если вы ведёте сайт на нескольких плагинах и кастомной теме, полезно держать такие правки в отдельном mu-plugin, а не в functions.php. Тогда решение не исчезнет после смены темы и проще переживёт обновления.
Для сайтов, где SEO и техническая чистка уже ведутся системно, удобно использовать инструменты вроде Clearfy Pro, если вам нужен набор типовых правок без ручного кода. Но даже в этом случае стоит понимать, что именно закрыто: обход, индексация или оба сценария сразу.
Если после внедрения страницы поиска всё ещё появляются в индексе, не пытайтесь «дожать» это случайными правками в нескольких местах. Сначала проверьте фактический HTML, затем ответ сервера, затем отчёты Search Console. В таких задачах важна не скорость правки, а отсутствие конфликтов между темой, SEO-плагином и серверными правилами.
