Страницы внутреннего поиска WordPress часто попадают в индекс не потому, что сайт «сломался», а потому что поисковик видит их как обычные URL с параметром ?s=. В результате в выдаче появляются пустые или слабые страницы, которые не несут ценности и размывают качество индекса. Если у вас уже есть статья про дубли с параметрами и canonical, этот сценарий стоит отдельно: здесь речь именно о поиске по сайту, а не о любых URL с параметрами.
Когда это действительно проблема
Не каждый сайт обязан закрывать поиск от индексации. Но если в логах и в Search Console видно, что в индекс лезут URL вида / ?s=запрос, а в выдаче появляются страницы с заголовками вроде «Результаты поиска для…», это уже техническая задача. Обычно она проявляется так:
- в индексе есть десятки или сотни URL внутреннего поиска;
- страницы поиска получают показы, но почти не дают кликов;
- поисковик тратит краулинговый бюджет на мусорные страницы;
- на сайте есть фильтры, поиск по товарам или по записям, и результаты сильно дублируются.
Что проверить перед правками
Сначала убедитесь, что проблема именно в индексации поиска, а не в другом типе дублей. Проверьте в Google Search Console запросы по шаблону site:example.com inurl:?s=, а также откройте несколько URL поиска вручную. Если страница отдает статус 200, содержит индексируемый title и не закрыта от роботов, поисковик вполне может ее добавить в индекс.
Еще один полезный тест — посмотреть исходный код страницы поиска. Если там нет noindex, а canonical указывает на саму страницу поиска, это почти гарантированный кандидат на индексацию.
Как закрыть поиск от индексации: рабочая схема
Надежнее всего использовать не один, а несколько слоев защиты: noindex для самих страниц поиска, корректный canonical и при необходимости ограничение обхода в robots.txt. Один только robots.txt не решает задачу полностью: URL может остаться в индексе, если на него есть внешние ссылки или поисковик уже видел страницу раньше.
Вариант 1. Добавить noindex для страниц поиска
Если у вас есть доступ к теме или плагину, который управляет мета-тегами, можно добавить условный noindex,follow для поисковых страниц. В WordPress это удобно делать через фильтр wp_robots.
add_filter( 'wp_robots', function( array $robots ) : array {
if ( is_search() ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
} );Этот вариант хорош тем, что не ломает обход ссылок внутри сайта, но явно говорит поисковику не индексировать страницу результатов поиска. Для большинства проектов этого уже достаточно, если canonical и шаблон страницы не конфликтуют с мета-тегом.
Вариант 2. Исправить canonical на страницах поиска
Если тема или SEO-плагин подставляет canonical на сам URL поиска, это лучше поправить. Для страниц поиска canonical обычно либо не нужен, либо должен указывать на более общий URL, если вы сознательно оставляете страницу доступной для пользователей. Но для индексации безопаснее не полагаться только на canonical, а сочетать его с noindex.
add_filter( 'get_canonical_url', function( $canonical, $post ) {
if ( is_search() ) {
return home_url( '/' );
}
return $canonical;
}, 10, 2 );Здесь важно понимать ограничение: фильтр get_canonical_url влияет не на все случаи одинаково, а тема и SEO-плагин могут переопределять canonical своим способом. Поэтому после внедрения обязательно проверяйте исходный код страницы.
Вариант 3. Ограничить обход в robots.txt
Если на сайте много мусорных поисковых URL, можно дополнительно закрыть их от обхода в robots.txt. Это не заменяет noindex, но уменьшает нагрузку на краулинг.
User-agent: *
Disallow: /?s=
Disallow: /search/
Этот способ полезен, если у вас есть отдельный ЧПУ-путь для поиска или если тема формирует поисковые URL не только через ?s=. Но не переоценивайте robots.txt: если URL уже в индексе, одной директивы часто недостаточно для его удаления.
Что выбрать: плагин, код или оба варианта
| Подход | Когда подходит | Плюс | Минус |
|---|---|---|---|
| Плагин SEO | Если уже используется SEO-плагин с управлением robots | Быстро и без правки темы | Зависит от логики плагина и его шаблонов |
| Код в теме или mu-plugin | Если нужен точечный контроль | Предсказуемо и прозрачно | Нужно следить за обновлениями и конфликтами |
| Robots.txt | Как дополнительный слой | Снижает обход мусорных URL | Не гарантирует удаление из индекса |
На практике я бы делал так: noindex через код или SEO-плагин, затем проверял canonical, и только потом добавлял robots.txt как дополнительную меру. Если сайт уже большой, это безопаснее, чем пытаться закрыть всё одной директивой.
Пошаговая настройка без лишнего риска
- Найдите все типы поисковых URL на сайте: обычный
?s=, отдельный путь поиска, поиск по таксономиям, если он есть. - Добавьте
noindex,followдля страниц поиска. - Проверьте canonical в исходном коде и уберите самоссылку, если она мешает.
- При необходимости добавьте запрет на обход в
robots.txt. - Отправьте на переобход несколько URL поиска через Search Console.
Если вы используете Clearfy Pro, часть таких задач можно закрыть через его SEO-настройки и чистку технических дублей: Clearfy Pro. Но даже в этом случае полезно понимать, что именно меняется в коде, чтобы не получить конфликт с темой или другим SEO-плагином.
Как проверить, что решение сработало
После правок не ограничивайтесь визуальной проверкой. Нужны три контроля: исходный код, HTTP-ответ и статус в Search Console.
- Откройте страницу поиска и проверьте наличие
noindexв мета-тегах или в блоке robots. - Убедитесь, что canonical не указывает на саму страницу поиска, если это не задумано специально.
- Проверьте, что страница отдает обычный код
200, если она нужна пользователям, или другой ожидаемый статус, если вы решили ее отключать. - В Search Console посмотрите, исчезают ли URL поиска из отчета по индексированию.
Для быстрой локальной проверки удобно использовать просмотр исходного кода страницы и команду curl:
curl -I "https://example.com/?s=test"
В ответе вы не увидите мета-теги, но сможете проверить статус, редиректы и заголовки. Для мета-тегов лучше смотреть HTML-ответ целиком или использовать инструменты разработчика в браузере.
Частые ошибки и как их исправить
Закрыли только robots.txt
Это самая частая ошибка. Если URL уже в индексе, запрет на обход не убирает его мгновенно. Добавьте noindex и дождитесь переобхода.
Сломали поиск для пользователей
Иногда после правок случайно отключают саму страницу поиска или ставят редирект на главную. Это плохо: пользовательский поиск должен работать, даже если страница не индексируется. Проверяйте, что закрытие касается только индексации, а не функциональности.
Конфликт с SEO-плагином
Если у вас уже стоит плагин, который управляет robots и canonical, не дублируйте логику в нескольких местах. Иначе один код добавит noindex, а другой тут же его уберет. В таких случаях оставляйте один источник истины: либо SEO-плагин, либо код в functions.php, либо mu-plugin.
Не учли нестандартный поиск
На некоторых сайтах поиск реализован отдельным шаблоном, AJAX-запросом или кастомным endpoint. Тогда is_search() может не покрыть все случаи. Проверьте, какие URL реально генерируются, и при необходимости добавьте условия по $_GET или по конкретному пути.
Что делать с безопасностью и производительностью
Если поиск на сайте активно используется, он может нагружать базу данных. Особенно это заметно на больших сайтах с длинными постами и слабой оптимизацией запросов. Закрытие от индексации не ускоряет сам поиск, но уменьшает лишний краулинг и снижает количество бесполезных обходов.
Если хотите пойти дальше, проверьте:
- не индексируются ли внутренние служебные страницы с параметрами;
- не создает ли тема отдельные архивы поиска по таксономиям без
noindex; - не дублируется ли title у страниц поиска и обычных архивов;
- не генерирует ли плагин поиска лишние URL с одинаковым контентом.
Для сайтов, где много технических дублей и служебных страниц, полезно держать под рукой инструмент для общей чистки SEO-настроек и дублей. Но решение должно быть точечным: сначала понять, какие URL реально попадают в индекс, а потом закрывать именно их, а не весь сайт целиком.
Если свести задачу к одному правилу, оно такое: внутренний поиск должен работать для людей, но не обязан жить в индексе. В WordPress это решается комбинацией noindex, аккуратного canonical и, при необходимости, ограничений в robots.txt. Главное — после правок проверить не только код страницы, но и то, как поисковик видит URL через Search Console.