Внутренний поиск WordPress часто оставляет в индексе страницы вида ?s=.... На небольшом сайте это выглядит как шум, а на крупном — как источник дублей, пустых страниц и лишней нагрузки на обход. Проблема обычно не в самом поиске, а в том, что поисковик получает доступ к результатам, которые не несут самостоятельной ценности.
Ниже — рабочий сценарий: сначала проверяем, что именно индексируется, затем закрываем служебные URL на уровне robots.txt и, если нужно, дополнительно ограничиваем выдачу на уровне PHP. Такой подход полезен, когда нужно не просто «поставить noindex», а убрать саму причину появления мусорных страниц.
Что именно нужно закрывать
В WordPress внутренний поиск обычно строится вокруг параметра s. Типичные URL выглядят так: / ?s=запрос, иногда с дополнительными параметрами сортировки или фильтрации. Если сайт использует темы и плагины, которые генерируют собственные формы поиска, URL может меняться, но базовый паттерн почти всегда один и тот же.
Закрывать нужно не только саму страницу поиска, но и варианты с параметрами, которые создают бесконечные комбинации. Иначе поисковик продолжит обходить почти одинаковые страницы, а вы получите дубли и размывание релевантности.
Диагностика: как понять, что проблема уже есть
Перед правками проверьте, действительно ли поисковые URL попали в индекс или хотя бы активно обходятся. Это можно сделать несколькими способами.
- Вбейте в поисковик запрос вида
site:example.com inurl:?s=и посмотрите, есть ли результаты. - Откройте отчёт по страницам в Google Search Console и найдите URL с параметром
s. - Проверьте логи сервера или аналитику: если на поиск идут регулярные заходы ботов, закрывать его стоит даже до индексации.
Если поиск возвращает много пустых или почти пустых страниц, это уже сигнал. Особенно часто такое бывает на сайтах с плохой настройкой шаблона результатов поиска, когда страница выглядит как обычный архив и легко индексируется.
Пошаговое решение
1. Закройте поиск в robots.txt
Самый простой слой защиты — запретить обход URL с параметром s. Это не гарантирует удаление уже проиндексированных страниц, но снижает вероятность появления новых.
User-agent: *
Disallow: /*?s=
Disallow: /search/
Если у вас на сайте нет ЧПУ-пути /search/, строку можно убрать. Но правило с ?s= полезно почти всегда. После правки проверьте, что файл доступен по /robots.txt и не перекрыт кэширующим плагином или CDN.
2. Добавьте noindex для страниц поиска на уровне PHP
Если тема или SEO-плагин не управляют мета-тегами поиска, можно добавить их вручную. Это не замена robots.txt, а дополнительный слой, который помогает убрать уже найденные страницы из индекса.
add_action('wp_head', function () {
if (is_search()) {
echo "<meta name=\"robots\" content=\"noindex,follow\" />\n";
}
}, 1);
Такой код лучше добавлять в дочернюю тему или в небольшой mu-plugin, а не в основной шаблон. Тогда он не потеряется при обновлении темы.
3. Не давайте поиску отдавать пустые результаты как обычную страницу
Если запрос пустой или слишком короткий, лучше перенаправить пользователя на нормальную страницу, а не показывать индексируемый мусор. Это особенно полезно, когда форма поиска отправляет пустой s из-за ошибки в теме.
add_action('template_redirect', function () {
if (is_search() && trim((string) get_query_var('s')) === '') {
wp_safe_redirect(home_url('/'), 302);
exit;
}
});
Здесь важно не переборщить: если у вас есть сценарий, где пустой поиск используется как отдельная страница с подсказками, редирект может быть лишним. Тогда ограничьтесь только noindex и robots.
Что выбрать: robots.txt, noindex или редирект
| Подход | Когда применять | Компромисс |
|---|---|---|
robots.txt | Чтобы уменьшить обход и не пускать ботов к поисковым URL | Не удаляет уже проиндексированные страницы |
noindex | Чтобы убрать результаты поиска из индекса | Страницу всё ещё могут обходить |
| Редирект | Когда пустой или служебный поиск не нужен пользователю | Нужно аккуратно проверить UX и сценарии темы |
На практике чаще всего нужен набор из двух слоёв: robots.txt плюс noindex. Редирект подключают только для явно пустых или ошибочных запросов.
Проверка результата после внедрения
После изменений не ограничивайтесь визуальной проверкой. Нужно убедиться, что поисковики видят именно то, что вы задумали.
- Откройте
/robots.txtи проверьте, что правило для?s=реально отдается сервером. - Сделайте тестовый поиск на сайте и посмотрите исходный код страницы: должен появиться
noindex,follow. - Проверьте URL с параметром
sв Search Console через проверку URL. - Убедитесь, что редирект не ломает внутренний поиск для пользователей.
Если страница всё ещё индексируется, обычно причина одна из трёх: правило в robots.txt не совпадает с фактическим URL, мета-тег не выводится из-за кэширования HTML, либо поисковик уже успел сохранить старую версию и нужно время на переобход.
Частые ошибки и как их исправить
Закрыли поиск только в robots.txt
Это частая недоработка. robots.txt ограничивает обход, но не всегда убирает уже известные URL из индекса. Если страница уже попала в выдачу, добавьте noindex и дождитесь переобхода.
Поставили noindex через плагин, но кэш отдает старую версию
Если на сайте есть полный HTML-кэш, мета-тег может не обновиться сразу. Очистите кэш страницы поиска и проверьте ответ сервера без CDN. Иначе вы будете смотреть на старый HTML и думать, что код не работает.
Сделали редирект для всех поисковых запросов
Это ломает пользовательский сценарий. Поиск нужен не только для индексации, но и для навигации. Редирект оправдан только для пустого поиска или технических параметров, а не для всех запросов подряд.
Использовали слишком широкое правило в robots.txt
Если запретить слишком много, можно случайно закрыть полезные страницы, которые используют похожие параметры. Перед публикацией проверьте, какие URL реально генерирует тема и какие из них должны оставаться доступными.
Практические советы по безопасности и производительности
Если внутренний поиск активно используется, он может стать точкой лишней нагрузки. Поисковые боты любят перебирать запросы, а некоторые темы ещё и строят тяжёлые SQL-запросы. В таком случае полезно:
- ограничить пустые и слишком короткие запросы;
- не отдавать индексируемую страницу без содержимого;
- проверить, не кэшируется ли поиск как обычная публичная страница;
- убрать из шаблона лишние блоки, которые не нужны на странице результатов.
Если нужен более широкий технический аудит дублей и служебных страниц, в экосистеме WPShop есть Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже с плагином полезно понимать, какие именно URL вы закрываете и почему.
Хорошая проверка после внедрения — открыть несколько поисковых URL вручную, убедиться в наличии noindex, проверить ответ сервера и посмотреть, не создаёт ли тема новые варианты параметров. Если этого не сделать, можно закрыть только один шаблон, а дубли продолжат появляться через другой.