Внутренний поиск WordPress часто создает страницы, которые поисковикам не нужны: ?s=, пустые запросы, мусорные параметры, иногда еще и пагинация результатов. Если такие URL попадают в индекс, они начинают конкурировать с нормальными страницами сайта, раздувают краулинговый бюджет и засоряют отчеты в Search Console.
Задача здесь не в том, чтобы отключить поиск на сайте, а в том, чтобы оставить его рабочим для посетителей и одновременно убрать поисковые URL из индекса. Ниже — рабочая схема: как диагностировать проблему, что именно закрывать, чем лучше управлять через код, а чем через SEO-плагин, и как проверить результат.
Когда проблема действительно есть
Сначала стоит убедиться, что речь именно о страницах поиска, а не о нормальных посадочных страницах. Типичный признак — в индексе появляются URL вида /?s=запрос, /page/2/?s=запрос или варианты с дополнительными параметрами. В отчетах по страницам можно увидеть заголовки вроде «Результаты поиска для…» или вообще пустые сниппеты.
Что проверить в первую очередь
- Откройте поиск по сайту и посмотрите, какой URL формируется после отправки формы.
- Проверьте исходный код страницы поиска: есть ли
<meta name="robots" content="noindex,follow">. - Посмотрите, не генерирует ли тема отдельный шаблон для поиска без мета-тега robots.
- В Google Search Console найдите URL с параметром
sи посмотрите, как они обнаруживаются.
Если поиск работает, но страницы с результатами продолжают индексироваться, значит, запрет на уровне robots.txt не решает задачу. Поисковик может увидеть URL по ссылкам и сохранить его в индексе без содержимого. Для таких страниц нужен именно noindex, а не только Disallow.
Что закрывать, а что оставлять
Не стоит без разбора закрывать все URL с параметрами. В некоторых проектах параметры используются для фильтров, сортировки, UTM-меток или внутренней аналитики. Для страниц поиска логика другая: они почти всегда должны быть noindex,follow, чтобы поисковик не индексировал сам результат поиска, но мог пройти по ссылкам внутри страницы, если они там есть.
| Подход | Когда подходит | Минус |
|---|---|---|
| meta robots noindex | Для страниц поиска и других служебных страниц | Нужно убедиться, что тег реально выводится на нужных шаблонах |
| robots.txt Disallow | Для экономии обхода на явно служебных URL | Не гарантирует удаление уже известных URL из индекса |
| Код в теме/плагине | Когда нужен точный контроль без лишних настроек | Требует аккуратности и тестирования после обновлений |
Решение через код: точечно для страниц поиска
Если нужен предсказуемый результат без зависимости от темы, проще добавить небольшой код в дочернюю тему или в свой мини-плагин. Для обычного поиска WordPress можно вывести noindex,follow только на шаблоне результатов поиска.
<?php
add_action('wp_head', function () {
if (is_search()) {
echo '<meta name="robots" content="noindex,follow" />' . "\n";
}
});Этот вариант рабочий, но есть важная оговорка: если тема или SEO-плагин уже выводят свой robots meta, можно получить дублирование. Тогда поисковик увидит несколько директив, и поведение станет менее предсказуемым. В таком случае лучше не добавлять второй источник, а настроить один основной.
Если у вас есть доступ к шаблону search.php, можно дополнительно убедиться, что страница поиска не получает каноникал на саму себя с мусорными параметрами. Для этого полезно использовать стандартный wp_get_canonical_url() только там, где он действительно нужен, а не копировать его на все шаблоны подряд.
Решение через SEO-плагин: когда код не нужен
Если на сайте уже стоит SEO-плагин, часто проще закрыть поиск через его настройки. Это удобнее для редактора или администратора, который не хочет лезть в код. Важно только проверить, что плагин не конфликтует с темой и не отключает нужные мета-теги на других страницах.
Удобный вариант — использовать плагин, который умеет чистить дубли и управлять техническими страницами. Например, в Clearfy Pro есть инструменты для технической оптимизации и удаления лишних дублей, если вам нужен более централизованный контроль. Но даже в этом случае проверка руками обязательна: интерфейс плагина не заменяет фактический HTML на странице.
Когда лучше выбрать плагин, а не код
- На сайте несколько администраторов, и настройку должен понимать не только разработчик.
- Тема часто обновляется, и вы не хотите держать правку в шаблоне.
- Нужно закрыть не только поиск, но и другие служебные страницы по одной логике.
Пошаговая настройка без лишних рисков
- Проверьте, какие URL поиска уже есть в индексе.
- Определите, где именно будет жить решение: в дочерней теме, мини-плагине или SEO-плагине.
- Добавьте
noindex,followтолько для страниц поиска. - Убедитесь, что на этих страницах не ломается форма поиска и не пропадает навигация по сайту.
- Если есть каноникал, проверьте, что он не указывает на мусорный параметризованный URL.
- После деплоя запросите повторную проверку в Search Console.
Как проверить, что решение сработало
Проверка должна быть не только визуальной. Откройте страницу поиска в браузере и посмотрите исходный код. В <head> должен быть один понятный robots meta с noindex,follow, если вы используете именно этот подход. Затем проверьте HTTP-ответ и HTML через инструменты разработчика или curl.
curl -I "https://example.com/?s=test"
curl -s "https://example.com/?s=test" | grep -i "robots"Если вы видите noindex в HTML, но URL все равно остается в индексе, это не ошибка настройки. Поисковику нужно время, чтобы переобойти страницу и обновить статус. В Search Console можно отправить URL на повторную проверку, но массово это не ускоряет процесс мгновенно.
Что должно измениться после внедрения
- Новые страницы поиска не должны попадать в индекс.
- Уже известные URL должны постепенно исчезать из отчетов как индексируемые.
- В логах обхода станет меньше бесполезных заходов на служебные поисковые страницы.
Частые ошибки и как их исправить
Закрыли поиск в robots.txt и думают, что этого достаточно
Это самая частая ошибка. Disallow ограничивает обход, но не гарантирует удаление URL из индекса. Если страница уже известна поисковику, нужен noindex на самой странице или другой механизм удаления.
Поставили noindex на все страницы сайта
Такое бывает после неудачной настройки SEO-плагина или правки шаблона. Проверяйте условие is_search() и не переносите его в общий хук без фильтра. Иначе можно случайно закрыть архивы, рубрики или обычные записи.
Получили дубли robots meta
Если и тема, и плагин выводят свои мета-теги, поисковик может увидеть несколько директив. Оставьте один источник правды: либо код, либо SEO-плагин, либо настройку темы.
Не проверили каноникал
Иногда страница поиска получает canonical на саму себя с параметром ?s=, а иногда — на главную. Оба варианта могут быть неудачными в зависимости от темы. Для служебных страниц лучше не полагаться на случайную логику шаблона.
Практические советы по безопасности и производительности
Если поиск на сайте часто используется, не перегружайте его лишней логикой в pre_get_posts и не добавляйте тяжелые запросы в шаблон результатов. Служебная страница поиска должна быть максимально легкой: без лишних блоков, без больших виджетов и без тяжелых внешних скриптов.
Для проектов, где поисковые страницы и другие технические дубли уже накопились, полезно сначала навести порядок в индексации, а потом уже заниматься контентом. Иначе вы будете оптимизировать то, что поисковик все равно не должен ранжировать.
Если нужен более широкий контроль над дублями, служебными страницами и базовой технической чисткой, имеет смысл смотреть не на отдельные точечные правки, а на набор инструментов для SEO-гигиены. Но даже в этом случае правило одно: сначала проверка HTML, потом ожидание переобхода, и только затем выводы по индексации.