Страницы внутреннего поиска в WordPress часто попадают в индекс не потому, что сайт «плохо настроен», а потому что поисковый запрос формирует отдельный URL с параметром ?s=. Для поисковиков это полноценная страница, и если на сайте много случайных запросов, мусорных запросов или пустых результатов, индекс быстро засоряется.
Самая частая ошибка — пытаться решить задачу через robots.txt. Это не убирает уже проиндексированные URL и не мешает поисковику видеть ссылки на такие страницы. Для внутреннего поиска обычно нужен другой подход: отдать корректный статус, поставить noindex там, где это уместно, и не ломать сам поиск для пользователей.
Как понять, что проблема именно в страницах поиска
Сначала проверьте, как WordPress формирует URL поиска на вашем сайте. В типовой установке это выглядит так: / ?s=запрос или /search/запрос/, если тема или плагин меняют структуру. В индексе обычно всплывают адреса с пустыми результатами, техническими запросами и дублями по разным вариантам написания.
Что смотреть в Google Search Console и логике сайта
- в отчёте по страницам есть URL с параметром
s=; - в сниппетах видны заголовки вроде «Результаты поиска для…»;
- поисковые страницы получают входящие ссылки из меню, футера или шаблонов;
- на сайте есть поиск по товарам, записям или таксономиям, но без отдельной обработки пустых результатов.
Если у вас уже есть статьи про пагинацию, архивы автора и страницы поисковых запросов, не путайте их с внутренним поиском. Здесь речь именно о страницах, которые создаются формой поиска на сайте и могут индексироваться как отдельные URL.
Что выбрать: noindex, canonical или запрет в robots.txt
Для внутреннего поиска обычно лучше не закрывать URL через robots.txt. Если робот не сможет зайти на страницу, он не увидит noindex и не всегда корректно обработает удаление из индекса. Для таких страниц чаще используют noindex, follow или вообще отдают заголовок X-Robots-Tag на уровне ответа.
| Подход | Когда уместен | Минус |
|---|---|---|
| noindex | Для страниц поиска, которые не должны ранжироваться | Нужно аккуратно внедрить, чтобы не затронуть обычные страницы |
| robots.txt | Для технических разделов, где не нужен обход роботом | Не решает проблему уже проиндексированных URL |
| canonical на главную | Редко, только если поиск полностью дублирует другой контент | Для поиска это обычно неестественно и может запутать сигналы |
Если нужен быстрый и безопасный вариант без правки темы, можно использовать SEO-плагин. Но если задача точечная и вы хотите контролировать только внутренний поиск, проще добавить условие в код темы или мини-плагин.
Пошаговое решение через код
Ниже вариант, который добавляет noindex, follow только на страницы поиска WordPress. Он не трогает обычные записи, страницы и архивы. Код можно положить в functions.php дочерней темы или в небольшой mu-plugin.
<?php
add_action( 'wp_head', function () {
if ( is_search() ) {
echo '<meta name="robots" content="noindex,follow" />' . "\n";
}
}, 1 );Если хотите сделать это надёжнее, лучше использовать фильтр wp_robots. Он работает с системным массивом директив и меньше зависит от разметки темы.
<?php
add_filter( 'wp_robots', function( array $robots ) {
if ( is_search() ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
} );В большинстве случаев этого достаточно. Но если у вас SEO-плагин уже управляет robots-мета, проверьте, не перетирает ли он директивы. Два источника noindex обычно не критичны, а вот конфликтующие правила уже создают путаницу.
Если поиск отдаёт пустые результаты
Когда запрос пустой или слишком короткий, лучше не показывать индексируемую страницу с шаблонным текстом. Можно вернуть 404 для пустого поиска, если это соответствует логике проекта. Но делать это нужно осторожно: пользовательский поиск не должен превращаться в тупик.
<?php
add_action( 'template_redirect', function () {
if ( is_search() && '' === trim( get_search_query( false ) ) ) {
global $wp_query;
$wp_query->set_404();
status_header( 404 );
nocache_headers();
include get_query_template( '404' );
exit;
}
} );Этот вариант имеет смысл только если пустой поиск у вас реально создаёт отдельную страницу, которую не нужно держать в индексе. Если же форма поиска должна просто возвращать страницу без результатов, ограничьтесь noindex.
Как сделать это через SEO-плагин
Если на сайте уже стоит SEO-плагин, иногда проще настроить правило там, чем писать код. Удобство в том, что не нужно поддерживать свой фрагмент после смены темы. Минус — не все плагины одинаково гибко работают именно с поисковыми страницами, поэтому проверка всё равно обязательна.
Если вы используете Clearfy Pro, проверьте разделы, связанные с SEO-очисткой и мета-тегами. На практике это полезно, когда нужно убрать лишние сигналы без ручного кода. Но даже в этом случае стоит убедиться, что плагин не закрывает лишнее, например страницы записей или таксономии. Подробности по продукту: Clearfy Pro.
Проверка результата после внедрения
После правки не ограничивайтесь просмотром исходника. Нужно проверить, что директива реально отдается в ответе и что поисковая страница не потеряла функциональность.
- Откройте страницу поиска с запросом, например
/?s=test. - Посмотрите исходный код страницы и убедитесь, что есть
noindex,follow. - Проверьте HTTP-ответ через DevTools или
curl. - Убедитесь, что обычные страницы сайта не получили тот же robots-мета.
- В Search Console отправьте URL на повторную проверку, если он уже был в индексе.
curl -I "https://example.com/?s=test"Если вы используете заголовок X-Robots-Tag вместо мета-тега, ищите его в ответе сервера. Это особенно полезно, если тема не выводит корректный wp_head или поиск рендерится нестандартно.
Частые ошибки и как их исправить
Закрыли поиск в robots.txt
Это самая распространённая ошибка. Робот может перестать обходить URL, но уже известные страницы не исчезнут автоматически. Для удаления из индекса нужен сигнал на самой странице или через ответ сервера.
Поставили noindex на все архивы
Иногда условие пишут слишком широко, например без проверки is_search(). В итоге под фильтр попадают архивы, страницы таксономий или даже главная. Всегда ограничивайте правило конкретным шаблоном запроса.
Сломали поиск для пользователей
Если вы отдаёте 404 на любой поисковый запрос, пользователь перестаёт получать результаты. Это допустимо только для пустого или заведомо мусорного поиска. Для обычного поиска лучше оставить страницу результатов, но закрыть её от индексации.
Дублируете правила в теме и плагине
Когда noindex добавляет и тема, и SEO-плагин, а ещё где-то есть ручной meta-тег, потом сложно понять, что именно работает. Оставьте один источник правды: либо код, либо плагин, либо серверный заголовок.
Практические советы по безопасности и производительности
Если у вас большой сайт, внутренний поиск может создавать лишнюю нагрузку. Это особенно заметно при частых запросах по коротким словам и при поиске по нескольким типам контента. В таких случаях полезно ограничить поиск только нужными post type через pre_get_posts, а не давать WordPress искать по всему подряд.
<?php
add_action( 'pre_get_posts', function( WP_Query $query ) {
if ( ! is_admin() && $query->is_main_query() && $query->is_search() ) {
$query->set( 'post_type', array( 'post', 'page' ) );
}
} );Это не замена noindex, а дополнение. Сначала вы убираете мусор из индекса, потом снижаете лишнюю нагрузку на сам поиск. Если на сайте есть кастомные типы записей, список post_type нужно подбирать под реальную структуру проекта.
Когда лучше не писать код вручную
Если тема часто обновляется, а разработчиков несколько, безопаснее вынести правило в mu-plugin или настроить его через SEO-плагин. Так вы не потеряете правку при обновлении темы и не будете искать её в functions.php через полгода.
Ручной код оправдан, когда задача точечная и вы хотите контролировать поведение без лишних зависимостей. Плагин удобнее, когда на сайте уже есть централизованная SEO-настройка и важно не распылять логику по разным местам.
Главное здесь не сам способ, а проверяемый результат: поисковая страница должна оставаться рабочей для пользователя, но не создавать лишних URL для индексации.