Внутренний поиск в WordPress часто оставляют как есть, а потом получают в индексе страницы вида ?s=.... Для небольшого сайта это может быть незаметно, но на контентных проектах такие URL быстро превращаются в источник мусорных страниц, дублей и лишней нагрузки на обход. При этом сам поиск на сайте обычно нужен: пользователи ищут статьи, а редакция — проверяет, как работает навигация по контенту.
Задача здесь не в том, чтобы отключить поиск полностью, а в том, чтобы правильно закрыть его результаты от индексации и не сломать поведение шаблона. Ниже — рабочий сценарий: что проверить, что именно менять, как не задеть полезные страницы и как убедиться, что поисковая выдача действительно перестала попадать в индекс.
Когда внутренний поиск становится проблемой для индексации
Страницы поиска в WordPress обычно создаются динамически и могут иметь много вариантов URL. Самый типичный пример — /?s=seo. Если на сайте есть фильтры, сортировки или дополнительные параметры, поисковая выдача может комбинироваться с ними и порождать еще больше адресов. Поисковики это видят как отдельные страницы, даже если контент на них почти одинаковый или вообще пустой.
Проблема особенно заметна, если:
- поиск возвращает мало результатов и часто показывает пустую выдачу;
- в шаблоне поиска есть заголовок, хлебные крошки и стандартный каркас, но нет уникального контента;
- в логах обхода видно много запросов к
?s=; - в Search Console появляются URL с параметром поиска;
- на сайте включены плагины, которые добавляют дополнительные query-параметры к поиску.
Что именно нужно закрывать
Обычно речь идет не о запрете доступа, а о том, чтобы поисковики не индексировали результаты поиска. Пользователь должен по-прежнему видеть выдачу, но роботам не нужно хранить ее в индексе. Для этого используют noindex и, в некоторых случаях, nofollow для ссылок на страницы поиска из шаблонов и виджетов.
Важно не путать это с robots.txt. Запрет в robots.txt не всегда решает задачу, потому что URL может остаться в индексе без контента, если на него есть внешние или внутренние ссылки. Для поисковой выдачи надежнее управлять индексацией на уровне HTML-мета или HTTP-заголовков.
Диагностика: как понять, что проблема есть именно у вас
Перед правкой шаблона проверьте, как сейчас отдается страница поиска. Откройте несколько вариантов запроса и посмотрите исходный код страницы. Если в <head> нет noindex, поисковик может индексировать такие URL.
Полезно проверить три вещи:
- какой статус-код возвращает страница поиска;
- есть ли на ней мета-тег robots;
- не создаются ли отдельные канонические URL на каждую поисковую фразу.
Если у вас установлен SEO-плагин, он может уже добавлять noindex автоматически. Но это нужно не предполагать, а проверить по факту. Иногда тема или кастомный код переопределяют поведение плагина.
<?php
// Быстрая проверка в шаблоне или через временный mu-plugin.
add_action('wp_head', function () {
if (is_search()) {
echo "\n<!-- search page detected -->\n";
}
}, 1);
Этот фрагмент не решает задачу сам по себе, но помогает убедиться, что шаблон действительно считает страницу поиском. Если комментарий появляется на странице выдачи, значит условный тег is_search() работает корректно.
Рабочее решение: закрыть поиск от индексации через код
Если SEO-плагин не используется или его настройка неудобна, можно добавить правило в тему или, лучше, в небольшой mu-plugin. Так вы не потеряете настройку при обновлении темы.
Самый безопасный вариант — добавить noindex, follow для страниц поиска. Это означает: не индексировать саму выдачу, но позволить роботам переходить по ссылкам дальше, если они есть.
<?php
/**
* Plugin Name: Search Noindex
*/
add_action('wp_head', function () {
if (is_search() && !is_admin()) {
echo '<meta name="robots" content="noindex, follow" />' . "\n";
}
}, 1);
Если у вас уже есть SEO-плагин, сначала проверьте, не дублируется ли мета robots. Два разных тега с конфликтующими значениями — частая причина странного поведения. В таком случае лучше оставить один источник управления индексацией.
Когда лучше использовать не мета-тег, а заголовок
Если сайт отдает HTML не только для браузера, но и для других клиентов, иногда удобнее управлять индексацией через HTTP-заголовок X-Robots-Tag. Это особенно полезно, когда шаблон страницы поиска формируется нестандартно или часть контента отдается через кэш-прокси.
<?php
add_action('send_headers', function () {
if (is_search() && !is_admin()) {
header('X-Robots-Tag: noindex, follow', true);
}
});
Этот способ не отменяет мета-тег, если он уже есть. Но в спорных случаях заголовок помогает задать правило на уровне ответа сервера, а не только HTML.
Сравнение подходов: плагин, код или robots.txt
| Подход | Что делает | Плюсы | Минусы |
|---|---|---|---|
| SEO-плагин | Добавляет noindex для поиска через настройки | Быстро, без кода, удобно для редактора | Зависит от конкретного плагина и его шаблонов |
| Код в mu-plugin | Жестко задает noindex для is_search() | Прозрачно, контролируемо, не зависит от темы | Нужно следить за конфликтами с SEO-плагином |
| robots.txt | Запрещает обход URL | Просто добавить | Не гарантирует удаление из индекса и не решает дубли полностью |
Если нужен предсказуемый результат, код в mu-plugin обычно надежнее. Если сайт уже живет на SEO-плагине, логичнее сначала использовать его настройки и только потом добавлять собственный код.
Пошаговая настройка без поломки шаблона
- Проверьте, есть ли на сайте SEO-плагин и не управляет ли он robots-метками для поиска.
- Откройте страницу поиска с несколькими запросами и посмотрите исходный код.
- Убедитесь, что на странице нет конфликтующих тегов
noindexиindex. - Добавьте правило
noindex, followчерезwp_headилиsend_headers. - Если используете кэш, очистите его после правки.
- Проверьте итоговый HTML и заголовки ответа.
Если вы правите тему, а не mu-plugin, не забудьте, что обновление темы может затереть изменения. Для технических правок лучше держать такой код отдельно.
Как проверить, что решение сработало
Проверка должна быть не визуальной, а технической. Откройте страницу поиска в браузере и посмотрите исходный код: в <head> должен быть один понятный robots-инструктаж. Затем проверьте заголовки ответа через DevTools, curl или любой HTTP-инспектор.
curl -I 'https://example.com/?s=wordpress'В ответе ищите X-Robots-Tag: noindex, follow, если вы использовали заголовок. Если поставили мета-тег, проверьте HTML-источник страницы. После этого откройте Search Console и посмотрите, не появляются ли новые URL поиска в отчете по индексированию. Старые записи могут исчезать не сразу, это нормальное поведение.
Дополнительно полезно проверить:
- не меняется ли канонический URL на страницу поиска;
- не отдает ли кэш старую версию страницы без
noindex; - не создаются ли отдельные URL поиска с параметрами сортировки или фильтрации.
Частые ошибки и как их исправить
Ошибка: закрыли поиск в robots.txt и на этом остановились
Такой запрет не всегда убирает URL из индекса. Если поисковик уже знает адрес, он может продолжить хранить его без полноценного обхода. Для результатов поиска лучше использовать noindex.
Ошибка: добавили два разных правила robots
Если SEO-плагин уже выводит noindex, а тема добавляет еще один тег с другим значением, поведение становится непредсказуемым. Оставьте один источник управления.
Ошибка: забыли про кэш
После правки шаблона кэш может продолжать отдавать старый HTML. Очистите серверный кэш, плагин кэширования и CDN, если он есть. Иначе вы проверите не актуальную версию страницы.
Ошибка: закрыли не только поиск, но и полезные страницы
Иногда разработчики ставят условие слишком широко, например по наличию параметра s в URL, и под него попадают другие страницы. Проверяйте условие именно через is_search(), а не по строке запроса вручную, если нет особой причины делать иначе.
Что делать с производительностью и безопасностью
Если поиск на сайте часто используется, имеет смысл следить не только за индексацией, но и за нагрузкой. Пустые или слишком тяжелые запросы могут создавать лишнюю работу для базы данных. Это особенно заметно на сайтах с большим количеством записей и сложными фильтрами.
Практически полезные меры:
- ограничить поиск только по нужным типам записей, если это соответствует логике сайта;
- не выводить в результатах слишком тяжелые блоки без необходимости;
- не позволять индексировать страницы с бесконечными комбинациями параметров;
- проверять, не генерирует ли тема лишние запросы к базе на странице поиска.
Если вы используете готовый SEO-инструмент для чистки дублей и технических настроек, например Clearfy Pro, его удобно держать как единый слой для таких правил. Но даже в этом случае полезно понимать, какой именно код или настройка отвечает за noindex, чтобы не искать проблему вслепую.
Когда лучше не трогать поиск вручную
Если сайт уже использует сложную SEO-логику, мультиязычность или нестандартный шаблон поиска, не стоит сразу вносить правки в тему. Сначала проверьте, не решается ли задача настройкой существующего SEO-плагина или отдельным mu-plugin. Чем меньше логики в теме, тем проще поддержка после обновлений.
Для типового сайта достаточно одного правила: страницы внутреннего поиска не должны индексироваться, но должны нормально работать для пользователя. Все остальное — детали реализации, которые зависят от стека проекта и того, кто потом будет это сопровождать.