Страницы внутреннего поиска в WordPress часто создают лишний мусор в индексе: пустые выдачи, дубли по запросам, URL с параметрами ?s= и слабый пользовательский сигнал для поисковиков. Проблема обычно не в самом поиске, а в том, что его результаты доступны для обхода и индексирования как обычные страницы.
Если не закрыть такие URL, они начинают конкурировать с нормальными страницами сайта, раздувают отчёты в Search Console и могут тянуть на себя обход краулера. Ниже — рабочий способ закрыть именно страницы поиска, не ломая форму поиска и не трогая остальной контент.
Когда это действительно проблема
Сначала стоит убедиться, что речь именно о страницах внутреннего поиска, а не о фильтрах каталога, пагинации или служебных URL. Для WordPress типичный адрес поиска выглядит так: / ?s=запрос или /search/запрос/ в зависимости от темы и настроек ЧПУ.
Диагностика в Search Console и в логах
Проверьте три вещи:
- в отчёте по индексированию есть URL с параметром
s; - в выдаче Google находятся страницы поиска по запросу
site:example.com inurl:?s=; - в логах сервера бот регулярно запрашивает адреса поиска, но на них мало полезного контента.
Если страница поиска отдаёт 200 OK и содержит список результатов, поисковик может попытаться её индексировать. Это не всегда критично, но почти всегда лишнее.
Что именно нужно закрыть
Задача не в том, чтобы отключить поиск на сайте. Нужно:
- оставить форму поиска рабочей для пользователей;
- закрыть страницы результатов поиска от индексации;
- по возможности убрать их из карты сайта и внутренних ссылок, если они туда попали;
- не сломать canonical и robots для обычных страниц.
| Подход | Что делает | Когда подходит |
|---|---|---|
| Плагин SEO/очистки | Добавляет noindex и правит robots | Если нужен быстрый и безопасный вариант без кода |
| Код в теме или плагине | Точечно ставит noindex для поиска | Если нужен контроль и минимальная зависимость от плагинов |
| Только robots.txt | Ограничивает обход, но не всегда индексацию | Как дополнительная мера, но не как единственная |
Пошаговое решение через код
Самый надёжный вариант — добавить noindex, follow на страницы поиска. Для этого не нужно трогать шаблоны поиска, достаточно повеситься на wp_robots. Хук доступен в современных версиях WordPress и позволяет изменить robots-мета без ручной вставки в header.php.
<?php
add_filter( 'wp_robots', function( array $robots ) {
if ( is_search() ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
} );
Если тема или старый плагин уже выводят собственный meta robots, проверьте итоговый HTML страницы. В редких случаях может быть два тега robots, и поисковик возьмёт более жёсткий вариант или проигнорирует конфликтующий набор.
Если нужен вариант для старых тем
На старых проектах иногда проще использовать wp_head и вывести meta вручную только для поиска. Это менее аккуратно, но работает, если тема не поддерживает современный фильтр.
<?php
add_action( 'wp_head', function() {
if ( is_search() ) {
echo '<meta name="robots" content="noindex,follow">' . "\n";
}
} );
Такой способ лучше держать в дочерней теме или в небольшом mu-plugin, чтобы не потерять настройку после обновления шаблона.
Дополнительная защита через robots.txt
Robots.txt не заменяет noindex, но помогает сократить обход мусорных URL. Если у вас есть явные поисковые адреса, можно добавить правило для параметра s. Делайте это осторожно: запрет на обход не гарантирует удаление из индекса, если URL уже известен поисковику.
User-agent: *
Disallow: /*?s=
Disallow: /search/
Этот вариант полезен как дополнительный слой, но не как единственный. Если закрыть только robots.txt, страница может остаться в индексе без сниппета или с урезанным описанием.
Проверка результата после внедрения
После правки не ограничивайтесь просмотром исходника. Проверьте цепочку целиком:
- откройте страницу поиска в браузере и убедитесь, что она доступна пользователю;
- посмотрите исходный код и найдите
noindex,follow; - в Search Console отправьте URL на проверку и запросите повторное сканирование;
- через несколько дней проверьте, исчез ли URL из отчёта по индексированию;
- убедитесь, что обычные записи и страницы не получили лишний
noindex.
Если используете кэш-плагин, очистите кэш после изменения. Иначе вы можете смотреть на старую версию страницы и думать, что код не сработал.
Частые ошибки и как их исправить
Закрыли поиск в robots.txt, но не поставили noindex
Это самая частая ошибка. Бот перестаёт обходить URL, но уже известные адреса могут оставаться в индексе. Исправление простое: добавьте noindex на сами страницы поиска.
Случайно закрыли весь сайт
Иногда фильтр ставят без проверки is_search() или вставляют глобальный meta robots в шаблон. В итоге поисковик получает noindex на всех страницах. Проверьте условие и протестируйте главную, записи и страницы архива.
Использовали конфликтующие SEO-плагины
Если один плагин ставит canonical и robots, а другой — свои правила, итоговый HTML может быть противоречивым. Оставьте один источник управления мета-тегами, а второй отключите или настройте точечно.
Ожидали мгновенного удаления из индекса
Даже при правильной настройке поисковик не убирает URL сразу. Нужны повторный обход и время на переоценку страницы. Если URL критичен, используйте инструмент удаления в Search Console как временную меру, но не как замену настройки.
Когда лучше обойтись без кода
Если на сайте уже стоит SEO-плагин с управлением robots для архивов и служебных страниц, проще использовать его. Например, в проектах, где уже есть Clearfy Pro, можно закрыть лишние типы страниц через интерфейс и не плодить код в теме. Это удобно, если сайт ведёт не разработчик, а редактор или администратор.
Но если задача точечная и нужна только для поиска, код обычно чище: он не зависит от настроек панели и не добавляет лишнюю логику в админку.
Что ещё стоит проверить рядом с поиском
После закрытия страниц поиска полезно посмотреть, не создаёт ли сайт другие служебные дубли: теги, авторские архивы, пагинацию, страницы вложений. Часто именно они вместе с поиском формируют основной объём мусора в индексе.
Если у вас уже настроены правила для дублей и служебных страниц, проверьте, не конфликтуют ли они с новой логикой. На практике лучше один раз собрать карту индексируемых URL, чем потом по отдельности лечить каждый тип страниц.