Внутренний поиск WordPress часто оставляет в индексе мусорные URL вида ?s=. Для поисковика это почти всегда слабые страницы: у них мало уникального контента, много дублей и нестабильные параметры. Но закрывать их нужно аккуратно, чтобы не задеть реальные страницы сайта и не создать цепочку лишних редиректов.
Ниже — рабочая схема: сначала проверяем, что именно индексируется, потом выбираем способ закрытия, затем валидируем результат в Search Console и по логам/выдаче.
Что именно нужно закрывать
Речь не про весь сайт, а только про результаты внутреннего поиска WordPress. Обычно это URL с параметром ?s=запрос, например / ?s=seo или /search/?s=seo, если тема выводит отдельную страницу поиска. Такие страницы могут появляться в индексе из-за ссылок с сайта, внешних переходов или случайного обхода роботом.
Проблема в том, что у поисковой выдачи сайта нет стабильной ценности как у обычной статьи или рубрики. Один и тот же запрос может возвращать разный набор записей, а пустые или слабые результаты создают тонкие страницы, которые не помогают ранжированию.
Диагностика: как понять, что проблема есть
Перед правкой проверьте, действительно ли поисковые URL попали в индекс и как они выглядят для робота.
Что смотреть в первую очередь
- поиск в Google по запросу
site:example.com inurl:?s=; - отчёт «Страницы» в Google Search Console;
- логи сервера: есть ли обход URL с параметром
s; - исходный код страницы поиска: есть ли
noindex, canonical и robots-мета.
Если в индексе уже есть десятки или сотни таких URL, простого удаления из выдачи недостаточно. Нужно закрыть источник проблемы, а не только отправить отдельные адреса на переобход.
Быстрая проверка через браузер
Откройте результат поиска на сайте и посмотрите исходный код. Важно понять, есть ли у темы или SEO-плагина уже готовая разметка. Иногда разработчик темы добавил noindex для поиска, но canonical указывает на саму страницу поиска, и это не лучший вариант.
<meta name="robots" content="noindex,follow">Если такого тега нет, страницу поиска лучше закрыть явно. Делать это можно на уровне SEO-плагина, через wp_head или через серверную настройку, если у вас есть доступ к конфигу.
Какой способ выбрать
Для большинства сайтов достаточно закрыть поиск от индексации и оставить переходы по ссылкам доступными для пользователей. Ниже короткое сравнение подходов.
| Способ | Когда подходит | Минус |
|---|---|---|
| SEO-плагин | Если уже используете Yoast, Rank Math или аналог и не хотите лезть в код | Зависит от настроек плагина и темы |
| Код в теме или мини-плагине | Если нужен точный контроль без лишних зависимостей | Нужно аккуратно тестировать после обновлений |
| robots.txt | Если нужно снизить обход, но не закрыть URL полностью | Не гарантирует удаление из индекса, если URL уже известен поисковику |
Если задача именно в индексации, robots.txt сам по себе не решает вопрос. Он может сократить обход, но не заменяет noindex или корректный canonical.
Пошаговое решение без плагина
Если вы не хотите завязываться на SEO-плагин, добавьте noindex,follow только для страниц внутреннего поиска. Это безопаснее, чем закрывать всё подряд в robots.txt.
<?php
add_action( 'wp_head', function () {
if ( is_search() ) {
echo '<meta name="robots" content="noindex,follow">' . "\n";
}
}, 1 );Этот код можно добавить в дочернюю тему или в небольшой mu-plugin. Он отработает только на страницах поиска WordPress и не затронет обычные записи, страницы и архивы.
Если хотите дополнительно убрать поиск из sitemap, это уже зависит от SEO-плагина. В Yoast и Rank Math такие настройки обычно есть в интерфейсе, и лучше использовать их, чем вручную править XML.
Когда нужен canonical
Для поиска canonical на саму страницу поиска обычно не помогает, потому что у неё нет устойчивой канонической версии. Если поисковая страница всё же должна существовать для пользователей, canonical лучше не подменять на главную или случайную рубрику: это создаёт путаницу для робота.
В большинстве случаев достаточно noindex,follow. Робот сможет пройти по ссылкам на найденные записи, но сама страница поиска не будет участвовать в индексации.
Если используете SEO-плагин
Удобнее всего закрывать поиск в одном месте, если у вас уже стоит SEO-плагин. Тогда не нужно держать отдельный код в теме и помнить о его переносе при смене шаблона.
Проверьте, есть ли в настройках раздел для архивов, таксономий или специальных страниц. У некоторых плагинов поиск закрывается через шаблон robots-мета для архивов, у других — через отдельные правила для страниц с параметрами.
Важно не включать сразу несколько механизмов одновременно: например, noindex в плагине и ещё один такой же тег через код темы. Дубли мета-тегов не ломают сайт, но создают мусор в HTML и усложняют диагностику.
Проверка результата после внедрения
После изменения не ограничивайтесь просмотром страницы в браузере. Нужно проверить и HTML, и реакцию поисковика.
- откройте страницу поиска и убедитесь, что в исходнике есть
noindex,follow; - проверьте, что обычные страницы сайта не получили этот тег;
- в Search Console отправьте URL на проверку;
- посмотрите, исчезают ли новые URL поиска из отчёта об индексировании;
- сравните логи обхода до и после, если у вас есть доступ к серверным логам.
Если страница всё ещё попадает в индекс, проверьте, не генерирует ли тема отдельный шаблон поиска без wp_head(). Это частая причина: код добавили, но шаблон не выводит нужные мета-теги.
Частые ошибки и как их исправить
Закрыли всё через robots.txt
Это распространённая ошибка. Disallow может сократить обход, но не гарантирует удаление уже известных URL из индекса. Для индексации нужен именно noindex или другой явный сигнал.
Поставили noindex на все архивы
Иногда вместе с поиском случайно закрывают рубрики, теги и пагинацию. В результате сайт теряет полезные посадочные страницы. Проверяйте условие: должно быть именно is_search(), а не общий шаблон для архивов.
Добавили тег в шаблон, но забыли про кэш
Если на сайте есть page cache, CDN или серверный кэш, старый HTML может ещё какое-то время отдаваться роботам. После правки очистите кэш и проверьте страницу в режиме инкогнито и через просмотр исходника.
Закрыли поиск, но оставили мусорные параметры
Иногда сайт генерирует не только ?s=, но и другие служебные параметры. Их нужно разбирать отдельно. Не стоит закрывать все query string без анализа: можно случайно задеть полезные фильтры или UTM-метки.
Практические советы по безопасности и производительности
Если поиск на сайте активно используется, стоит подумать не только об индексации, но и о нагрузке. Внутренний поиск по большому каталогу записей может создавать тяжёлые запросы к базе. В таком случае полезно ограничить частоту обхода, включить кэширование страниц поиска на уровне сервера и следить, чтобы поиск не индексировался как полноценный контент.
Если у вас уже есть Clearfy Pro, в нём есть инструменты для чистки сайта и закрытия технических дублей; это может быть удобнее, чем держать отдельные куски кода в теме. Но всё равно проверяйте итоговый HTML и не полагайтесь только на переключатель в админке: тема и SEO-плагин могут конфликтовать.
Как понять, что всё сделано правильно
Хороший результат выглядит так: страница поиска открывается для пользователя, но в исходном коде есть noindex,follow; новые URL с ?s= не накапливаются в индексе; обычные статьи, рубрики и страницы продолжают индексироваться как раньше. Если хотя бы один из этих пунктов не выполняется, нужно возвращаться к диагностике и смотреть, где именно теряется правило.