Страницы внутреннего поиска в WordPress часто создают лишние URL: один и тот же запрос может открываться с разными параметрами, а пустые или мусорные запросы попадают в индекс. Проблема не в самом поиске, а в том, что поисковые страницы почти всегда слабо отличаются по содержимому и быстро превращаются в дубли.
Если у вас уже настроены canonical и XML-карты сайта, это не решает вопрос полностью: поисковый URL всё равно может быть доступен роботам, а иногда ещё и попадать в логи, аналитику и отчёты Search Console. Ниже — рабочая схема, которая не ломает поиск для пользователей и не требует отключать его целиком.
Когда поиск в WordPress становится проблемой для индексации
Сначала стоит понять, что именно у вас индексируется. В WordPress внутренний поиск обычно живёт на URL вида /?s=запрос или на ЧПУ-варианте, если его меняет тема или плагин. Дубли появляются в трёх типичных случаях:
- один и тот же запрос доступен с разными параметрами;
- поиск отдаёт пустую страницу, но с индексируемым URL;
- поисковые страницы содержат слишком мало уникального контента и конкурируют с основными разделами сайта.
Если в индексе уже есть такие страницы, они обычно не дают трафик, но забирают краулинговый бюджет и создают шум в отчётах. Для небольшого сайта это не критично, для каталога или контентного проекта — уже заметно.
Диагностика: что проверить перед правками
Не начинайте с массового noindex для всего подряд. Сначала посмотрите, как поиск ведёт себя сейчас:
- откройте несколько запросов вручную и проверьте исходный код страницы;
- посмотрите, есть ли у страницы поиска
meta robotsи canonical; - проверьте, не создаёт ли тема отдельный шаблон для результатов поиска;
- в Search Console найдите URL с параметром
s=и посмотрите, как они индексируются; - проверьте, не попадают ли поисковые URL в sitemap через сторонний плагин.
Если поиск отдаёт пустую выдачу с кодом 200 и без ограничений для индексации, это уже достаточная причина для правки.
Что делать: три рабочих подхода
Универсального варианта нет. Выбор зависит от того, нужен ли вам поиск как отдельная посадочная страница или только как интерфейс для посетителей.
| Подход | Когда подходит | Минус |
|---|---|---|
| noindex, follow для страниц поиска | Поиск нужен пользователям, но не должен индексироваться | Нужно следить, чтобы правило не сломалось после обновления темы |
| canonical на главную или релевантный раздел | Поисковая страница почти всегда пустая или нерелевантная | Можно потерять полезный сигнал, если поиск реально даёт уникальные результаты |
| закрыть только пустые и мусорные запросы | Есть нормальные поисковые страницы, но часть запросов мусорная | Требует небольшой доработки кода |
На практике чаще всего достаточно первого варианта: оставить поиск доступным, но запретить его индексацию. Это самый безопасный сценарий, если вы не строите сайт вокруг поисковой выдачи.
Шаг 1. Добавить noindex для страниц поиска
Если тема или SEO-плагин не делают это корректно, проще добавить правило вручную. Для WordPress это можно сделать через wp_head, не трогая шаблоны темы.
<?php
add_action( 'wp_head', function () {
if ( is_search() ) {
echo '<meta name="robots" content="noindex,follow" />' . "\n";
}
}, 1 );Этот код лучше добавить в дочернюю тему или в небольшой mu-plugin, а не в основной файл темы. Так он не потеряется после обновления.
Если у вас уже стоит SEO-плагин, сначала проверьте его настройки. Дублирующий noindex сам по себе не страшен, но лишний код в <head> усложняет диагностику. В идеале должен быть один источник правды.
Когда лучше использовать плагин, а не код
Если на сайте много технических исключений и вы не хотите держать их в теме, удобнее использовать плагин для SEO-правил. Например, в Clearfy Pro есть инструменты для чистки технических дублей и управления индексированием служебных страниц. Это уместно, когда нужно централизованно закрывать несколько типов URL, а не только поиск.
Но даже в этом случае полезно знать, как выглядит ручная проверка: плагин может быть отключён, а код в теме — нет.
Шаг 2. Отсечь пустые запросы и мусорные параметры
Если сайт получает много запросов вида ?s= или поисковых URL с лишними параметрами, можно не отдавать им полноценную страницу. Это особенно полезно, когда поиск используется ботами или когда пользователи часто отправляют пустую форму.
<?php
add_action( 'template_redirect', function () {
if ( is_search() ) {
$query = trim( (string) get_search_query() );
if ( $query === '' ) {
wp_safe_redirect( home_url( '/' ), 302 );
exit;
}
}
} );Здесь важно не переборщить. Не стоит редиректить все поисковые запросы на главную — это уже ломает пользовательский сценарий. Редирект нужен только для пустого поиска, а не для нормальных запросов.
Если нужен более строгий контроль
Иногда имеет смысл ограничить длину запроса или отсеивать заведомо мусорные символы. Но это уже зависит от языка сайта и поведения аудитории. Жёсткая фильтрация без анализа реальных запросов может удалить нормальные поисковые фразы.
Для начала достаточно закрыть пустые запросы и оставить всё остальное под noindex,follow.
Шаг 3. Проверить canonical и шаблон результатов поиска
На странице поиска canonical должен вести либо на саму поисковую страницу, либо на релевантный URL, если вы сознательно сводите такие страницы в один канонический адрес. Ошибка возникает, когда тема ставит canonical на главную без логики или вообще не выводит его на поисковых страницах.
Проверка простая: откройте исходный код страницы поиска и найдите строку с rel="canonical". Если canonical отсутствует, это не всегда критично, но тогда особенно важно, чтобы noindex был на месте.
Ещё один частый случай — тема выводит на странице поиска слишком много одинаковых блоков: похожие записи, популярные статьи, последние записи, хлебные крошки и повтор заголовка. В результате поисковая страница становится почти копией других архивов. Если это ваш случай, лучше упростить шаблон поиска, а не только закрывать индексацию.
Как проверить, что решение сработало
После внедрения не ограничивайтесь просмотром страницы в браузере. Проверьте несколько уровней:
- в исходном коде есть
meta name="robots" content="noindex,follow"; - поисковый URL отдаёт код ответа 200 или 302 в зависимости от логики, которую вы задали;
- пустой поисковый запрос редиректится или обрабатывается отдельно;
- в Search Console новые URL с
?s=не начинают массово индексироваться; - в логах сервера не растёт число бесполезных запросов к поиску от ботов.
Если у вас есть доступ к консоли, можно быстро проверить заголовки ответа:
curl -I "https://example.com/?s=test"В ответе важно увидеть ожидаемый код и отсутствие неожиданных редирект-цепочек. Если вместо этого появляется несколько переходов подряд, значит где-то конфликтуют правила темы, плагина или .htaccess.
Частые ошибки и как их исправить
Закрыли поиск в robots.txt
Это распространённая ошибка. Если запретить обход поисковых URL в robots.txt, робот может не увидеть noindex на самой странице и продолжит учитывать URL как отдельный объект. Для управления индексацией лучше использовать мета-тег или заголовок X-Robots-Tag, а не только robots.txt.
Поставили noindex, но оставили мусорные ссылки внутри сайта
Если поиск активно используется в меню, виджетах и блоках, поисковые URL всё равно будут постоянно генерироваться. Это не критично, но создаёт лишний шум. Проверьте, не вставляет ли тема ссылки на пустой поиск или на запросы по умолчанию.
Сделали редирект всех поисковых страниц
Так ломается внутренний сценарий поиска. Пользователь вводит запрос и попадает на главную, а не на выдачу. Если нужен редирект, ограничьте его только пустыми запросами.
Дублирующийся noindex из плагина и темы
Иногда в коде страницы одновременно присутствуют несколько правил robots. Это не всегда ошибка, но диагностику усложняет. Оставьте один источник: либо SEO-плагин, либо код в теме/му-плагине.
Безопасность и производительность: что учесть
Любая логика, которая работает с параметром s, должна быть максимально простой. Не делайте тяжёлые запросы к базе на каждом поисковом хите и не запускайте сложную фильтрацию без необходимости. Поиск и так может быть дорогим по ресурсам, особенно на сайтах с большим количеством записей.
Если у вас высокий трафик и много мусорных поисковых запросов, полезно смотреть не только на индексацию, но и на нагрузку. Иногда проблема не в SEO, а в том, что боты массово дергают поиск и создают лишние обращения к базе. В таком случае помогает комбинация: noindex, ограничение пустых запросов и базовая защита на уровне сервера или WAF.
Для сайтов, где техническую чистку удобнее держать в одном месте, можно посмотреть в сторону Clearfy Pro: он закрывает часть типовых SEO- и технических задач без ручного разбрасывания кода по теме. Но если у вас уже есть понятная архитектура, mu-plugin часто оказывается проще и надёжнее.
Мини-чек-лист перед публикацией правок
- поисковые страницы не попадают в индекс;
- пустой запрос не создаёт отдельную мусорную страницу;
- canonical не указывает на случайный URL;
- поиск по сайту продолжает работать для пользователя;
- в коде нет дублирующих SEO-правил от темы и плагина;
- после обновления темы правило не исчезнет.
Если после правок в индексе всё ещё остаются старые URL поиска, это нормально: поисковики не удаляют их мгновенно. Важно, чтобы новые страницы уже отдавали корректные сигналы, а старые постепенно выпадали из обхода и индекса.
В таких задачах выигрывает не самый «умный» способ, а самый предсказуемый. Для WordPress это обычно означает: минимальный код, понятные условия, одна точка управления и обязательная проверка ответа страницы после внедрения.