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