Страницы внутреннего поиска в WordPress часто попадают в индекс не потому, что сайт «плохо настроен», а потому что поисковые роботы видят их как обычные URL с параметром ?s=. Если по таким адресам возвращаются результаты, пустые выдачи или бесконечные комбинации запросов, это быстро превращается в дубли и лишнюю нагрузку на сайт.
Задача здесь не в том, чтобы «спрятать всё подряд», а в том, чтобы:
- не отдавать поисковикам страницы внутреннего поиска;
- не добавлять их в XML sitemap;
- не ломать поиск для живых пользователей;
- не создавать лишние редиректы и ошибки 404 там, где они не нужны.
Когда это действительно проблема
Сначала стоит понять, что именно у вас индексируется. Типичный сценарий: в Google Search Console появляются URL вида /?s=запрос, /search/?s=... или страницы с пустым результатом поиска. Иногда это видно и в логах: робот регулярно ходит по десяткам вариантов одного и того же запроса.
Признаки, что внутренний поиск уже мешает
- в индексе есть страницы поиска с одинаковым или почти одинаковым содержимым;
- в sitemap попадают URL, которые не должны ранжироваться;
- поисковый робот тратит краулинговый бюджет на мусорные запросы;
- в отчётах по покрытию появляются «Просканировано, но не проиндексировано» для URL поиска;
- на сайте есть плагины, которые генерируют отдельные страницы поиска с ЧПУ.
Если у вас поиск используется только как внутренняя функция, а не как отдельный раздел сайта, такие страницы лучше закрыть от индексации и убрать из карты сайта.
Диагностика: что именно отдает WordPress
В WordPress стандартный поиск обычно работает через параметр s. Проверить это можно без плагинов: откройте любой запрос поиска и посмотрите URL. Если адрес выглядит как https://example.com/?s=тест, то проблема почти наверняка в том, что поисковики могут добраться до этих страниц напрямую.
Полезно проверить три вещи:
- какой HTTP-статус возвращает страница поиска;
- есть ли на ней
noindexв мета-тегах или заголовке; - попадает ли она в XML sitemap.
Если поиск уже закрыт плагином SEO, не спешите дублировать правила в теме. Сначала посмотрите, что именно делает текущая настройка, иначе легко получить конфликт: один плагин ставит noindex, другой добавляет URL в sitemap, а третий ещё и редиректит запросы.
Рабочие варианты решения
Есть три нормальных пути: через SEO-плагин, через код или комбинированно. Если нужен быстрый и безопасный способ, лучше сначала использовать возможности SEO-плагина. Если нужна точечная логика под конкретный сайт, тогда уже подключать код.
| Подход | Что делает | Плюсы | Минусы |
|---|---|---|---|
| SEO-плагин | Ставит noindex и исключает URL из карты сайта | Быстро, без кода | Меньше контроля над логикой |
| Код в теме/плагине | Отдает noindex и убирает поиск из sitemap | Точно под задачу | Нужно аккуратно тестировать |
| Комбинированно | Плагин + точечные фильтры | Гибко и надежно | Важно не задублировать правила |
Вариант 1. Закрыть поиск через код
Если у вас нет SEO-плагина или вы хотите контролировать поведение на уровне темы, можно добавить noindex для страниц поиска. Это не запрещает пользователю искать по сайту, но говорит роботам не индексировать такие страницы.
<?php
add_action( 'wp_head', function () {
if ( is_search() ) {
echo '<meta name="robots" content="noindex,follow" />' . "\n";
}
} );
Этот вариант простой, но он не решает вторую часть задачи — исключение из sitemap. Для этого нужен отдельный фильтр, если карта сайта генерируется WordPress core.
<?php
add_filter( 'wp_sitemaps_posts_query_args', function( $args, $post_type ) {
return $args;
}, 10, 2 );
add_filter( 'wp_sitemaps_taxonomies_query_args', function( $args, $taxonomy ) {
return $args;
}, 10, 2 );
Сам по себе этот код ничего не меняет для поиска, потому что стандартный sitemap WordPress не включает поисковые URL как отдельный тип. Но если у вас кастомная логика или плагин добавляет такие страницы в карту сайта, нужно искать его фильтры и отключать генерацию именно там.
Вариант 2. Если используется SEO-плагин
В популярных SEO-плагинах обычно есть настройка для страниц поиска и архивов. Ищите опцию, которая ставит noindex для результатов поиска или исключает их из sitemap. Это предпочтительнее, чем править шаблоны вручную, потому что плагин сам управляет мета-тегами и картой сайта.
Если плагин уже умеет закрывать поиск, не добавляйте второй noindex через wp_head. Два одинаковых сигнала не критичны, но в реальной поддержке потом сложно понять, откуда берётся поведение.
Вариант 3. Убрать пустые и мусорные поисковые запросы
Иногда проблема не в индексации как таковой, а в том, что сайт активно генерирует пустые страницы поиска. Например, когда форма поиска отправляет пустой запрос или бот перебирает случайные символы. В таком случае полезно не только закрыть индексирование, но и аккуратно обрабатывать пустой поиск.
<?php
add_action( 'template_redirect', function () {
if ( is_search() ) {
$query = get_search_query( false );
if ( trim( $query ) === '' ) {
wp_safe_redirect( home_url( '/' ), 302 );
exit;
}
}
} );
Такой редирект стоит использовать осторожно. Если у вас есть сценарии, где пустой поиск должен показывать страницу результатов или подсказки, редирект будет мешать. В этом случае лучше ограничиться noindex и не трогать пользовательский поток.
Пошаговая схема внедрения
- Проверьте, как сейчас работает поиск: стандартный
?s=или отдельный URL. - Посмотрите, есть ли уже
noindexв HTML-коде страницы поиска. - Проверьте sitemap: нет ли там URL поиска или похожих технических страниц.
- Выберите один источник правды: SEO-плагин или код.
- После изменений очистите кеш страницы и серверный кеш, если он есть.
- Переобойдите URL поиска в Search Console и проверьте, как робот видит страницу.
Как проверить, что решение сработало
Проверка должна быть не «на глаз», а по конкретным признакам. Откройте страницу поиска и посмотрите исходный код: в <head> должен быть мета-тег noindex,follow, если вы выбрали этот вариант. Затем проверьте XML sitemap — поисковые URL там не должны появляться.
Дополнительно полезно сделать три проверки:
- в браузере открыть поиск по сайту и убедиться, что пользовательский сценарий не сломался;
- через
curl -Iпосмотреть заголовки ответа, если вы добавлялиX-Robots-Tagна уровне сервера или плагина; - в Search Console проверить, не растёт ли число URL поиска в отчётах по индексированию.
Если у вас включён кеш, обязательно проверьте не только «чистую» страницу, но и версию из кеша. Частая ситуация: код уже добавлен, а старый HTML ещё отдаётся из кеша и робот видит прежнюю версию.
Частые ошибки и как их исправить
Закрыли поиск в robots.txt и на этом остановились
Это распространённая ошибка. Disallow в robots.txt не гарантирует удаление URL из индекса, если на них уже есть внешние или внутренние ссылки. Для надёжного результата нужен noindex или корректная обработка на уровне SEO-плагина.
Поставили редирект на главную для всех поисковых запросов
Такой подход часто ломает UX и аналитику. Пользователь ищет товар, статью или документ, а вместо результата получает главную страницу. Если нужен редирект, делайте его только для пустых запросов или явно мусорных параметров.
Добавили noindex, но URL всё равно в sitemap
Значит, у вас отдельно генерируется карта сайта, и она не учитывает правило индексации. Ищите настройку в SEO-плагине или фильтр генератора sitemap. Сам по себе мета-тег noindex не удаляет URL из карты сайта.
Забыли про кеш
После правок страницы поиска могут ещё долго отдаваться из кеша. Очистите кеш плагина, серверный кеш и, если используется CDN, его тоже. Иначе проверка даст ложный результат.
Безопасность и производительность
Если поиск на сайте активно используется, не стоит превращать его в тяжёлую точку входа. Для больших сайтов полезно следить за тем, чтобы поисковые запросы не создавали лишнюю нагрузку на базу данных. Особенно это заметно, если поиск встроен в тему и делает сложные запросы по мета-полям без индексов.
Практически это означает следующее:
- не добавляйте лишние JOIN в запрос поиска без необходимости;
- не индексируйте технические URL, которые не несут ценности пользователю;
- не держите одновременно несколько механизмов закрытия индексации, если они конфликтуют;
- проверяйте, как поиск ведёт себя под нагрузкой, если на сайт идёт бот-трафик.
Если вам нужен более широкий набор инструментов для чистки дублей, технических страниц и SEO-правил, имеет смысл смотреть в сторону решений, которые умеют управлять индексацией централизованно. Например, у Clearfy Pro есть инструменты для отключения лишних технических страниц и дублей: https://wpshop.ru/plugins/clearfy.
Что делать, если поиск должен быть доступен, но не индексироваться
Это самый частый нормальный сценарий. Пользователи должны пользоваться поиском, а поисковики — не тратить ресурсы на его индексацию. В таком случае достаточно noindex,follow, исключения из sitemap и отсутствия внутренних ссылок на поисковые URL как на отдельные посадочные страницы.
Если у вас есть кастомный шаблон страницы поиска, проверьте, не выводит ли он канонический URL на саму себя с параметром ?s=. Каноникал для поиска обычно не нужен как отдельная «SEO-страница», и неправильная настройка может только запутать робота.
После внедрения не полагайтесь только на один инструмент проверки. Посмотрите HTML, карту сайта и отчёты поисковой системы. Тогда будет понятно, что решение работает не только в шаблоне, но и на уровне индексации.