Как закрыть от индексации страницы поисковой выдачи WordPress

Автор: Екатерина Крылова | Опубликовано: 31.08.2026

Внутренний поиск WordPress часто создает страницы, которые не дают ценности поисковым системам: результаты с пустым запросом, дубли по разным параметрам, страницы с тонким контентом. Если такие URL попадают в индекс, они размывают структуру сайта и могут засорять отчеты в Search Console.

Ниже разберем, как закрыть от индексации именно страницы поиска, не ломая сам поиск для пользователей. Подход подойдет для обычных тем и для проектов, где поиск используется как навигационный инструмент, а не как посадочная страница.

Когда это действительно проблема

Сначала стоит убедиться, что речь именно о страницах поиска, а не о полезных архивных страницах. В WordPress поиск обычно выглядит так: ?s=запрос. Иногда к нему добавляются дополнительные параметры от темы или плагинов, и тогда появляются лишние варианты одного и того же URL.

Признаки, что страницы поиска лучше закрыть

в индексе есть URL с ?s= и пустыми или бессмысленными запросами;
в отчетах Search Console появляются страницы с низким качеством и коротким временем просмотра;
поисковые роботы тратят краулинговый бюджет на внутренний поиск вместо важных страниц;
поисковая выдача показывает внутренние результаты по брендовым или служебным запросам, которые не нужны пользователю.

Что проверить перед правкой

Откройте несколько URL поиска вручную и посмотрите, как они отдаются сервером и что попадает в <head>. Важно понять, есть ли уже noindex от SEO-плагина, не конфликтует ли он с каноникалами и не закрыт ли поиск через robots.txt, что может мешать роботам увидеть директиву noindex.

https://example.com/?s=wordpress

Если страница открывается нормально для пользователя, но ее не нужно индексировать, лучший вариант — отдать noindex, follow и не блокировать сам URL в robots.txt.

Какой способ выбрать: код, SEO-плагин или robots.txt

Для внутренних страниц поиска есть три рабочих подхода. У каждого свои плюсы и компромиссы.

Способ	Когда подходит	Минус
Код в теме или мини-плагине	Нужен точный контроль без лишних зависимостей	Нужно следить за обновлениями темы
SEO-плагин	Уже используется Yoast SEO, Rank Math или аналог	Поведение зависит от настроек плагина
robots.txt	Нужно быстро ограничить обход	Это не замена noindex и может оставить URL в индексе

Если задача именно убрать страницы поиска из индекса, robots.txt сам по себе не решает проблему. Он может запретить обход, но не гарантирует удаление уже известных URL. Поэтому основной упор лучше делать на noindex.

Пошаговое решение через код

Самый предсказуемый способ — добавить директиву noindex, follow только для страниц поиска. Это можно сделать в дочерней теме или в небольшом mu-plugin, чтобы не потерять правку при обновлении темы.

<?php
add_action('wp_head', function () {
    if (is_search()) {
        echo '<meta name="robots" content="noindex,follow" />' . "\n";
    }
}, 1);

Этот вариант работает на уровне HTML и не зависит от конкретного SEO-плагина. Но если у вас уже подключен плагин, который тоже выводит robots meta, проверьте, чтобы не получилось две разные директивы в одном документе.

Если нужно убрать еще и пустой поиск

Пустой запрос ?s= лучше не индексировать и не использовать как полноценную страницу. Можно дополнительно отправлять пользователя на главную или показывать обычную страницу без индексации. Но редирект нужен только если это соответствует логике сайта; на некоторых проектах удобнее оставить страницу с сообщением и noindex.

<?php
add_action('template_redirect', function () {
    if (is_search() && trim((string) get_query_var('s')) === '') {
        wp_safe_redirect(home_url('/'), 302);
        exit;
    }
});

Здесь важно не злоупотреблять редиректами. Если пользователь действительно использует поиск, резкий уход на главную может ухудшить UX. Для многих сайтов достаточно просто закрыть пустой поиск от индексации и показать понятное сообщение.

