Страницы внутреннего поиска WordPress часто попадают в индекс как тонкие и бесполезные URL: ?s=, /search/ или их вариации после фильтров темы и плагинов. На небольшом сайте это выглядит как шум, на большом — как источник дублей, мусорных страниц и лишней нагрузки на обход. Если в поиске по сайту нет ценности для внешней выдачи, его лучше закрыть аккуратно: не ломая сам поиск для пользователей и не создавая конфликтов с каноникалами, robots.txt и кэшем.
Когда проблема действительно есть
Сначала стоит убедиться, что речь именно о страницах поиска, а не о случайных URL с параметром s. В WordPress поиск может открываться как через стандартный query string, так и через ЧПУ-формы темы. В индексе это обычно видно по адресам вида /?s=запрос, /search/запрос/ или страницам, где в title повторяется слово «Поиск» и почти нет уникального контента.
Диагностика в админке и в поисковой консоли
Проверка занимает несколько минут:
- в Google Search Console откройте отчёт по страницам и найдите URL с
?s=или/search/; - проверьте, не индексируются ли пустые результаты поиска, страницы с одним и тем же шаблоном title и коротким текстом;
- посмотрите исходный код таких страниц: есть ли
noindex,canonicalи не закрыты ли они только вrobots.txt; - сравните поведение с включённым кэшем и без него, если сайт использует плагин кэширования.
Если страницы поиска уже в индексе, одной правки robots.txt обычно недостаточно. Поисковик может продолжать держать URL в выдаче, если он уже известен и отдаёт HTML-ответ без явного запрета на индексацию.
Что лучше: robots.txt, noindex или код
Для внутреннего поиска WordPress чаще всего нужен не запрет обхода, а запрет индексации. Это разные задачи. Если закрыть URL только в robots.txt, робот может не увидеть страницу, но уже известный адрес всё равно останется в индексе без нормального сигнала на удаление. Поэтому в большинстве случаев правильнее отдавать noindex,follow на страницах поиска, а не просто запрещать их в robots.txt.
| Подход | Плюс | Минус | Когда использовать |
|---|---|---|---|
| robots.txt | Снижает обход | Не гарантирует удаление из индекса | Как дополнительная мера, не как основная |
| noindex | Даёт прямой сигнал поисковику | Нужно внедрить на уровне шаблона или SEO-плагина | Для страниц поиска, архивов, фильтров |
| Редирект | Убирает URL из обращения | Не подходит, если поиск нужен пользователям | Только если поиск на сайте вообще не используется |
Пошаговое решение через код темы
Если вы не хотите завязываться на SEO-плагин, можно добавить условный noindex в wp_head. Это рабочий вариант для стандартного поиска WordPress и большинства тем.
<?php
add_action('wp_head', function () {
if (is_search()) {
echo '<meta name="robots" content="noindex,follow" />' . "\n";
}
}, 1);
Этот вариант решает только мета-тег. Чтобы поисковик не видел дублирующие title и description, лучше дополнительно поправить заголовок страницы поиска. В современных темах это часто делается через фильтр document_title_parts.
<?php
add_filter('document_title_parts', function ($parts) {
if (is_search()) {
$parts['title'] = 'Поиск по сайту';
}
return $parts;
});
Если тема выводит собственный H1 на странице поиска, проверьте, не дублируется ли он с title. Это не критическая ошибка, но для пустых страниц поиска лучше, чтобы заголовок был нейтральным и не содержал длинный поисковый запрос пользователя.
Как сделать это через SEO-плагин
Если на сайте уже стоит SEO-плагин, логичнее использовать его настройки, а не плодить код в теме. Так проще сопровождать сайт после обновлений. Важно только проверить, что плагин действительно ставит noindex именно на поисковые страницы, а не только на отдельные записи или архивы.
В некоторых наборах для технической чистки сайта, например в Clearfy Pro, есть инструменты для управления дублями и служебными страницами. Это удобно, если у вас уже настроена централизованная SEO-гигиена и не хочется разносить правила по шаблонам. Но даже в этом случае проверка исходного кода обязательна: интерфейс плагина не заменяет фактический HTML-ответ страницы.
Что проверить после внедрения
После правки не ограничивайтесь визуальной проверкой в браузере. Нужно убедиться, что сервер отдаёт именно тот HTML, который вы ожидаете.
- Откройте страницу поиска с любым запросом и посмотрите исходный код: должен быть
<meta name="robots" content="noindex,follow" />. - Проверьте title страницы в браузере и в исходнике: он не должен дублировать длинный поисковый запрос без необходимости.
- Если используется кэш, очистите его и проверьте страницу в режиме инкогнито.
- В Search Console отправьте URL на повторную проверку после переобхода.
- Убедитесь, что внутренний поиск по сайту по-прежнему работает для пользователей.
Если у вас есть серверный кэш или CDN, иногда старый HTML продолжает отдаваться ещё некоторое время. В таком случае проверяйте не только браузер, но и ответ сервера через curl или инструменты разработчика.
curl -I "https://example.com/?s=test"
Частые ошибки и как их исправить
Закрыли поиск только в robots.txt
Это самая частая ошибка. Робот может перестать обходить новые URL, но уже известные страницы поиска не исчезнут из индекса сами по себе. Добавьте noindex в HTML-ответ.
Поставили noindex на все страницы сайта
Такое бывает, если условие написано слишком широко, например без проверки is_search(). После этого поисковик перестаёт индексировать не только поиск, но и нормальные страницы. Проверяйте условие и тестируйте на staging-копии.
Сломали поиск редиректом
Редирект на главную выглядит как быстрый способ убрать URL, но для пользователя это плохой опыт. Если поиск нужен, не редиректите его на главную. Лучше закрыть от индексации и оставить рабочим.
Не учли фильтры и параметры темы
Некоторые темы и плагины добавляют к поиску дополнительные параметры, сортировки и фильтры. Тогда у вас появляется несколько URL с одинаковым содержимым. В этом случае нужно смотреть не только на is_search(), но и на конкретные шаблоны, которые генерирует тема.
Чек-лист перед публикацией правки
- страницы поиска открываются для пользователя;
- в исходнике есть
noindex,follow; - title страницы поиска не дублирует лишний текст;
- robots.txt не конфликтует с HTML-метатегами;
- кэш очищен на сервере и в плагине;
- в Search Console нет массовых ошибок по этим URL;
- если используется SEO-плагин, его настройки не переопределяются темой.
Практические замечания по безопасности и производительности
Сам по себе внутренний поиск может нагружать базу данных, если на сайте много записей и запросы часто приходят от ботов. Закрытие от индексации не уменьшает нагрузку напрямую, но снижает вероятность того, что поисковик будет активно обходить бесполезные URL. Если поиск используется редко, имеет смысл дополнительно ограничить его кэшированием и следить за логами 404 и 200-ответов на странные запросы.
Если вы хотите централизованно убрать служебные страницы, дубли и технический шум, удобнее делать это через набор инструментов, а не вручную в каждой теме. Но даже в таком сценарии базовая проверка остаётся той же: URL должен отдавать правильный HTML, а не просто «быть закрыт где-то в настройках».
В итоге рабочая схема простая: для страниц поиска нужен явный noindex,follow, корректный title, проверка кэша и контроль индексации в Search Console. Тогда поиск остаётся полезным для посетителей и не превращается в источник дублей для поисковых систем.