Внутренний поиск в WordPress часто создаёт страницы, которые не нужны в индексе: результаты поиска по сайту, пустые выдачи, запросы с мусорными параметрами. Если такие URL начинают попадать в поиск, это обычно не даёт трафика, но добавляет дубли и лишние обходы для робота.
Проблема в том, что закрывать нужно аккуратно. Если просто запретить всё подряд в robots.txt, можно случайно скрыть полезные страницы или оставить в индексе уже найденные URL без возможности их переобхода. Ниже — рабочие варианты для типичного WordPress-сайта: от самого безопасного до более жёсткого.
Когда внутренний поиск действительно нужно закрывать
Не каждый URL поиска — проблема. На небольшом сайте с редким поиском это может вообще не влиять на SEO. Но если в индексе уже появились страницы вида ?s=..., а в отчётах Google Search Console видны запросы с низким качеством, лучше навести порядок.
Типичные признаки, что индексацию стоит ограничить
- в поиске находятся URL с параметром
s; - страницы поиска дают дубли заголовков и сниппетов;
- внутренний поиск генерирует много пустых или почти пустых страниц;
- роботы тратят обход на технические URL вместо полезных материалов;
- в шаблоне поиска нет нормального контента, только список записей.
Если у вас на странице поиска есть полезный текст, фильтры или посадочная логика, закрывать её полностью не всегда разумно. Тогда лучше ограничить только пустые и служебные варианты.
Диагностика: какие URL поиска индексируются сейчас
Перед правками проверьте, что именно попало в индекс. Для WordPress чаще всего это URL с параметром ?s=, например / ?s=seo или /search/seo/, если тема или плагин меняет структуру поиска.
Что смотреть:
- поиск в Google по оператору
site:example.com inurl:s=; - отчёт «Страницы» в Google Search Console;
- логи сервера, если нужно понять, как часто роботы заходят на поиск;
- шаблон
search.phpв теме — есть ли там уникальный контент.
Если URL уже в индексе, одного Disallow в robots.txt может быть недостаточно: робот перестанет ходить по странице, но сам URL не всегда быстро исчезает из выдачи. В таких случаях полезно сочетать несколько методов.
Пошаговое решение: что делать в WordPress
Вариант 1. Добавить noindex на страницы поиска
Это самый предсказуемый способ. Страница остаётся доступной для обхода, но поисковик получает явный сигнал не индексировать её. Для WordPress можно добавить noindex, follow только на результаты поиска.
<?php
add_action('wp_head', function () {
if (is_search()) {
echo '<meta name="robots" content="noindex,follow" />' . "\n";
}
});
Код лучше добавить в дочернюю тему или в небольшой mu-plugin, а не в основной файл темы, если она часто обновляется. Для теста откройте страницу поиска в браузере и посмотрите исходный код: в <head> должен появиться meta robots.
Вариант 2. Закрыть поиск в robots.txt
Если нужно ещё и сократить обход, можно запретить роботу заходить на поисковые URL. Для стандартного WordPress это обычно делается по шаблону /search/ или по параметру, если он попадает в путь через правила темы/плагина.
User-agent: *
Disallow: /search/
Disallow: /*?s=
Но здесь есть нюанс: не все поисковые роботы одинаково обрабатывают параметр в robots.txt, а уже проиндексированные URL могут остаться в выдаче. Поэтому этот способ лучше использовать вместе с noindex, а не вместо него.
Вариант 3. Отдавать 404 для пустого поиска
Если у вас нет задачи показывать страницу поиска вообще, можно жёстче обработать пустые запросы. Это полезно, когда сайт получает много мусорных переходов на пустые поисковые URL.
<?php
add_action('template_redirect', function () {
if (is_search()) {
$query = trim((string) get_search_query(false));
if ($query === '') {
global $wp_query;
$wp_query->set_404();
status_header(404);
nocache_headers();
include get_query_template('404');
exit;
}
}
});
Это уже более жёсткая логика. Её стоит применять только если вы уверены, что пустая страница поиска не нужна пользователям и не используется в навигации.
Что выбрать: robots.txt, meta robots или код
| Подход | Когда подходит | Минус |
|---|---|---|
noindex в <head> | Нужно убрать страницу из индекса без потери обхода | Нельзя мгновенно убрать уже известный URL |
robots.txt | Нужно сократить crawl budget на мусорные URL | Не гарантирует удаление из индекса |
| 404 для пустого поиска | Поиск не нужен как публичная страница | Можно сломать сценарии пользователей |
На практике чаще всего достаточно связки noindex,follow + аккуратный robots.txt. Если сайт крупный и поиск создаёт много мусорных URL, добавляют ещё и обработку пустых запросов.
Проверка результата после внедрения
После правок не ограничивайтесь визуальной проверкой. Нужно убедиться, что поисковик видит именно тот сигнал, который вы задумали.
- Откройте страницу поиска в браузере и проверьте исходный код.
- Убедитесь, что в
<head>естьmeta name="robots" content="noindex,follow". - Проверьте ответ сервера для URL поиска через DevTools или
curl. - В Google Search Console отправьте URL на проверку и посмотрите, как он определяется.
- Через несколько обходов проверьте, исчез ли URL из отчётов индексации.
Пример быстрой проверки через консоль:
curl -I "https://example.com/?s=seo"
Если вы используете 404 для пустого поиска, ответ должен быть 404 Not Found. Если ставите noindex, код ответа обычно остаётся 200, и это нормально.
Частые ошибки и как их исправить
Закрыли в robots.txt, но URL остался в индексе
Это ожидаемо. Disallow запрещает обход, но не всегда удаляет уже известный адрес. Добавьте noindex или временно снимите запрет, чтобы робот смог увидеть директиву удаления.
Поставили noindex на весь сайт через общий шаблон
Такое случается, если условие написано слишком широко. Проверяйте, что код срабатывает только на is_search(), а не на все архивы или страницы.
Сломали поиск для пользователей
Если вы отдаёте 404 на пустой запрос, убедитесь, что форма поиска не отправляет пустое значение по умолчанию. Иногда проблема в теме: кнопка поиска ведёт на URL без параметра, и это надо исправлять в шаблоне формы.
Оставили дубли с параметрами в теме или плагине
Некоторые темы создают отдельные URL для поиска, фильтрации и сортировки. Тогда одного правила для ?s= мало — нужно посмотреть, какие именно параметры генерируются, и закрывать только технические варианты, а не полезные посадочные страницы.
Практические советы по безопасности и производительности
Если внутренний поиск активно используется, не делайте его полностью недоступным без анализа логов. Иногда именно через поиск пользователи находят старые материалы, и жёсткое закрытие ухудшает UX.
- не редактируйте
robots.txtвручную через нестабильные плагины, если они перезаписывают файл при обновлении; - проверяйте, не создаёт ли тема отдельные шаблоны поиска с лишними запросами к базе;
- если на сайте много дублей и технических страниц, полезно сначала провести общую чистку SEO-хаоса — например, через Clearfy Pro, но только если вам реально нужны его функции по noindex, дублям и служебным страницам: https://wpshop.ru/plugins/clearfy;
- не закрывайте полезные страницы поиска, если они уже дают входящий трафик по длинным запросам;
- после изменений следите за отчётами Search Console, а не только за наличием meta-тега.
Если нужна именно техническая дисциплина, а не разовая правка, лучше сразу определить правило: какие URL поиска индексируются, какие нет, и кто отвечает за поддержку этого правила при смене темы или SEO-плагина. Тогда проблема не вернётся после очередного обновления.