Страницы внутреннего поиска WordPress часто попадают в индекс не потому, что они полезны, а потому что их легко обнаружить: запросы вида ?s= создают множество URL с тонким или пустым контентом. Для поисковых систем это типичный источник дублей и мусорных страниц. Если сайт уже растёт, такие URL начинают мешать краулингу и размывают качество индекса.
Задача здесь не в том, чтобы «сломать поиск», а в том, чтобы оставить его рабочим для пользователей и при этом не отдавать роботам страницы, которые не должны ранжироваться. Ниже — рабочие способы для WordPress: от простой настройки до точечного кода, если нужен полный контроль.
Когда внутренний поиск становится проблемой
Проверять нужно не по ощущениям, а по фактам. Откройте отчёт по страницам в Google Search Console или выгрузку из краулера и посмотрите, есть ли в индексе URL с параметром ?s=, /search/ или похожими вариантами. На небольшом сайте это может быть незаметно, но на контентном проекте такие страницы быстро плодятся из-за разных запросов пользователей.
Типичные признаки
- в индексе есть URL поиска с пустой выдачей или очень коротким списком результатов;
- в логах краулинга много обращений к URL с параметром
s; - в Search Console растёт число страниц, помеченных как «Просканировано, но не проиндексировано»;
- поиск генерирует заголовки и сниппеты, которые не отражают реальную ценность страницы.
Если у вас стоит SEO-плагин, он может уже закрывать такие страницы частично, но лучше проверить, что именно происходит на вашем сайте. Важно не путать индексацию с доступностью: страница поиска может быть доступна пользователю, но не должна попадать в индекс.
Какой способ выбрать: плагин, код или robots.txt
У каждого подхода есть свои ограничения. robots.txt не удаляет уже проиндексированные URL и не гарантирует, что робот не увидит их через внешние ссылки. Метатег noindex работает точнее, но его нужно отдать именно на страницах поиска. Код даёт максимум контроля, если вы не хотите зависеть от настроек плагина.
| Подход | Когда подходит | Минус |
|---|---|---|
| SEO-плагин | Нужна быстрая настройка без кода | Не всегда удобно для нестандартных шаблонов |
| Код в теме или мини-плагине | Нужен точный контроль над noindex и заголовками | Нужно аккуратно тестировать после обновлений |
robots.txt | Дополнительное ограничение для краулеров | Не решает проблему индексации сам по себе |
Если нужен практичный и быстрый вариант без ручной поддержки кода, удобно использовать SEO-инструменты вроде Clearfy Pro, но только как часть общей настройки: закрытие в индексе, корректные мета-роботы и проверка шаблонов поиска должны совпадать. Ссылка на продукт: Clearfy Pro.
Пошаговое решение без плагина
Если вы хотите закрыть именно страницы поиска WordPress, а не весь сайт, проще всего добавить noindex,follow для поисковых страниц и при необходимости убрать их из sitemap. Ниже пример для functions.php дочерней темы или собственного мини-плагина.
<?php
add_action( 'wp_head', function () {
if ( is_search() ) {
echo '<meta name="robots" content="noindex,follow" />' . "\n";
}
} );
add_filter( 'wp_robots', function( array $robots ) {
if ( is_search() ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
} );Здесь есть два уровня защиты. Первый — вывод метатега в <head>. Второй — фильтр wp_robots, который используется WordPress для формирования директив роботов. В современных версиях WordPress это более надёжный путь, чем полагаться только на ручной вывод HTML.
Если у вас кастомный шаблон поиска, проверьте, не переопределяет ли тема мета-robots вручную. Иногда тема выводит собственный <meta name="robots">, и тогда ваш код будет конфликтовать с ним.
Дополнительно: убрать поиск из sitemap
Если ваш SEO-плагин или кастомный генератор sitemap добавляет туда поисковые URL, их лучше исключить. Для стандартного WordPress это обычно не требуется, но в проектах с кастомной логикой такое встречается. Проверяйте sitemap вручную после изменений.
Как закрыть поиск через robots.txt, если нужен дополнительный барьер
robots.txt полезен как дополнительный сигнал для краулеров, но не как единственная защита. Его можно использовать вместе с noindex, особенно если на сайте много параметрических URL.
User-agent: *
Disallow: /*?s=
Disallow: /search/Этот вариант не универсален для всех конфигураций, потому что формат URL поиска зависит от темы и структуры сайта. Если поиск у вас работает через красивый URL, сначала посмотрите, какой именно адрес генерируется при поисковом запросе. Иначе можно закрыть не то, что нужно.
Проверка результата после внедрения
После настройки не ограничивайтесь открытием страницы в браузере. Нужно проверить, что робот видит именно ту версию, которую вы ожидаете.
- Откройте страницу поиска и посмотрите исходный код: должен быть
noindex,follow. - Проверьте заголовки ответа через DevTools или
curl, если у вас настроены HTTP-заголовки для роботов. - В Search Console отправьте URL на повторную проверку после переобхода.
- Убедитесь, что обычный поиск для пользователя по-прежнему работает и выдаёт результаты.
Для быстрой проверки можно использовать команду:
curl -I "https://example.com/?s=test"Если вы видите редирект на другой URL, проверьте, не переписывает ли его плагин кеширования, SEO-модуль или тема. Иногда проблема не в индексации, а в том, что поисковая форма ведёт на нестандартный адрес, который потом индексируется отдельно.
Частые ошибки и как их исправить
Закрыли поиск только в robots.txt
Это частая ошибка. Если URL уже в индексе, запрет в robots.txt не удалит его сразу. Нужен noindex или удаление через инструменты поисковой системы, если страница уже закрепилась в выдаче.
Поставили noindex, но забыли про шаблон темы
Некоторые темы выводят собственный <meta name="robots"> и перетирают настройки плагина. В таком случае нужно найти источник тега в header.php или в подключаемом модуле и убрать дублирование.
Сломали внутренний поиск редиректом
Не стоит редиректить все поисковые запросы на главную. Это ухудшает UX и создаёт ложные сигналы для поисковиков. Пользователь должен видеть результаты поиска, а не пустую заглушку.
Закрыли слишком много страниц
Иногда вместе с поиском случайно закрывают архивы, теги или страницы пагинации. Проверяйте условие is_search(), а не общие шаблоны архивов. Это особенно важно на сайтах с большим количеством контента.
Что делать для безопасности и производительности
Если внутренний поиск активно используется, он может нагружать базу данных. Это уже не вопрос индексации, а вопрос производительности. На больших сайтах имеет смысл ограничивать слишком короткие запросы, логировать частые пустые выдачи и следить за кешированием страниц результатов, если оно вообще уместно в вашей архитектуре.
Не кешируйте поисковые результаты без понимания последствий: пользователь должен получать актуальную выдачу, а не устаревший список. Лучше оптимизировать сам поиск и убрать его мусорные URL из индекса, чем маскировать проблему кешем.
Короткий чек-лист перед публикацией изменений
- Проверить, какой URL генерирует поиск на сайте.
- Добавить
noindex,followдляis_search(). - Убедиться, что нет второго мета-robots из темы или плагина.
- Проверить sitemap и исключить поисковые URL, если они туда попали.
- Протестировать результат в браузере и через Search Console.
- Не использовать редирект на главную вместо нормальной страницы результатов.
Если у вас уже стоит SEO-плагин и вы не хотите поддерживать код вручную, настройку можно упростить через один инструмент, но всё равно стоит проверить итоговый HTML и индексацию. В таких задачах важен не сам способ, а совпадение трёх вещей: доступность для пользователя, корректная директива для робота и отсутствие дублей в индексе.