Если используете SEO-плагин

У большинства SEO-плагинов есть настройка для noindex на страницах поиска или для архивов. Это удобнее, если вы уже ведете мета-данные через плагин и не хотите дублировать логику в коде.

Проверяйте не только сам флажок, но и итоговый HTML. Иногда плагин ставит canonical на главную или на саму страницу поиска, а это не всегда то, что нужно. Для внутренних поисковых URL обычно достаточно noindex без попытки сделать их каноническими.

Когда плагин лучше кода

на сайте уже есть единая SEO-логика в одном плагине;
редактор или контент-менеджер должен сам управлять индексированием;
нужно быстро применить правило без правки файлов темы.

Проверка результата после внедрения

После внесения изменений не ограничивайтесь визуальной проверкой страницы. Нужно убедиться, что директива реально отдается в HTML и не перезаписывается другим слоем.

Откройте URL поиска в браузере.
Посмотрите исходный код страницы и найдите meta name="robots".
Убедитесь, что там есть noindex,follow.
Проверьте, что страница по-прежнему открывается для пользователя и поиск работает.
Через Search Console отправьте URL на повторную проверку, если он уже был в индексе.

Если у вас есть доступ к командной строке, можно быстро проверить заголовок и HTML через curl:

curl -s https://example.com/?s=wordpress | grep -i robots

Для более точной проверки посмотрите, не появляется ли на странице второй meta robots от темы или SEO-плагина. Две конфликтующие директивы — частая причина, почему поисковик интерпретирует страницу не так, как ожидалось.

Частые ошибки и как их исправить

Закрыли поиск в robots.txt вместо noindex

Это распространенная ошибка. Если URL уже известен поисковику, запрет в robots.txt не гарантирует его удаление из индекса. Сначала нужен noindex, а robots.txt можно использовать только как дополнительное ограничение обхода, если оно действительно нужно.

Поставили noindex на все страницы сайта

Иногда правку добавляют слишком широко, например через условие, которое срабатывает не только на поиск. Проверяйте, что используется именно is_search(), а не общий шаблон для архивов или страниц с параметрами.

Сломали поиск редиректом

Если редиректить все URL с параметром s на главную, пользователь перестает понимать, что произошло. Лучше редиректить только пустой запрос или вообще не трогать поведение поиска, если задача только в индексации.

Не учли canonical

Некоторые темы и плагины автоматически выводят canonical на страницы поиска. Это не всегда ошибка, но если canonical указывает на нерелевантный URL, поисковик может игнорировать вашу логику noindex. После правки проверьте исходный код и убедитесь, что canonical не конфликтует с задачей.

Практические советы по безопасности и производительности

Если вы добавляете код вручную, не правьте родительскую тему. Используйте дочернюю тему или небольшой mu-plugin, чтобы обновления не затерли изменения. Для проектов с несколькими редакторами это особенно важно: одна потерянная правка может вернуть мусорные URL в индекс.

Еще один полезный момент: не делайте тяжелую обработку в template_redirect для каждой страницы поиска. Условие должно быть коротким и предсказуемым. Если логика усложняется, выносите ее в отдельную функцию и тестируйте на staging-копии сайта.

Если на сайте уже накопились индексируемые URL поиска, после внедрения noindex не ждите мгновенного эффекта. Поисковику нужно время, чтобы переобойти страницы и снять их из выдачи. В этот период полезно отслеживать статус URL в Search Console и не менять правило туда-сюда.

Что должно получиться в итоге

После настройки внутренние страницы поиска должны оставаться доступными пользователю, но не претендовать на место в индексе. Это убирает лишние URL из отчётов, уменьшает шум в поисковой аналитике и делает структуру сайта чище без потери функциональности.

Если нужен более широкий технический аудит дублей и служебных страниц, похожие задачи обычно решают комплексно: закрывают архивы, чистят параметры, настраивают canonical и проверяют карту сайта. Но для внутреннего поиска чаще всего достаточно точечной правки, описанной выше.