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

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

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

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

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

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

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

Диагностика: какие URL уже попали в индекс

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

Проверить можно так:

• поиск в Google по site:example.com inurl:?s=;
• отчет «Страницы» в Google Search Console;
• логика шаблона темы: есть ли отдельный search.php и какой заголовок он выводит;
• просмотр исходного кода страницы поиска — есть ли noindex или canonical на главную.

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

Что выбрать: плагин, код или оба варианта

Для этой задачи есть три нормальных подхода. Выбор зависит от того, насколько у вас кастомная тема и кто будет поддерживать сайт дальше.

Если у вас уже есть SEO-плагин, сначала проверьте его настройки. Например, в Clearfy Pro есть инструменты для технической чистки сайта и управления дублями. Но если нужен только поиск, достаточно и небольшого кода.

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

Самый надежный вариант — добавить noindex, follow для страниц поиска. Это говорит роботам не индексировать саму страницу, но не запрещает переходить по ссылкам на ней. Для WordPress это обычно правильнее, чем жесткий disallow в robots.txt.

1. Добавьте мета-robots для поиска

Вставьте код в functions.php дочерней темы или в небольшой mu-plugin. Так правило не потеряется при обновлении темы.

<?php
add_filter( 'wp_robots', function( array $robots ) {
    if ( is_search() ) {
        $robots['noindex'] = true;
        $robots['follow']   = true;
    }

    return $robots;
} );

Этот способ использует штатный фильтр WordPress и не зависит от конкретного SEO-плагина. Если плагин тоже управляет robots-мета, проверьте, не конфликтуют ли правила.

2. Уберите поисковые страницы из sitemap, если они туда попали

В стандартном WordPress поисковые страницы обычно не попадают в XML-карту сайта. Но некоторые темы и плагины могут добавлять лишние URL через свои генераторы sitemap. Если у вас кастомный sitemap, убедитесь, что там нет URL поиска и других служебных страниц.

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

3. При необходимости ограничьте доступ через robots.txt, но осторожно

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

Если вам нужно лишь снизить нагрузку на краулинг, можно добавить правило для параметра поиска, но только как дополнительную меру:

User-agent: *
Disallow: /*?s=

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

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

Во многих случаях проще закрыть поиск через настройки SEO-плагина, если он умеет управлять мета-тегами и архивами. Смотрите не на маркетинговые обещания, а на конкретную возможность задать noindex для search-страниц и проверить итоговый HTML.

Что важно проверить в настройках:

• есть ли отдельное правило для страниц поиска;
• не добавляет ли плагин canonical на главную вместо canonical на саму страницу поиска;
• не конфликтует ли он с темой, если тема уже выводит свои meta robots;
• не закрывает ли он случайно обычные страницы сайта.

Если плагин умеет только общие настройки, а поиск все равно индексируется, лучше добавить точечный код, чем пытаться лечить проблему косвенно.

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

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

1. Откройте страницу поиска в браузере, например https://example.com/?s=test.
2. Посмотрите исходный код страницы и найдите noindex.
3. Проверьте, что страница отдает обычный код ответа 200, а не редирект на главную.
4. В Google Search Console отправьте URL на повторную проверку, если он уже был в индексе.
5. Через несколько дней проверьте, исчез ли URL из отчета по индексированию.

Если у вас включен кэш, очистите его после правок. Иначе можно смотреть на старую версию страницы и ошибочно думать, что правило не работает.

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

Ставят только Disallow в robots.txt

Это самая частая ошибка. Запрет обхода не равен запрету индексации. Если URL уже известен поисковику, он может остаться в выдаче без сниппета. Для поисковых страниц нужен именно noindex.

Делают редирект всех поисковых страниц на главную

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

Забывают про кэш и CDN

Если страница поиска уже закэширована, вы можете не увидеть изменения сразу. Очистите серверный кэш, кэш плагина и CDN, если он есть. Иначе проверка будет ложной.

Конфликтуют два источника meta robots

Например, тема выводит свои мета-теги, а SEO-плагин — свои. В итоге в HTML может оказаться два разных правила, и поисковик выберет не то, что вы ожидали. Оставьте один источник управления robots-метками.

Что делать, если поисковые страницы нужны внутри сайта

Иногда внутренний поиск используют как рабочий инструмент для пользователей, и закрывать его полностью не хочется. В таком случае можно оставить функциональность, но убрать индексирование. Это нормальный компромисс: посетитель ищет, робот не тащит в индекс служебные URL.

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

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

Служебные страницы поиска сами по себе неопасны, но они могут создавать лишнюю нагрузку, если на сайте много запросов от ботов. Поэтому полезно:

• не генерировать тяжелые шаблоны для search.php без необходимости;
• проверить, не делает ли тема лишние запросы к базе на странице поиска;
• не выводить на search-странице тяжелые блоки, которые не нужны для результата;
• держать актуальный кэш и не забывать очищать его после правок.

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

Короткий чек-лист перед публикацией правки

• Страницы поиска получают noindex, follow.
• В HTML нет второго конфликтующего meta robots.
• Поисковые URL не попали в sitemap.
• Кэш и CDN очищены.
• В Search Console отправлен URL на повторную проверку.
• Поиск на сайте продолжает работать как раньше.

Если после правки страницы поиска все еще индексируются, обычно проблема не в самом noindex, а в том, что робот видит старую версию страницы, другой canonical или дублирующий шаблон в теме. В таком случае проще идти от исходного HTML и ответа сервера, чем гадать по симптомам.