Страницы внутреннего поиска в WordPress часто создают мусорный индекс: у них мало уникального контента, URL быстро плодятся по разным запросам, а поисковики тратят краулинговый бюджет на бесполезные страницы. Если на сайте уже есть дубли от пагинации и архивов авторов, следующий типичный источник лишних URL — именно поиск по сайту.
Проблема обычно выглядит так: в отчётах индексации появляются адреса вида /?s=запрос, иногда ещё с параметрами сортировки или фильтрами, а в выдаче можно встретить пустые или почти пустые страницы поиска. Это не всегда критично, но на небольших и средних сайтах такие URL лучше убрать из индекса и не отдавать их роботам как отдельные посадочные страницы.
Когда страницы поиска становятся проблемой
Не каждый сайт обязан закрывать поиск от индексации. Если поиск используется как полноценный каталог и даёт стабильные, полезные результаты, можно оставить его открытым. Но в большинстве проектов внутренний поиск — это техническая страница, а не контентная.
Типичные признаки, что поиск лучше закрыть
- в индексе есть десятки или сотни URL с параметром
?s=; - страницы поиска не получают органический трафик, но регулярно обходятся ботами;
- результаты поиска часто пустые или слишком короткие;
- в выдаче появляются страницы с одинаковыми заголовками, но разными запросами;
- поиск создаёт дубли с параметрами, например
?s=тест&orderby=date.
Если сайт небольшой, закрытие поиска почти всегда безопаснее, чем попытка оптимизировать каждую такую страницу под SEO.
Диагностика: как понять, что именно индексируется
Перед правкой важно не гадать, а посмотреть реальные URL. В Search Console откройте отчёт по страницам и найдите адреса с ?s=. Дополнительно проверьте серверные логи или статистику обхода, если они доступны: поисковые роботы часто возвращаются к поисковым URL даже после удаления их из карты сайта.
Полезно проверить и сам шаблон поиска. В WordPress страница результатов обычно строится через search.php или index.php, а заголовок формируется динамически. Если шаблон выводит полноценный <title> и meta robots не задан, поисковик может воспринимать страницу как обычную.
<?php
// Пример проверки: что отдаёт поисковая страница.
// Откройте URL вида /?s=тест и посмотрите исходный код.
// Важно увидеть, есть ли noindex и не попадает ли страница в sitemap.
Рабочие способы закрыть поиск от индексации
Есть три нормальных подхода: через SEO-плагин, через код темы/му-плагина и через серверную логику. Выбор зависит от того, чем вы уже управляете на сайте.
| Способ | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| SEO-плагин | Если уже используется плагин для мета-тегов и robots | Быстро, без правки темы | Зависимость от интерфейса плагина |
| Код в теме или mu-plugin | Если нужен точечный контроль | Прозрачно, легко проверить | Нужно аккуратно обновлять |
| Редирект или 404 для мусорных запросов | Если поиск вообще не нужен | Жёстко убирает URL из обхода | Можно сломать внутренний поиск для пользователей |
Вариант 1: noindex для страниц поиска
Самый мягкий способ — оставить поиск доступным людям, но запретить индексацию. Для этого можно добавить noindex,follow только на поисковые результаты.
<?php
add_action('wp_head', function () {
if (is_search()) {
echo '<meta name="robots" content="noindex,follow">' . "\n";
}
});
Этот вариант подходит, если вам важно сохранить поиск для пользователей и не трогать логику шаблона. Но одного мета-тега иногда мало: желательно ещё убрать поисковые URL из sitemap, если они туда попали через нестандартную генерацию.
Вариант 2: запрет через robots.txt
Если нужно снизить обход, можно добавить правило в robots.txt. Это не заменяет noindex, но помогает уменьшить количество обращений к поисковым URL.
User-agent: *
Disallow: /?s=
Disallow: /search/
Здесь есть важная оговорка: robots.txt не гарантирует удаление уже проиндексированных страниц. Если URL уже в индексе, сначала нужен noindex или редирект, а затем — запрет обхода.
Вариант 3: редирект или 404 для пустого поиска
Если поиск на сайте не нужен вообще, можно отправлять пустые запросы на главную или отдавать 404. Это жёстче, но иногда оправдано на лендингах, корпоративных сайтах и маленьких блогах без реальной потребности в поиске.
<?php
add_action('template_redirect', function () {
if (is_search() && !get_query_var('s')) {
wp_safe_redirect(home_url('/'), 302);
exit;
}
});
Не делайте такой редирект для всех поисковых запросов без проверки. Пользователь может искать по сайту осознанно, и вы просто убьёте полезную функцию.
Пошаговое решение без лишнего риска
- Проверьте, какие поисковые URL уже есть в индексе.
- Решите, нужен ли поиск пользователям как отдельная функция.
- Если нужен — добавьте
noindex,followнаis_search(). - Если не нужен — настройте редирект или 404 для пустых запросов и проверьте шаблон поиска.
- Уберите поисковые URL из sitemap, если они там есть.
- Переобойдите важные страницы через Search Console и дождитесь переиндексации.
Как проверить, что решение сработало
Проверка должна быть не только визуальной. Откройте страницу поиска в браузере и посмотрите исходный код: в <head> должен появиться meta name="robots" content="noindex,follow", если вы выбрали мягкий вариант. Затем проверьте ответ сервера через DevTools или curl.
curl -I "https://example.com/?s=test"
В ответе не должно быть неожиданных редиректов на мусорные URL, а сама страница должна отдавать предсказуемый статус. Если вы используете редирект для пустого поиска, убедитесь, что он не срабатывает на нормальные запросы.
Дальше откройте Search Console и проверьте:
- уменьшилось ли число URL с
?s=в отчёте по страницам; - не появляются ли новые поисковые URL в sitemap;
- нет ли ошибок сканирования после внедрения;
- сохранился ли доступ к поиску для пользователей, если он нужен.
Частые ошибки и как их исправить
Закрыли только robots.txt, но не добавили noindex
Это частая ошибка. Если URL уже в индексе, один Disallow не уберёт его быстро. Сначала нужен сигнал noindex или редирект, потом — ограничение обхода.
Поставили noindex на все архивы вместо только поиска
Иногда разработчики добавляют условие слишком широко и случайно закрывают категории, теги или записи. Проверяйте, что условие действительно ограничено is_search().
Сломали поиск редиректом
Если редиректить все запросы на главную, пользователь перестаёт получать результаты. Лучше сначала протестировать сценарий пустого поиска и только потом решать, нужен ли более жёсткий запрет.
Оставили поисковые URL в sitemap
Даже при noindex это лишний шум. Если sitemap генерируется SEO-плагином, проверьте его настройки. Если карта сайта кастомная, исключите поисковые страницы на уровне генерации.
Безопасность и производительность
Не стоит вешать тяжёлую логику на каждый запрос к фронтенду. Для простой мета-строки достаточно лёгкого хука в wp_head. Если вы выносите решение в mu-plugin, оно не потеряется при смене темы и не зависит от обновлений шаблона.
Если на сайте много мусорных поисковых запросов, проверьте ещё и нагрузку на базу данных. Иногда проблема не в индексации, а в том, что ботами постоянно генерируются дорогие запросы к поиску. В таком случае полезно ограничить длину запроса, добавить кэширование или вовсе отключить поиск для неавторизованных пользователей, если это допустимо по задаче.
Для сайтов, где нужен более широкий контроль над дублями и техническими страницами, иногда удобнее использовать набор инструментов вроде Clearfy Pro: он помогает закрывать лишние типы страниц и чистить технический шум без ручного дублирования кода. Но даже с плагином всё равно стоит проверить, что именно он меняет в <head> и в robots.txt.
Если после правки поисковые URL всё ещё появляются в индексе, не пытайтесь ускорить процесс сомнительными способами. Безопаснее оставить noindex на месте, дождаться переобхода и убедиться, что новые поисковые страницы больше не генерируются в sitemap и внутренних ссылках.