Поисковые страницы WordPress часто попадают в индекс сами по себе: ?s=, страницы с параметрами фильтрации, пустые результаты поиска, а иногда и служебные URL с сортировкой. Для SEO это почти всегда лишний шум: такие страницы не дают ценности, размазывают краулинговый бюджет и создают дубли с очень слабым контентом.
Проблема обычно не в самом поиске, а в том, что сайт отдает его как обычную HTML-страницу со статусом 200 OK. Если робот может открыть страницу, он может и добавить ее в индекс. Ниже — как найти источник, что именно закрывать и как сделать это без поломки поиска для пользователей.
Как понять, что поисковые страницы уже индексируются
Начать стоит не с правок в коде, а с диагностики. Иначе легко закрыть не то: например, убрать из индекса полезные страницы каталога или сломать поиск по сайту.
Что проверить в первую очередь
- поиск в Google по запросу
site:example.com inurl:?s=илиsite:example.com inurl:/search/; - отчеты в Google Search Console по страницам с параметрами;
- логи сервера: запросы к
?s=,?orderby=,?post_type=и другим параметрам; - шаблон темы: не выводит ли он отдельную страницу результатов поиска с уникальным URL.
Если в индексе уже есть такие URL, не ждите, что они исчезнут сами. Сначала нужно убрать причину появления, затем дать поисковику понятный сигнал, что страница не должна ранжироваться.
Какие поисковые страницы стоит закрывать, а какие — нет
Не все URL с поиском одинаково бесполезны. Иногда у сайта есть внутренний поиск по базе знаний или каталогу, и его страницы нужны пользователям. В этом случае задача не в полном запрете, а в том, чтобы не индексировать мусорные варианты.
| Вариант | Что делать | Компромисс |
|---|---|---|
| Обычный внутренний поиск WordPress | Закрыть от индексации | Пользователи продолжают искать, роботы — нет |
| Поиск с пустой выдачей | Отдавать noindex или 404 для пустых результатов | Нужно аккуратно проверить UX |
| Поиск по базе знаний с ценными страницами | Оставить только полезные URL, остальные закрыть | Нужна фильтрация параметров |
Если у вас обычный корпоративный сайт или блог, почти всегда достаточно закрыть поисковые страницы целиком. Для сложных проектов лучше ограничиться параметрами и пустыми результатами.
Пошаговое решение: закрываем поиск от индексации
Есть три рабочих подхода: через SEO-плагин, через код темы или через серверную логику. Если нужен быстрый и безопасный вариант, проще всего использовать SEO-плагин. Если нужен контроль без лишних зависимостей — лучше код.
Вариант 1. Через код: noindex для страниц поиска
Этот способ подходит, если вы не хотите полагаться на настройки плагина. Добавьте код в functions.php дочерней темы или в собственный мини-плагин.
add_action( 'wp_head', function () {
if ( is_search() ) {
echo '<meta name="robots" content="noindex,follow" />' . "\n";
}
} );Такой вариант говорит роботам не индексировать страницу, но позволяет переходить по ссылкам на ней. Для обычного поиска этого обычно достаточно.
Если хотите усилить сигнал, можно добавить заголовок X-Robots-Tag на уровне PHP:
add_action( 'template_redirect', function () {
if ( is_search() ) {
header( 'X-Robots-Tag: noindex, follow', true );
}
} );Этот способ полезен, когда тема не выводит <head> как ожидается или когда вы хотите передать директиву на уровне ответа сервера. Но не дублируйте слишком много одинаковых сигналов без необходимости: достаточно одного надежного механизма.
Вариант 2. Через robots.txt — только как дополнительная мера
Закрывать поиск только через robots.txt — плохая идея. Робот может не заходить на страницу, но URL все равно останется известным и может попасть в индекс по внешним ссылкам или из старых данных. Поэтому Disallow — это не замена noindex, а вспомогательная мера.
User-agent: *
Disallow: /?s=
Disallow: /search/Этот вариант имеет смысл, если у вас есть отдельный поисковый путь вроде /search/. Но если поиск работает через параметр ?s=, правило в robots.txt не всегда отработает так, как ожидается. Надежнее закрывать через noindex и при необходимости дополнительно ограничивать обход.
Вариант 3. Через SEO-плагин
Если на сайте уже стоит SEO-плагин, проверьте, умеет ли он задавать noindex для страниц поиска. Это проще, чем поддерживать код, если проект ведется не одним разработчиком. Удобно, когда настройка делается в интерфейсе и не зависит от темы.
Если используете Clearfy Pro, у него есть инструменты для технической чистки и управления дублями; в таких задачах это часто быстрее, чем писать отдельную логику вручную. Но даже в этом случае все равно стоит проверить итоговый HTML и заголовки ответа, а не верить только галочке в админке.
Когда лучше отдавать 404 или 410
Если поиск на сайте фактически не используется, а страницы результатов создаются только как технический мусор, можно пойти жестче: отдавать 404 Not Found или 410 Gone для пустых результатов. Это уже не про SEO-метку, а про отсутствие страницы как сущности.
Но здесь важно не переборщить. Если пользователь вводит запрос и видит ошибку вместо нормальной страницы поиска, это плохой UX. Поэтому такой подход уместен только для совсем пустых, технических или устаревших URL.
Проверка результата после внедрения
После правки не ограничивайтесь просмотром страницы в браузере. Нужно проверить именно то, что видит робот.
- Откройте страницу поиска с параметром
?s=test. - Посмотрите исходный код и убедитесь, что есть
<meta name="robots" content="noindex,follow" />. - Проверьте заголовки ответа через DevTools или
curl. - Убедитесь, что страница возвращает
200 OK, если вы не меняли логику на404/410. - Через несколько дней проверьте отчет в Google Search Console и индекс по оператору
site:.
Пример проверки заголовков через консоль:
curl -I "https://example.com/?s=test"Если вы добавляли X-Robots-Tag, в ответе должен быть виден соответствующий заголовок. Если его нет, значит код не сработал или подключен не в том месте.
Частые ошибки и как их исправить
Закрыли только robots.txt
Это самая частая ошибка. Disallow не гарантирует удаление URL из индекса. Если страница уже известна поисковику, он может оставить ее в выдаче без контента или с фрагментом текста. Исправление: добавьте noindex или отдавайте 404/410 там, где это оправдано.
Поставили noindex, но оставили canonical на саму себя
Canonical не отменяет noindex, но в комбинации с другими сигналами может запутать диагностику. Если страница не нужна в индексе, не делайте из нее «почти каноническую» сущность. Лучше оставить чистый и понятный сигнал: noindex,follow.
Сломали поиск для пользователей
Иногда разработчики ставят редирект с ?s= на главную или на архив, и поиск перестает работать. Это особенно заметно на сайтах с большим количеством контента. Проверяйте не только SEO-логику, но и сценарий пользователя: запрос должен возвращать релевантную выдачу, если поиск вообще нужен.
Закрыли полезные страницы с фильтрами вместе с поиском
Если на сайте есть отдельные страницы фильтров, их нельзя закрывать по тому же шаблону, что и внутренний поиск. У параметров фильтрации и у поиска разные задачи. Перед внедрением составьте список URL-шаблонов, которые действительно нужно закрыть.
Чек-лист перед публикацией правки
- Проверен тип URL:
?s=, отдельный путь или параметры фильтрации. - Выбрана стратегия:
noindex,X-Robots-Tag,404/410или комбинация. - Поиск не сломан для живых пользователей.
- В исходном коде есть нужная директива для роботов.
- Заголовки ответа проверены через
curl -Iили DevTools. - В
robots.txtне добавлены правила, которые мешают диагностике. - Сайт повторно проверен в Google Search Console после индексации.
Практические советы по производительности и безопасности
Если поисковые запросы часто создают тяжелую нагрузку, имеет смысл ограничить их на уровне темы или плагина: кэшировать выдачу, не показывать слишком длинные списки результатов и не индексировать пустые запросы. Это особенно важно для крупных сайтов, где внутренний поиск может генерировать много одинаковых обращений.
С точки зрения безопасности не стоит раскрывать лишнюю внутреннюю структуру сайта через поисковые URL. Если поиск возвращает служебные типы записей, проверьте, что они не уводят пользователя на закрытые разделы и не показывают лишние поля в сниппете.
Если вам нужно не только закрыть поиск, но и почистить сайт от технических дублей, служебных страниц и лишних SEO-сигналов, имеет смысл смотреть в сторону инструментов, которые умеют управлять такими настройками централизованно. Это проще сопровождать, чем держать набор разрозненных правок в теме.