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