Внутренний поиск WordPress часто создаёт мусорные URL: пустые выдачи, страницы с одним и тем же запросом в разных регистрах, дубли с параметрами сортировки и фильтрами. Для поисковиков это не полезные посадочные, а технические страницы, которые размывают краулинговый бюджет и иногда попадают в индекс вместо нормальных разделов.
Если у вас уже настроены robots.txt и базовая индексация, но в отчётах всё равно всплывают URL вида ?s=, /search/ или страницы поиска с параметрами, проблема обычно не в одной настройке, а в связке: шаблон темы, мета-robots, canonical и поведение самого поиска.
Что именно ломается и как это выглядит в индексе
Типичный сценарий такой: пользователь ищет на сайте, WordPress отдаёт страницу результатов, а поисковик видит её как отдельный документ. Если запрос короткий, пустой или повторяется с разными параметрами, появляются десятки почти одинаковых страниц. Иногда они индексируются даже тогда, когда в выдаче нет ни одного результата.
Проверять нужно не только саму страницу поиска, но и все варианты URL, которые генерирует тема или плагины:
/?s=запрос;/search/запрос/;- поиск с параметрами фильтрации и сортировки;
- страницы без результатов, но с индексируемым заголовком и canonical на саму себя.
Диагностика: где искать проблему
Сначала откройте несколько поисковых URL вручную и посмотрите исходный код страницы. Важны три вещи: есть ли noindex, какой canonical указан и не закрыта ли страница только через robots.txt. Если страница уже в индексе, одного robots.txt недостаточно: поисковик может продолжать хранить старую версию в выдаче.
Полезно проверить и логи сервера или отчёты в Search Console: если бот часто ходит по поисковым URL, а полезных переходов нет, это хороший кандидат на закрытие от индексации.
Какой подход выбрать: плагин, код или оба варианта
Если задача локальная и вам нужен контроль над конкретным шаблоном поиска, лучше править кодом темы или мини-плагином. Если на сайте много технических дублей, удобнее использовать SEO-плагин или набор настроек, который умеет управлять мета-robots и canonical без ручной правки шаблонов.
| Подход | Когда подходит | Плюс | Минус |
|---|---|---|---|
| Код в теме/плагине | Нужно закрыть именно поиск WordPress | Точный контроль | Нужно тестировать после обновлений |
| SEO-плагин | Есть много дублей и архивов | Быстро настраивается | Меньше гибкости в нестандартных шаблонах |
| robots.txt | Нужно снизить обход мусорных URL | Просто внедрить | Не гарантирует удаление из индекса |
Пошаговое решение без лишней магии
1. Закройте страницу поиска от индексации через meta robots
Если тема выводит результаты поиска как обычную страницу, добавьте noindex,follow для поисковых запросов. Это не запрещает переход по ссылкам на странице, но говорит поисковику не добавлять её в индекс.
<?php
add_action('wp_head', function () {
if (is_search()) {
echo '<meta name="robots" content="noindex,follow" />' . "\n";
}
}, 1);
Этот вариант рабочий, но в реальном проекте лучше не дублировать мета-тег, если SEO-плагин уже делает это сам. Перед добавлением проверьте исходный код страницы поиска.
2. Нормализуйте сам поиск, чтобы не плодить дубли
Частая проблема — пустой запрос или запрос из одних пробелов. В таком случае WordPress всё равно создаёт страницу результата. Можно перехватить пустой поиск и отправить пользователя на обычную страницу поиска без мусорного URL или на страницу с подсказкой.
<?php
add_action('template_redirect', function () {
if (!is_search()) {
return;
}
$query = get_search_query(false);
$query = trim(wp_unslash($query));
if ($query === '') {
wp_safe_redirect(home_url('/'), 302);
exit;
}
});
Если у вас есть отдельная страница с подсказками поиска, можно редиректить туда. Главное — не оставлять пустую выдачу как индексируемую страницу.
3. Ограничьте индексацию параметров, которые не несут смысла
Если тема или плагин добавляют к поиску параметры сортировки, фильтры или трекинг, проверьте, не создают ли они отдельные URL. Для таких страниц обычно нужен canonical на основную версию без лишних параметров. Это особенно важно, если поиск сочетается с фильтрами по рубрикам или меткам.
В шаблоне можно явно задать canonical для поиска без параметров:
<?php
add_filter('get_canonical_url', function ($canonical, $post) {
if (is_search()) {
$search = get_search_query(false);
$search = trim(wp_unslash($search));
if ($search !== '') {
return home_url('/?s=' . rawurlencode($search));
}
}
return $canonical;
}, 10, 2);
Это не универсальная панацея: если у вас SEO-плагин уже управляет canonical, не надо наслаивать ещё один фильтр без проверки результата.
4. Подправьте robots.txt только как дополнительный слой
Закрывать поиск в robots.txt можно, но это вспомогательная мера. Она уменьшает обход мусорных URL, но не заменяет noindex на уже известных страницах.
User-agent: *
Disallow: /?s=
Disallow: /search/
Если у сайта есть нестандартный формат поиска, проверьте реальные URL в браузере и подставьте именно их. Не копируйте правила вслепую: иногда тема использует не /search/, а только query string.
Проверка результата после внедрения
После правок не ограничивайтесь просмотром страницы в браузере. Откройте исходный код и убедитесь, что на поисковой странице есть noindex,follow, а canonical не указывает на случайную страницу или на саму себя без смысла.
Дальше проверьте три вещи:
- поисковый URL с пустым запросом даёт редирект или нормальную обработку;
- в Search Console новые поисковые страницы не появляются как индексируемые;
- старые URL постепенно выпадают из отчётов, а не множатся с новыми параметрами.
Для быстрой ручной проверки удобно открыть страницу поиска и посмотреть response headers и HTML. Если используете серверный кеш, не забудьте очистить его после изменения шаблона, иначе вы будете смотреть старую версию страницы.
Частые ошибки и как их исправить
Закрыли поиск только в robots.txt
Это самая распространённая ошибка. Если страница уже в индексе, robots.txt не удалит её сам по себе. Добавьте noindex и дождитесь переобхода.
Поставили noindex, но забыли про canonical
Иногда поисковик видит страницу поиска с параметрами и считает её отдельной версией полезного документа. В таком случае canonical должен вести на основную форму поиска или на релевантную страницу, а не на мусорный URL.
Сломали поиск редиректом на главную
Редирект на главную для любого запроса — плохая идея. Пользователь вводит запрос и получает нерелевантную страницу, а не результаты. Редиректить стоит только пустой или заведомо мусорный запрос.
Дубли создаёт не WordPress, а тема или плагин
Некоторые темы выводят поиск через отдельный шаблон, а плагины добавляют фильтры и AJAX-обновление. В таком случае правка в functions.php может быть недостаточной. Проверьте, не генерирует ли плагин собственный endpoint или параметр.
Чек-лист перед публикацией изменений
- Проверен исходный код страницы поиска.
- Добавлен
noindex,followдля поисковых страниц. - Пустой запрос не создаёт индексируемую страницу.
- Canonical не ведёт на мусорный URL.
- robots.txt не конфликтует с реальными маршрутами поиска.
- Кеш очищен на сервере и в плагине, если он есть.
- Проверка выполнена в Search Console и вручную в браузере.
Когда лучше не править кодом
Если на сайте уже стоит SEO-плагин, который управляет мета-robots, canonical и архивами, не дублируйте логику в теме. Сначала проверьте настройки плагина. Для сайтов с большим количеством технических дублей иногда удобнее использовать один инструмент для чистки индексации, чем держать несколько разрозненных правок в шаблонах.
Если нужна именно комплексная чистка дублей, архивов и технических страниц, имеет смысл смотреть в сторону решений, которые умеют управлять индексацией без ручного вмешательства в код. Но даже в этом случае сначала проверьте конкретный шаблон поиска: автоматические настройки не всегда покрывают нестандартную тему.
В рабочем проекте задача обычно решается не одной строкой, а связкой из трёх действий: закрыть индексирование, нормализовать URL и проверить, что поисковик больше не получает мусорные страницы. Это как раз тот случай, где аккуратная техническая правка даёт больше пользы, чем очередной SEO-совет общего характера.