Страницы внутреннего поиска в WordPress часто становятся техническим мусором для индексации: у них меняется только запрос, а контент почти всегда пустой, повторяющийся или слишком тонкий. Для пользователя это рабочий инструмент, для поисковика — источник дублей и лишних URL в обходе. Если сайт уже индексирует десятки или сотни адресов вида ?s=, проблему лучше решать не точечно, а на уровне шаблона и правил индексации.
Ниже — практический сценарий: как закрыть страницы поиска от индексации, при этом оставить сам поиск доступным для посетителей и не сломать формы, виджеты и AJAX-обработку, если они уже используются в теме или плагине.
Когда это действительно проблема
Не каждый сайт обязан прятать поиск от индексации, но в большинстве проектов это оправдано. Особенно если поиск генерирует страницы без полезного контента, а в выдаче появляются URL с параметрами, которые не несут самостоятельной ценности.
Типичные признаки
- в Search Console появляются URL с
?s=или похожими параметрами; - в индексе есть страницы поиска с одинаковым title и description;
- поисковик тратит обход на внутренние результаты вместо важных страниц;
- в шаблоне поиска нет нормального контента, только список записей или сообщение «ничего не найдено»;
- в теме есть отдельная страница поиска, но она не должна ранжироваться как посадочная.
Диагностика: что именно индексируется
Сначала нужно понять, какой вариант поиска у вас используется. В WordPress это обычно один из трех сценариев: стандартный поиск через ?s=, отдельный шаблон search.php или кастомная страница/форма от плагина. От этого зависит, достаточно ли поставить noindex или нужно еще ограничить генерацию ссылок и каноникал.
Проверьте несколько URL вручную:
https://example.com/?s=тест;https://example.com/search/тест/, если тема делает ЧПУ-поиск;- страницы результатов поиска в мобильной версии и в AJAX-виджете, если они есть.
Затем посмотрите исходный код страницы и ответ сервера. Важно понять, есть ли уже meta robots, какой canonical отдает шаблон и не закрыт ли поиск случайно через robots.txt, что может мешать обходу, но не гарантирует удаление URL из индекса.
Что лучше: плагин, код или robots.txt
Для этой задачи чаще всего выигрывает комбинация: noindex, follow на самих страницах поиска и нормальный каноникал на основную страницу сайта. Robots.txt можно использовать как дополнительную меру, но не как единственный способ.
| Подход | Когда подходит | Минус |
|---|---|---|
| Плагин SEO | Если уже стоит SEO-плагин и в нем есть управление мета-robots | Не всегда покрывает кастомные шаблоны поиска |
| Код в теме/плагине | Если нужен точный контроль без лишних зависимостей | Нужно аккуратно тестировать после обновлений темы |
| robots.txt | Как дополнительный барьер для обхода | Не убирает уже найденные URL из индекса сам по себе |
Пошаговое решение через код
Самый надежный вариант — добавить noindex, follow на страницы поиска и задать канонический URL на главную или на саму страницу поиска, если это оправдано. Для обычного WordPress-поиска это можно сделать через фильтр wp_robots.
<?php
add_filter( 'wp_robots', function( $robots ) {
if ( is_search() ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
} );
Этот вариант работает на уровне вывода мета-роботов и не ломает сам поиск. Пользователь по-прежнему сможет искать по сайту, но поисковым системам будет явно сказано не индексировать страницу результатов.
Если тема или SEO-плагин уже выводят свой canonical, проверьте, не конфликтует ли он с вашим шаблоном. Для поисковых страниц чаще всего логично отправлять canonical на саму страницу поиска с тем же запросом, но если цель — полностью убрать такие URL из индекса, canonical не должен превращать их в самостоятельные посадочные.
В некоторых проектах полезно дополнительно убрать поиск из XML-карты сайта, если туда попадают нестандартные URL. Стандартный WordPress этого не делает, но плагины могут добавлять свои правила генерации sitemap.
Если поиск сделан через отдельный шаблон
Когда тема использует не стандартный ?s=, а отдельный маршрут вроде /search/, одного фильтра может быть мало. Тогда нужно проверить шаблон search.php или кастомный rewrite и убедиться, что страница не получает индексируемый title без смысла.
Пример: если у вас отдельный шаблон поиска, можно явно добавить мета-robots в <head> через wp_head:
<?php
add_action( 'wp_head', function() {
if ( is_search() ) {
echo '<meta name="robots" content="noindex,follow">' . "\n";
}
}, 1 );
Этот способ полезен, когда SEO-плагин не установлен или когда нужно быстро проверить гипотезу без правок в настройках плагина. Но если на сайте уже есть SEO-решение, лучше не дублировать вывод robots в двух местах.
Как не сломать внутренний поиск
Частая ошибка — закрыть от индексации не только страницу результатов, но и сам механизм поиска. Это разные вещи. Пользователь должен продолжать отправлять запросы через форму, а поисковик — просто не должен считать результаты поиска самостоятельной ценностью.
Проверьте три вещи:
- форма поиска отправляет запрос и открывает результаты;
- поиск работает в меню, сайдбаре и мобильной шапке;
- AJAX-поиск, если он есть, не зависит от запрета индексации.
Если у вас есть кастомный AJAX-поиск, убедитесь, что endpoint не закрыт случайно через robots.txt или серверные правила. Поисковый робот не должен обходить API-запросы, но пользовательский интерфейс должен получать ответы.
Проверка результата после внедрения
После правок не ограничивайтесь визуальной проверкой. Откройте страницу поиска и посмотрите исходный код: в <head> должен появиться noindex,follow. Затем проверьте HTTP-ответ и canonical, если он выводится.
Минимальный чек-лист проверки:
- страница поиска открывается без ошибок 404 и 500;
- в исходнике есть
meta name="robots" content="noindex,follow"; - поиск по сайту возвращает результаты как раньше;
- в Search Console новые URL поиска не получают статус «Индексировано»;
- старые страницы поиска постепенно выпадают из индекса после переобхода.
Если нужно ускорить переобход, можно отправить на проверку несколько примеров URL через инспекцию в Search Console. Но не ждите мгновенного эффекта: поисковику нужно время, чтобы увидеть новые директивы.
Частые ошибки и как их исправить
Закрыли поиск в robots.txt и на этом остановились
Это не лучший вариант. Robots.txt ограничивает обход, но не всегда убирает уже известные URL из индекса. Для удаления дублей надежнее использовать noindex на самой странице.
Поставили noindex только на одну версию поиска
Если у сайта есть и ?s=, и ЧПУ-вариант поиска, закрывать нужно оба сценария. Иначе дубли останутся в другой форме.
Сломали canonical в SEO-плагине
Иногда кастомный код конфликтует с настройками Yoast SEO, Rank Math или другого плагина. После правок проверьте исходный код и убедитесь, что canonical не указывает на случайную страницу, а robots не дублируется дважды.
Закрыли от индексации страницу, но оставили индексируемые ссылки на нее
Если поиск активно связан внутренними ссылками, это нормально. Но если в меню или футере есть отдельная ссылка на поисковую страницу, она может продолжать попадать в обход. Для обычного поиска это не критично, но для кастомных посадочных лучше пересмотреть структуру ссылок.
Практические советы по безопасности и производительности
Если поиск на сайте тяжелый, проблема может быть не только в индексации, но и в нагрузке. Частые запросы по ?s= иногда создают лишнюю нагрузку на базу, особенно на больших сайтах. В таком случае имеет смысл ограничить пустые запросы, добавить кеширование результатов на уровне плагина или пересмотреть сам механизм поиска.
Для сайтов с большим количеством дублей и технических страниц иногда удобно использовать инструменты чистки SEO-обвязки, например Clearfy Pro, если он уже вписан в стек проекта. Но даже в этом случае проверка исходного кода и Search Console остается обязательной: автоматические настройки не заменяют ручную валидацию.
Если вы вносите код вручную, держите его в дочерней теме или в небольшом mu-plugin, а не в файле основной темы. Тогда обновление шаблона не затрет настройку.
<?php
/**
* Plugin Name: Search Noindex Helper
*/
add_filter( 'wp_robots', function( $robots ) {
if ( is_search() ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
} );
Такой мини-плагин проще отключить для теста и легче сопровождать, чем правку в functions.php.
Что проверить через неделю после правок
Через несколько дней или недель, в зависимости от частоты обхода, снова откройте отчеты индексации. Важно смотреть не только на количество URL, но и на типы страниц, которые остаются в индексе. Если поисковые страницы все еще всплывают, проверьте, не генерирует ли их сторонний плагин, не создает ли тема отдельные архивы поиска и не переопределяет ли SEO-плагин ваши директивы.
Если после внедрения все работает, а в индексе остались старые URL, это нормально: поисковик должен переобойти их и увидеть новые правила. В этот момент не стоит снова менять схему наугад — лучше оставить один стабильный вариант и дождаться переобхода.