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