Внутренний поиск WordPress часто создает мусорные URL вида ?s=..., которые поисковики могут обходить и индексировать как тонкие страницы. На небольшом сайте это выглядит безобидно, но на практике в индекс попадают десятки и сотни бесполезных страниц поиска с пустым или почти пустым контентом. Это размывает качество индекса и мешает нормальным страницам получать вес.
Ниже разберем, как закрыть такие страницы корректно: что именно нужно ограничить, где чаще всего ошибаются и как проверить, что решение реально сработало.
Какие страницы поиска WordPress нужно закрывать
Речь обычно идет не только о главной странице поиска, но и о любых URL, где параметр s передается в строке запроса. Пример: https://site.ru/?s=seo. В зависимости от темы и плагинов такие страницы могут иметь отдельный шаблон, хлебные крошки, заголовок и даже canonical, но по сути это все равно динамические результаты поиска.
Если поисковик видит их как отдельные документы, он может тратить краулинговый бюджет на бесполезные варианты запросов. Особенно это заметно на сайтах с большим количеством внутренних ссылок на поиск, фильтры и автодополнение.
Диагностика: как понять, что проблема есть
Сначала проверьте, действительно ли поисковые URL доступны для индексации. Самый простой способ — открыть несколько вариантов поиска и посмотреть исходный код страницы.
- Есть ли в
<head>тег<meta name="robots" content="index,follow">или его отсутствие. - Меняется ли canonical на сам URL поиска.
- Возвращает ли страница код ответа
200 OK. - Попадают ли такие URL в отчет «Страницы» в Google Search Console.
Если у вас уже есть индексация, в Search Console часто видно, что Google обнаружил страницы с параметром s как «Просканировано — сейчас не проиндексировано» или просто как отдельные URL в отчете по страницам. Это не всегда катастрофа, но сигнал, что поисковик тратит ресурсы на нецелевые документы.
Быстрая проверка через браузер и curl
Для технической проверки удобно посмотреть заголовки ответа и HTML. Например:
curl -I "https://site.ru/?s=wordpress"Если страница отдает 200, а в HTML нет запрета на индексацию, значит поисковик может ее обрабатывать как обычную страницу. Это не всегда ошибка, но для внутреннего поиска обычно нежелательно.
Как закрыть поиск: рабочие варианты
Есть три нормальных подхода. Выбор зависит от того, хотите ли вы просто убрать URL из индекса или еще и сократить обход таких страниц.
| Способ | Что делает | Когда подходит | Ограничение |
|---|---|---|---|
| meta robots noindex | Запрещает индексацию страницы | Если URL должен открываться пользователю, но не нужен в поиске | Не всегда мгновенно убирает URL из индекса |
| robots.txt | Ограничивает обход | Если хотите снизить нагрузку на краулинг | Не гарантирует удаление уже известного URL из индекса |
| Серверная обработка | Меняет поведение на уровне PHP/веб-сервера | Если нужен полный контроль над поисковыми URL | Требует аккуратной реализации |
Вариант 1: noindex для страниц поиска
Это самый безопасный вариант, если поиск нужен пользователям, но не должен попадать в индекс. В WordPress можно добавить условие в wp_head и выводить noindex,follow только на поисковых страницах.
add_action( 'wp_head', function () {
if ( is_search() ) {
echo '<meta name="robots" content="noindex,follow" />' . "\n";
}
}, 1 );Здесь важно не ставить nofollow без необходимости. Для внутренних ссылок на результаты поиска это обычно лишнее. Если страница не должна индексироваться, но по ней можно переходить, noindex,follow — нормальная рабочая схема.
Вариант 2: запрет обхода в robots.txt
Если цель — еще и уменьшить количество обходов, можно добавить правило в robots.txt. Но не путайте это с удалением из индекса: robots.txt не гарантирует, что уже известный URL исчезнет. Он лишь ограничивает сканирование.
User-agent: *
Disallow: /*?s=
Disallow: /search/Такое правило полезно, если тема или плагин формируют человекопонятный путь поиска вроде /search/keyword/. Но с параметрами нужно быть осторожным: разные поисковики по-разному трактуют шаблоны, а слишком широкое правило может задеть другие URL с параметрами.
Вариант 3: отключить индексацию на уровне шаблона
Если у вас кастомная тема, можно сделать отдельный шаблон для результатов поиска и явно выводить там noindex. Это удобно, когда нужно еще и поменять canonical, заголовок и структуру страницы.
add_filter( 'wp_robots', function( array $robots ) {
if ( is_search() ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
} );Этот способ лучше, чем вручную печатать meta-тег в шаблоне, потому что он использует стандартный фильтр WordPress. Если тема уже подключает wp_robots, вы не ломаете ее логику, а только дополняете правила.
Пошаговое решение без лишнего риска
- Проверьте, как сейчас отдаются страницы поиска: код ответа, canonical, robots.
- Добавьте
noindex,followчерезwp_robotsилиwp_head. - При необходимости ограничьте обход в
robots.txt. - Убедитесь, что поиск не генерирует лишние URL в sitemap.
- Проверьте Search Console и дождитесь переобхода.
Если на сайте используется SEO-плагин, сначала проверьте его настройки. Часто там уже есть опция для закрытия поисковых страниц, и тогда дополнительный код не нужен. Дублировать правила в плагине и в теме — плохая идея: потом сложно понять, какое именно правило сработало.
Проверка результата после внедрения
После изменений не ограничивайтесь визуальной проверкой. Нужно убедиться, что поисковая страница действительно получила нужные сигналы.
- Откройте
?s=тести проверьте исходный код страницы. - Убедитесь, что есть
noindexи нет конфликтующегоindex. - Проверьте canonical: он не должен вести на случайный другой URL поиска.
- Посмотрите ответ сервера через
curl -I. - В Search Console отправьте URL на проверку и посмотрите, как Google видит страницу.
Если вы добавили только robots.txt, не ждите мгновенного исчезновения URL из индекса. Для уже известных страниц поисковику нужен сигнал уровня страницы — обычно это noindex или удаление контента с возвратом другого кода ответа.
Частые ошибки и как их исправить
Закрыли поиск в robots.txt, но URL остались в индексе
Это типичная ситуация. Robots.txt не удаляет страницу из индекса сам по себе. Если URL уже известен поисковику, добавьте noindex и дождитесь переобхода.
Поставили noindex на все страницы сайта
Такое бывает, когда условие написано слишком широко, например без проверки is_search(). В результате поисковик перестает индексировать не только поиск, но и нормальные страницы. Перед выкладкой обязательно проверьте несколько типов URL: главную, запись, рубрику и поиск.
Сломали canonical
Если canonical на странице поиска указывает на главную или на случайную запись, это может запутать поисковик. Для поисковых страниц canonical лучше либо не использовать, либо делать его предсказуемым и не конфликтующим с noindex.
Закрыли не тот путь
Иногда тема использует не параметр ?s=, а отдельный маршрут. Перед правкой посмотрите реальные URL, которые генерирует сайт. Иначе вы закроете старый шаблон, а новый останется доступным.
Что делать с производительностью и безопасностью
Если внутренний поиск активно используется, он может нагружать базу данных. В этом случае одна только индексация — не единственная проблема. Имеет смысл посмотреть, не генерирует ли форма поиска слишком много пустых запросов, а автодополнение — лишние AJAX-обращения.
Для безопасности важно не выводить поисковый запрос в HTML без экранирования. Если вы правите шаблон поиска, используйте стандартные функции WordPress для вывода данных. Например, заголовок запроса должен проходить через esc_html() или аналогичный безопасный вывод в контексте шаблона.
<h1><?php echo esc_html( get_search_query() ); ?></h1>Это не связано напрямую с индексацией, но часто идет рядом: когда разработчик правит шаблон поиска, он одновременно меняет и вывод, и мета-данные. Здесь легко случайно открыть XSS-дыру или сломать верстку.
Когда лучше использовать плагин, а когда код
Если сайт ведется редактором без доступа к теме, удобнее закрывать поиск через SEO-плагин или через настройки темы, если они есть. Если у вас кастомная сборка и нужен точный контроль, код надежнее: он не зависит от интерфейса плагина и не теряется при обновлениях настроек.
На практике часто хватает стандартных возможностей SEO-плагина, а код нужен только для точечной доработки. Если вы уже используете инструменты вроде Clearfy Pro, проверьте, не решается ли задача штатной настройкой без самописных правок.
Мини-чек-лист перед публикацией
- Поисковые URL отдают
noindex,follow. - Canonical не конфликтует с robots-правилами.
- В
robots.txtнет слишком широких запретов. - Главные страницы сайта по-прежнему индексируются.
- В Search Console нет массового роста URL с параметром
s.
Если после внедрения вы видите, что поиск все еще индексируется, не добавляйте сразу новые запреты. Сначала проверьте, какой именно сигнал видит поисковик: meta robots, canonical, robots.txt или ответ сервера. В таких задачах ошибка обычно не в самом принципе, а в конфликте нескольких правил одновременно.