Внутренний поиск WordPress часто создаёт мусор в индексе: страницы вида ?s=... с пустым или слабым контентом, десятки вариантов одного и того же запроса, а иногда ещё и пагинацию результатов. Для пользователя это рабочий инструмент, для поисковика — почти всегда дубли или страницы с низкой ценностью. Если сайт уже начал собирать такие URL в индексе, лучше не ждать, пока они размоют краулинговый бюджет и отчёты в Search Console.
Ниже — рабочая схема: как понять, что проблема именно в поиске, как закрыть лишние URL без поломки формы поиска и как проверить, что изменения реально сработали.
Когда внутренний поиск становится проблемой
Сначала стоит убедиться, что речь именно о поисковых страницах, а не о другом типе дублей. Типичный признак — в индексе появляются URL с параметром ?s=, а в отчётах по страницам видны заголовки вроде «Результаты поиска для…» или пустые листинги без полезного контента. Ещё один сигнал — в логах обхода бот регулярно ходит по множеству однотипных поисковых URL, хотя они не несут самостоятельной ценности.
Что проверить в первую очередь
- Есть ли в индексе URL с
?s=и разными вариантами одного запроса. - Отдаёт ли страница поиска код
200 OKдаже при пустом результате. - Есть ли у шаблона поиска уникальный title и description или они повторяются.
- Не индексируются ли пагинированные результаты поиска, если они не нужны в выдаче.
- Не создаёт ли тема отдельные архивы поиска по типу
/search/term/и параметрические URL одновременно.
Как закрыть поиск от индексации без поломки сайта
Самый надёжный подход — не пытаться «лечить» это только robots.txt. Поисковая страница должна продолжать работать для людей, но не обязана быть индексируемой. Поэтому обычно используют noindex на самих страницах поиска и, при необходимости, каноникал на базовый URL сайта или на саму страницу поиска без лишних параметров.
Если у вас уже стоит SEO-плагин, сначала проверьте, не решает ли он задачу штатно. Например, в Clearfy Pro есть инструменты для чистки дублей и технических страниц. Это не обязательное условие, но иногда проще включить готовую настройку, чем поддерживать свой код. Если нужен именно кодовый вариант, ниже есть безопасная базовая схема.
Вариант через wp_head: noindex для страниц поиска
Добавьте код в дочернюю тему или в небольшой mu-plugin. Он не отключает поиск, а только просит поисковики не индексировать такие страницы.
<?php
add_action( 'wp_head', function () {
if ( is_search() ) {
echo '<meta name="robots" content="noindex,follow" />' . "\n";
}
} );Если на сайте уже есть SEO-плагин, который выводит robots meta, проверьте, не дублируется ли тег. Два разных robots-тега на одной странице — частая ошибка, особенно после ручных правок шаблона.
Когда нужен canonical
Для обычной страницы поиска canonical часто не обязателен, если вы ставите noindex,follow. Но если тема генерирует несколько URL для одного и того же запроса, canonical помогает сократить дубли внутри самого поиска. Например, когда один и тот же запрос открывается с лишними параметрами сортировки или фильтрации.
<?php
add_filter( 'get_canonical_url', function ( $canonical, $post ) {
if ( is_search() ) {
return home_url( '/' );
}
return $canonical;
}, 10, 2 );Этот вариант стоит применять осторожно. Если у вас поиск — важная пользовательская страница, canonical на главную может быть слишком агрессивным. В большинстве случаев достаточно noindex,follow без дополнительных трюков.
Что делать с robots.txt и почему одного запрета мало
Закрывать поиск только через robots.txt — слабое решение. Бот может перестать обходить URL, но уже известные страницы не всегда исчезают из индекса быстро, а сам URL может продолжать жить как «известный, но не просканированный». Поэтому robots.txt полезен как дополнительный барьер, но не как единственный механизм.
Если вы всё же хотите снизить лишний обход, можно закрыть параметр s в robots.txt. Но делайте это только вместе с noindex на страницах поиска, а не вместо него.
User-agent: *
Disallow: /*?s=
Disallow: /search/Этот фрагмент не универсален для всех конфигураций. Если у вас ЧПУ для поиска отличается, проверьте реальные URL в браузере и в логах сервера. Нельзя закрывать то, чего у вас нет, и нельзя рассчитывать, что один шаблон robots.txt решит все варианты.
Пошаговое решение на практике
- Проверьте, какие URL поиска уже есть в индексе и в обходе бота.
- Добавьте
noindex,followна страницы поиска. - При необходимости ограничьте обход через robots.txt.
- Уберите лишние параметры из ссылок на поиск в теме и виджетах.
- Проверьте canonical и отсутствие дублей title/description.
- После обновления отправьте на переобход только важные страницы сайта, а не весь поиск.
Если поиск генерирует пустые страницы
Иногда проблема не в индексации, а в том, что поиск отдаёт 200 OK на пустой запрос или на запрос без результатов. Это лучше исправить отдельно: пустой поиск должен вести себя предсказуемо для пользователя и не создавать мусорные URL.
<?php
add_action( 'template_redirect', function () {
if ( is_search() && '' === trim( get_search_query( false ) ) ) {
wp_safe_redirect( home_url( '/' ), 302 );
exit;
}
} );Такой редирект уместен только для пустого запроса. Не перенаправляйте все поисковые страницы на главную: это ломает пользовательский сценарий и может создать цепочки редиректов.
Как проверить, что решение сработало
Проверка должна быть не «на глаз», а по нескольким признакам. Сначала откройте страницу поиска в браузере и посмотрите исходный код: должен быть meta name="robots" content="noindex,follow", если вы выбрали этот вариант. Затем проверьте HTTP-ответ и canonical.
- Страница поиска открывается для пользователя и показывает результаты.
- В исходнике есть
noindex,follow. - Нет второго conflicting robots-тега от темы или плагина.
- В Search Console URL поиска отмечаются как исключённые или неиндексируемые, а не как дубли.
- В логах обхода уменьшается количество бесполезных запросов к поисковым URL.
Если используете инструмент проверки URL в Search Console, смотрите именно на рендер и индексируемость, а не только на статус ответа. Страница может отдавать 200, но при этом быть закрыта от индексации корректно — это нормальная ситуация для внутреннего поиска.
Частые ошибки и как их исправить
Закрыли поиск в robots.txt, но забыли про noindex
Такой вариант часто оставляет уже известные URL в индексе. Исправление простое: добавьте noindex,follow на сам шаблон поиска и оставьте robots.txt только как дополнительную меру.
Поставили noindex через плагин и через тему одновременно
В результате в коде появляются два разных robots-тега. Поисковик обычно выберет один, но вы теряете предсказуемость. Оставьте только один источник управления: либо SEO-плагин, либо код темы.
Сделали редирект всех поисковых страниц на главную
Это ломает поиск и может ухудшить поведенческие сигналы. Редирект допустим только для пустого запроса или явно мусорных URL, которые не должны существовать.
Не учли параметры сортировки и фильтрации
Если поиск сочетается с сортировкой, пагинацией или фильтрами, дубли появляются не только из-за ?s=. Проверьте, какие параметры реально участвуют в генерации URL, и не закрывайте всё подряд без анализа.
Что выбрать: плагин, код или оба варианта
| Подход | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| SEO-плагин | Нужна быстрая настройка без правки темы | Меньше кода, проще сопровождать | Зависимость от интерфейса плагина и его логики |
| Код в теме или mu-plugin | Нужен точный контроль над поведением | Прозрачно, легко проверить, не зависит от UI | Нужно следить за обновлениями и конфликтами |
| Плагин + точечный код | Есть нестандартный шаблон поиска | Гибкость и контроль | Риск дублей настроек, если не зафиксировать источник истины |
Практические замечания по безопасности и производительности
Не стоит пытаться решать проблему поисковых дублей тяжёлыми плагинами, которые переписывают весь robots-слой сайта. Для одной задачи лучше точечная настройка: меньше кода, меньше конфликтов, проще откатить. Если у вас высоконагруженный сайт, проверьте ещё и серверный кеш: поисковые страницы обычно не должны попадать в публичный кеш так же, как обычные посты.
Если поиск активно используется, не отключайте его целиком ради SEO. Правильная цель — оставить его рабочим для людей и убрать из индекса то, что не несёт самостоятельной ценности. Это как раз тот случай, где аккуратная техническая настройка лучше, чем грубый запрет.