Внутренний поиск WordPress часто создаёт мусорные URL вида ?s=..., а иногда ещё и страницы с пустой выдачей, сортировками или параметрами фильтрации. Если такие адреса попадают в индекс, они начинают конкурировать с нормальными страницами сайта, раздувают отчёты в Search Console и забирают краулинговый бюджет у полезных URL.
Задача здесь не в том, чтобы «спрятать всё подряд», а в том, чтобы оставить поиск рабочим для пользователей и одновременно убрать его из индекса. Ниже — рабочая схема для обычного WordPress без выдуманных костылей.
Когда внутренний поиск действительно нужно закрывать
Не каждый URL поиска надо трогать одинаково. Если у вас поиск используется как навигация по контенту, но сам результат поиска не несёт самостоятельной ценности для поиска, его обычно имеет смысл закрыть от индексации. Это особенно заметно на сайтах с большим количеством материалов, где поисковая выдача часто формируется из коротких запросов, дублей и пустых страниц.
Типичные признаки проблемы
- в индексе есть страницы с адресом
?s=и почти пустым сниппетом; - в Search Console растёт число «Просканировано, но не проиндексировано» для поисковых URL;
- поисковые страницы получают переходы из выдачи, но не дают стабильной пользы;
- на сайте есть несколько вариантов одного и того же запроса из-за параметров, например
?s=seoи?s=seo+wordpress; - поисковая выдача показывает мало контента, а иногда вообще страницу «Ничего не найдено».
Диагностика: что именно индексируется
Сначала проверьте, какие URL реально попали в индекс и как они выглядят в HTML. Это важно, потому что решение зависит от того, есть ли у вас отдельный шаблон результатов поиска, плагин для поиска или просто стандартный механизм WordPress.
- Откройте несколько URL вида
https://site.ru/?s=запрос. - Посмотрите исходный код страницы и проверьте наличие
meta name="robots". - Проверьте canonical: он должен указывать на саму страницу поиска только если вы сознательно хотите её индексировать.
- В Search Console найдите отчёт по страницам и посмотрите, не растёт ли количество URL с параметром
s.
Если у вас уже стоит SEO-плагин, не спешите добавлять второй слой правил в тему. Сначала выясните, кто сейчас управляет robots и canonical: тема, плагин SEO или кастомный код. Два конкурирующих решения чаще ломают индексацию, чем помогают.
Пошаговое решение через код
Самый предсказуемый вариант — добавить noindex,follow для страниц поиска и оставить ссылки доступными для обхода. Для WordPress это можно сделать через фильтр wp_robots, который поддерживается в современных версиях ядра.
<?php
add_filter( 'wp_robots', function( array $robots ) {
if ( is_search() ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
} );Этот вариант хорош тем, что не ломает сам поиск и не требует править шаблон вручную. Но если тема или SEO-плагин уже выводит свои robots-мета, нужно убедиться, что итоговый HTML не содержит конфликтующих директив.
Если нужен отдельный canonical для поиска
Для большинства сайтов canonical на поисковой странице не обязателен, но иногда его добавляют, чтобы явно показать поисковикам, что это служебная страница. Важно не ставить canonical на главную или на случайную категорию — это уже искажает смысл страницы.
<?php
add_filter( 'get_canonical_url', function( $canonical ) {
if ( is_search() ) {
return home_url( '/' );
}
return $canonical;
} );Такой подход стоит применять осторожно. Если на поисковой странице есть полезные переходы из органики или внутренней навигации, canonical на главную может быть слишком агрессивным. В большинстве случаев достаточно noindex,follow без подмены canonical.
Сравнение подходов: плагин, код или SEO-плагин
| Подход | Когда подходит | Минус |
|---|---|---|
| Код в теме или mu-plugin | Нужен точный контроль над is_search() | Требует поддержки при смене темы |
| SEO-плагин | Уже используется на сайте и управляет robots | Легко получить конфликт настроек |
| Редирект поиска на главную | Поиск не нужен вообще | Пользователь теряет функциональность, а сайт — удобство |
Если поиск нужен посетителям, редирект — плохая идея. Он маскирует проблему, но не решает её. Для нормального сайта лучше закрыть индексацию и оставить поиск рабочим.
Как настроить это без конфликта с SEO-плагином
Если у вас уже стоит Yoast SEO, Rank Math или другой SEO-плагин, проверьте, не задаёт ли он свои правила для страниц поиска. В таком случае лучше выбрать один источник правды. Либо всё делает плагин, либо всё делает код. Смешивать оба варианта без необходимости не стоит.
Практический порядок такой:
- Отключите ручные правки robots в шаблоне, если они есть.
- Добавьте правило через
wp_robotsили настройку SEO-плагина. - Проверьте исходный HTML одной поисковой страницы.
- Убедитесь, что нет двух тегов
meta name="robots".
Проверка результата после внедрения
После изменения не ограничивайтесь визуальной проверкой. Нужно посмотреть именно итоговый HTML и реакцию поисковых систем.
- Откройте страницу поиска в браузере и посмотрите исходный код.
- Проверьте, что в
robotsестьnoindexиfollow. - Убедитесь, что страница не отдаёт 404 и не редиректит без причины.
- Проверьте, что внутренние ссылки на поиск всё ещё работают.
- Через Search Console отправьте URL на повторную проверку, если он уже был в индексе.
Если вы используете серверный кеш, очистите его после правки. Иначе вы можете смотреть старую версию страницы и решить, что код не сработал.
Что смотреть в исходном коде
Минимальный набор признаков, что всё настроено правильно: в head есть noindex, страница открывается без ошибок, canonical не указывает на случайный URL, а в выдаче поиска по сайту пользователь по-прежнему видит результаты. Для страниц с пустой выдачей это особенно важно: они не должны становиться отдельными индексируемыми документами.
Частые ошибки и как их исправить
На практике проблемы почти всегда повторяются. Ниже — то, что ломает настройку чаще всего.
Ошибка 1. Добавили noindex в robots.txt
robots.txt не управляет индексацией так, как многие ожидают. Если URL уже известен поисковику, запрет в robots может помешать обходу, но не гарантирует удаление из индекса. Для поисковых страниц нужен именно noindex в HTML или HTTP-заголовке.
Ошибка 2. Поставили canonical на главную без разбора
Это выглядит как быстрый способ «склеить всё», но на деле создаёт путаницу. Canonical должен отражать близкий по смыслу документ, а не просто любую страницу сайта.
Ошибка 3. Спрятали поиск через JS, но URL остались доступны
Если форма поиска скрыта, а URL по-прежнему открывается напрямую, поисковик всё равно может его обходить. Нужно работать с самим ответом сервера, а не только с интерфейсом.
Ошибка 4. Конфликт с SEO-плагином
Когда тема выводит один robots-мета, а плагин — другой, итог зависит от порядка подключения. Это легко пропустить. Проверяйте не настройки в админке, а фактический HTML страницы.
Практические советы по безопасности и производительности
Если внутренний поиск активно используется, он может стать источником лишней нагрузки. Это не повод его отключать, но повод ограничить мусорные запросы и следить за кешированием.
- не индексируйте страницы поиска с пустым запросом;
- не плодите параметры в URL без необходимости;
- если поиск генерирует тяжёлые запросы к базе, проверьте логи медленных запросов;
- не ставьте агрессивные редиректы на каждую поисковую страницу — это ухудшает UX и усложняет отладку;
- после изменений тестируйте и обычный поиск, и пустой результат.
Если на сайте уже используется Clearfy Pro, часть задач по закрытию дублей и технической чистке можно закрыть через него, но всё равно стоит проверить итоговый HTML и не полагаться только на галочки в интерфейсе. Для поисковых страниц важен именно фактический результат в коде страницы.
Когда лучше не закрывать поиск от индексации
Есть редкие случаи, когда поисковая выдача сама по себе полезна: например, если сайт построен вокруг каталога с очень точными запросами и выдача имеет стабильный спрос. Но это уже отдельная SEO-логика, и её нельзя переносить на обычный блог или корпоративный сайт без проверки данных.
Если сомневаетесь, начните с noindex,follow и наблюдайте за Search Console. Это безопаснее, чем удалять поиск из интерфейса или пытаться «починить SEO» редиректами.