Внутренний поиск WordPress часто создаёт страницы, которые не должны попадать в индекс: пустые выдачи, дубли по разным запросам, URL с параметрами и страницы, которые не несут ценности для поиска. На небольшом сайте это выглядит как мелочь, но в реальности такие URL быстро разрастаются и засоряют отчёты в Search Console.
Задача здесь не в том, чтобы «спрятать всё подряд», а в том, чтобы аккуратно закрыть именно страницы поиска, не ломая сам поиск для пользователей и не мешая роботам обходить полезные разделы сайта.
Когда проблема уже видна в индексации
Проверять нужно не только robots.txt, но и то, как WordPress формирует URL поиска. Типичный адрес выглядит так: ?s=запрос. Если сайт использует ЧПУ-поиск через плагин или тему, структура может быть другой, но суть та же — это служебная выдача, а не контентная страница.
Признаки, что с поиском уже есть SEO-проблема:
- в индексе появляются URL с параметром
?s=; - в Search Console растёт число страниц с низкой ценностью и дублирующимся заголовком;
- поисковик показывает пустые или почти пустые страницы поиска;
- в логах обхода много запросов к внутреннему поиску по случайным фразам;
- страницы поиска получают title вроде «Поиск: …», но не дают полезного контента.
Отдельно проверьте, не используются ли на сайте фильтры, которые тоже строятся через параметры URL. Их не нужно путать с поиском: фильтры товаров, сортировка и поиск решаются по-разному.
Что именно нужно закрывать
Обычно достаточно закрыть три типа страниц:
1. Результаты внутреннего поиска
Это страницы, которые WordPress отдаёт по запросу ?s=.... Они почти всегда должны быть noindex, а не просто закрыты в robots.txt. Если закрыть только robots.txt, робот может увидеть URL по ссылкам и продолжить учитывать его в индексации без содержимого.
2. Пустые поисковые выдачи
Если пользователь ищет то, чего нет на сайте, страница с нулевым результатом не должна становиться отдельной индексируемой страницей. Для неё тоже нужен noindex и, как правило, отсутствие каноникала на саму себя.
3. Технические варианты поиска с параметрами
Если тема или плагин добавляет дополнительные параметры к поиску, нужно проверить, не создают ли они отдельные URL. Иногда это post_type, orderby или собственные параметры темы. Такие адреса лучше нормализовать на уровне шаблона или фильтра.
Диагностика: как понять, что закрытие нужно делать кодом
Сначала посмотрите, как сайт отвечает на поисковый URL. Откройте несколько вариантов:
https://site.ru/?s=test;https://site.ru/?s=;- поиск по несуществующему слову;
- поиск по слову, которое точно есть на сайте.
Дальше проверьте исходный код страницы. Ищите:
<meta name="robots" content="noindex,follow">;<link rel="canonical" ...>;- нет ли случайно
index,followна страницах поиска; - не закрыт ли поиск только в
robots.txt.
Если у вас установлен SEO-плагин, он может уже добавлять noindex на поиск. Но это нужно проверять, а не предполагать. В разных темах и конфигурациях поведение отличается.
Пошаговое решение через код темы или мини-плагин
Самый надёжный вариант — добавить правило в functions.php дочерней темы или вынести его в небольшой mu-plugin. Так вы не зависите от интерфейса SEO-плагина и не теряете настройку при смене темы.
Если нужно закрыть страницы поиска от индексации, но оставить переходы по ссылкам доступными для обхода, используйте noindex,follow:
<?php
add_action( 'wp_head', function () {
if ( is_search() ) {
echo '<meta name="robots" content="noindex,follow" />' . "\n";
}
}, 1 );Этот вариант простой, но у него есть ограничение: если SEO-плагин уже выводит свой robots meta, можно получить дублирование. Поэтому лучше сначала проверить, не делает ли это плагин автоматически.
Более аккуратный вариант — использовать фильтр wp_robots, который есть в современных версиях WordPress:
<?php
add_filter( 'wp_robots', function( array $robots ) {
if ( is_search() ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
} );Этот способ предпочтительнее, потому что он работает в рамках штатного механизма WordPress и меньше конфликтует с темой.
Если нужно убрать пустые поисковые страницы отдельно
Иногда полезно различать обычный поиск и пустой запрос. Например, если пользователь открыл ?s= без значения, такую страницу лучше не индексировать и не считать полноценной выдачей:
<?php
add_filter( 'wp_robots', function( array $robots ) {
if ( is_search() ) {
$robots['noindex'] = true;
$robots['follow'] = true;
if ( '' === trim( get_search_query( false ) ) ) {
$robots['noindex'] = true;
}
}
return $robots;
} );Смысл здесь не в отдельном «супер-правиле», а в том, чтобы не оставлять пустую выдачу на усмотрение темы или плагина.
Когда robots.txt помогает, а когда мешает
Закрывать поиск только через robots.txt — распространённая ошибка. Да, это уменьшает обход, но не гарантирует исключение из индекса. Для служебных страниц поиска правильнее использовать noindex на самой странице.
| Подход | Что делает | Минус |
|---|---|---|
noindex через wp_robots | Страница не должна попадать в индекс | Нужно проверить конфликты с SEO-плагином |
| robots.txt | Ограничивает обход | Не гарантирует удаление URL из индекса |
| SEO-плагин | Удобно настраивать без кода | Не всегда покрывает все сценарии темы |
Если у вас уже стоит SEO-плагин и он корректно ставит noindex на поиск, дополнительный код может быть не нужен. Но если в индексе всё равно всплывают поисковые URL, лучше перейти на явное правило в теме или mu-plugin.
Проверка результата после внедрения
После правки не ограничивайтесь визуальной проверкой. Нужно убедиться, что поисковые URL реально отдают нужные сигналы для роботов.
- Откройте страницу поиска в браузере.
- Посмотрите исходный код и найдите robots meta или заголовок
X-Robots-Tag, если он используется сервером. - Проверьте, что на странице есть
noindexи нет случайногоindex. - Убедитесь, что обычные страницы сайта не получили это правило по ошибке.
- В Search Console отправьте URL на повторную проверку, если он уже был в индексе.
Если хотите проверить быстро через консоль, можно посмотреть заголовки ответа:
curl -I "https://site.ru/?s=test"Если сайт отдаёт X-Robots-Tag, он будет виден в заголовках. Если используется только meta robots, смотрите исходный HTML.
Частые ошибки и как их исправить
Закрыли поиск в robots.txt и остановились на этом
Это не решает задачу полностью. Робот может знать URL из внутренних ссылок или внешних упоминаний. Для индексации важнее noindex на самой странице.
Поставили noindex на все страницы через шаблон
Такое бывает, когда условие написано слишком широко. Проверяйте, что срабатывает именно is_search(), а не любой архив или любая страница с параметрами.
Получили дубли robots meta
Если SEO-плагин и тема одновременно выводят robots meta, в коде может быть два тега. Это не всегда критично, но выглядит грязно и иногда сбивает диагностику. В таком случае оставьте один источник правила — либо плагин, либо код.
Не учли пустой поиск
Страница ?s= иногда ведёт себя отдельно от обычного поиска. Её нужно проверить вручную, а не считать, что правило автоматически покрывает все варианты.
Сломали шаблон поиска
Если правка внесена прямо в родительскую тему, обновление может её затереть. Для постоянного решения используйте дочернюю тему или mu-plugin.
Практические советы по безопасности и производительности
Внутренний поиск — частая точка для лишней нагрузки. Если на сайте много контента, поисковые запросы могут создавать заметную нагрузку на базу данных. Это не повод отключать поиск, но повод ограничить мусорные запросы и следить за логами.
- не индексируйте служебные страницы поиска;
- не оставляйте пустые результаты как полноценные посадочные страницы;
- проверяйте, не генерирует ли тема отдельные URL для сортировки и фильтров;
- если сайт большой, смотрите, не нужен ли более быстрый поиск через отдельный плагин или внешний сервис;
- не дублируйте одно и то же правило в нескольких местах без необходимости.
Если вам нужен более широкий набор технических настроек для чистки сайта и SEO-правил, в экосистеме WPShop есть Clearfy Pro. Но даже с плагином полезно понимать, какие именно URL вы закрываете и почему.
В итоге рабочая схема простая: диагностируете поисковые URL, ставите noindex,follow именно на страницы поиска, проверяете исходный код и потом контролируете индексацию в Search Console. Это тот случай, когда точечная правка даёт больше пользы, чем попытка «почистить SEO» одним общим правилом.