Страницы внутреннего поиска WordPress часто попадают в индекс как тонкие и дублирующиеся URL. Проблема обычно не в самом поиске, а в том, что запросы вида ?s= создают много бесполезных страниц, которые поисковик может обходить и хранить в индексе. Если на сайте есть фильтры, автоподсказки или похожие запросы, мусорных URL становится еще больше.
Задача здесь не просто «запретить всё подряд», а аккуратно убрать из индекса результаты поиска, не сломав поиск для пользователей и не создав конфликтов с canonical, robots и кэшированием.
Когда это действительно нужно
Закрывать внутренний поиск имеет смысл, если в индексе уже есть URL с параметром ?s= или если в отчетах Search Console появляются страницы, которые не должны ранжироваться. Для большинства обычных сайтов результаты поиска не несут самостоятельной ценности: это не посадочные страницы, а динамическая выдача по запросу пользователя.
Типичный симптом — в индексе оказываются URL вроде / ?s=wordpress, /search/term/ или страницы с параметрами сортировки и фильтрации, если тема или плагин поиска их добавляет. Вторая частая ситуация — поисковик индексирует пустые или почти пустые результаты, потому что запросы генерируются автоматически и ведут на страницы с минимальным контентом.
Диагностика проблемы
Перед правками проверьте, какие именно URL уже попали в индекс и как они отдаются сервером. Это важно: иногда проблема не в WordPress, а в теме, которая выводит поиск по нестандартному шаблону и забывает про мета-теги.
- Откройте в поиске Google запрос
site:example.com inurl:?s=илиsite:example.com inurl:search. - Проверьте отчет «Страницы» в Google Search Console на наличие URL поиска.
- Посмотрите исходный код страницы поиска: есть ли
noindex,canonicalи не конфликтуют ли они между собой. - Проверьте, не кэшируется ли страница поиска как обычная статическая страница.
Если у вас установлен плагин SEO, сначала посмотрите его настройки. Многие плагины уже умеют ставить noindex на архивы поиска, но это не всегда включено по умолчанию.
Рабочая схема: noindex + canonical + ограничение обхода
Для внутреннего поиска лучше использовать не один инструмент, а связку. noindex говорит поисковику не включать страницу в индекс, canonical помогает не плодить дубли, а robots.txt можно использовать как дополнительный барьер для обхода, но не как единственный способ.
Важно помнить: если вы закроете URL только через robots.txt, поисковик может перестать его сканировать, но уже известный URL иногда останется в индексе без возможности увидеть мета-теги. Поэтому для уже проиндексированных страниц надежнее сначала поставить noindex, а robots использовать осторожно.
Вариант через код темы или mu-plugin
Если вы не хотите зависеть от настроек SEO-плагина, можно добавить правило в код. Для большинства тем достаточно вставить это в functions.php дочерней темы или в отдельный mu-plugin.
add_action('wp_head', function () {
if (is_search()) {
echo "<meta name='robots' content='noindex,follow' />\n";
}
}, 1);
add_filter('wpseo_canonical', function ($canonical) {
if (is_search()) {
return home_url('/');
}
return $canonical;
});
add_filter('rank_math/frontend/canonical', function ($canonical) {
if (is_search()) {
return home_url('/');
}
return $canonical;
});Здесь есть два фильтра для canonical, потому что на практике используют разные SEO-плагины. Если у вас активен только один из них, второй фильтр просто не сработает. Это нормально.
Если вы не используете Yoast SEO или Rank Math, достаточно оставить только вывод мета-тега noindex,follow. Но canonical на главную в случае поиска — разумная страховка, если тема не подставляет свой вариант.
Ограничение обхода в robots.txt
Robots.txt не заменяет noindex, но может снизить лишний обход. Для стандартного WordPress-поиска обычно достаточно закрыть URL с параметром s= от сканирования, если вы понимаете последствия.
User-agent: *
Disallow: /*?s=
Disallow: /search/
Этот вариант работает не в каждом случае одинаково: часть поисковиков по-разному трактует шаблоны с параметрами. Поэтому robots.txt стоит рассматривать как дополнительную меру, а не как единственную.
Сравнение подходов
| Подход | Что делает | Плюс | Минус |
|---|---|---|---|
| Только robots.txt | Ограничивает обход | Просто внедрить | Не гарантирует удаление из индекса |
noindex,follow | Запрещает индексирование | Работает для уже известных URL | Нужно дождаться переобхода |
noindex + canonical | Убирает дубли и задает основной URL | Меньше конфликтов | Требует аккуратной настройки темы/плагина |
Пошаговое внедрение без лишнего риска
- Проверьте, какой формат поиска использует сайт:
?s=,/search/или кастомный шаблон. - Убедитесь, что поисковая страница не нужна как посадочная для SEO.
- Добавьте
noindex,followна все страницы поиска. - Проверьте canonical: он не должен вести на саму поисковую выдачу.
- При необходимости ограничьте обход в robots.txt.
- Отправьте URL на переобход в Search Console, если они уже были в индексе.
Как проверить, что решение сработало
Проверка должна быть не визуальной, а технической. Откройте страницу поиска и посмотрите исходный код: в <head> должен быть мета-тег noindex,follow. Затем проверьте заголовки и canonical. Если canonical указывает на главную страницу или на релевантный раздел, это нормально для внутреннего поиска, если вы не хотите индексировать выдачу.
Дальше используйте Search Console:
- проверьте, ушли ли URL поиска из отчета по индексированию;
- посмотрите, не появились ли новые варианты с параметрами;
- сравните дату последнего сканирования до и после изменений;
- проверьте, не выросло ли число страниц с пометкой «Просканировано, но не проиндексировано» из-за конфликтов canonical.
Если сайт использует кэш, не забудьте сбросить его после правок. Иначе вы можете смотреть на старую версию страницы и думать, что код не сработал.
Частые ошибки и как их исправить
Закрыли поиск только в robots.txt
Это частая ошибка. URL может остаться в индексе, потому что поисковик уже знает о нем, но не может заново просканировать страницу и увидеть noindex. Исправление простое: сначала верните доступ для обхода, добавьте noindex, дождитесь переобхода, и только потом решайте, нужен ли robots.
Поставили noindex на все страницы сайта
Иногда это случается из-за неаккуратного условия в шаблоне или глобальной настройки SEO-плагина. Проверяйте, что условие ограничено именно is_search(). Если noindex появился на обычных записях, это уже не настройка поиска, а серьезная ошибка шаблона.
Canonical ведет на саму поисковую страницу
Такой canonical не помогает убрать дубли. Для внутреннего поиска лучше указывать канонический URL на главную или на тематическую страницу, если запрос фактически заменяет навигацию по разделу. Но не подменяйте canonical на нерелевантную страницу ради «красоты» — поисковик может проигнорировать его.
Кэш отдает старые мета-теги
Если после правки в исходнике ничего не меняется, проверьте серверный и плагинный кэш. Для страниц поиска кэширование иногда вообще лучше отключить или настроить отдельно, чтобы не хранить десятки вариантов выдачи.
Практические советы по безопасности и производительности
Внутренний поиск часто недооценивают как источник нагрузки. Если на сайте много контента и запросы к поиску тяжелые, страницы ?s= могут создавать лишнюю работу для базы данных и кэша. Здесь полезно ограничить кэширование мусорных запросов и следить, чтобы поисковые URL не попадали в sitemap.
Если вы используете SEO-плагин или набор для чистки сайта, проверьте, не генерируются ли отдельные архивы поиска, тегов и авторов без необходимости. В таких случаях удобно сначала убрать дубли и технические страницы, а уже потом настраивать индексацию. Для этого часто используют Clearfy Pro, но сам принцип остается тем же: не плодить URL, которые не дают ценности пользователю и поиску.
Отдельно проверьте формы поиска в теме и виджетах: если они отправляют запросы через GET на нестандартный путь, это может создавать новые шаблоны URL. Чем меньше вариантов поиска, тем проще поддерживать индексацию в порядке.
Что делать после внедрения
После настройки не ждите мгновенного эффекта. Поисковик должен заново обойти страницы, увидеть noindex и убрать их из индекса. На практике полезно отслеживать не только исчезновение URL, но и то, не появились ли новые варианты с параметрами, например с сортировкой или пагинацией.
Если внутренний поиск нужен пользователям, но не нужен в индексе, это нормальная рабочая схема: страница остается доступной на сайте, но не участвует в поисковой выдаче. Именно так и стоит ее настраивать, а не ломать поиск целиком.