Поисковые страницы WordPress часто попадают в индекс случайно: внутренний поиск, страницы с параметром ?s=, фильтры, архивы по датам, служебные URL плагинов. На небольшом сайте это выглядит как мусор в отчёте Search Console, а на большом — ещё и как лишняя нагрузка на обход. Закрывать всё подряд нельзя: можно случайно убрать из индекса полезные страницы или сломать навигацию для ботов.
Ниже — рабочая схема: что именно закрывать, чем это делать в WordPress и как проверить, что поисковик действительно перестал индексировать мусорные URL.
Какие страницы обычно нужно закрывать
Сначала стоит отделить полезные страницы от технических. В индекс обычно не нужны:
- результаты внутреннего поиска;
- страницы с пустым или слишком общим поисковым запросом;
- архивы по датам, если они не несут самостоятельной ценности;
- служебные страницы с пагинацией, если они дублируют основной контент;
- страницы с параметрами сортировки, фильтрации и трекинга;
- авторские архивы на сайтах, где у автора нет отдельной смысловой нагрузки.
При этом не стоит автоматически закрывать всё, что выглядит как архив. Если у вас медиа-сайт, каталог или блог с сильной структурой по рубрикам, часть архивов может быть полезной и для пользователей, и для поиска.
Диагностика: где именно появляется дубль
Перед правками проверьте, какие URL реально индексируются. Самый быстрый путь — открыть Search Console и посмотреть отчёт по страницам, а затем вручную проверить несколько адресов сайта. Для WordPress типичные сигналы такие:
/search/в красивых ЧПУ, если тема или плагин выводит поиск в отдельный путь;?s=запросв адресной строке;/page/2/и дальше в архивах;/2024/05/в датированных архивах;- страницы с параметрами
?orderby=,?filter=,?utm_.
Если сомневаетесь, откройте URL в браузере и посмотрите исходный код страницы. Важно понять, стоит ли там уже noindex или только каноникал. Каноникал сам по себе не гарантирует исключение из индекса, если поисковик считает страницу полезной.
Пошаговое решение: закрываем поиск и служебные архивы
1. Добавьте noindex для поисковых страниц
Если у вас есть доступ к теме или мини-плагину, можно добавить мета-тег noindex,follow только на страницы поиска. Это безопаснее, чем править robots.txt вслепую: бот увидит страницу, но не будет считать её индексируемой.
<?php
add_action('wp_head', function () {
if (is_search()) {
echo '<meta name="robots" content="noindex,follow" />' . "\n";
}
});Этот вариант подходит, если у вас нет SEO-плагина или вы хотите точечно закрыть именно поиск. Если SEO-плагин уже управляет robots-мета, лучше не дублировать логику в теме, а использовать его настройки или фильтры.
2. Закройте пустой поиск и мусорные запросы
Пустой поиск — частая причина дублей. Пользователь открывает страницу поиска без запроса, а WordPress отдаёт архив с общим шаблоном. В таком случае лучше не только поставить noindex, но и не пускать пустые запросы в обработку.
<?php
add_action('template_redirect', function () {
if (is_search() && trim((string) get_search_query()) === '') {
wp_safe_redirect(home_url('/'), 302);
exit;
}
});Редирект на главную или на страницу поиска с подсказкой — вопрос UX. Главное, чтобы пустой URL не попадал в индекс и не создавал лишний дубль.
3. Отключите индексацию архивов, которые не нужны
Если архивы по датам или автору не дают ценности, их можно закрыть через SEO-плагин или код. Для архивов по датам часто достаточно добавить noindex и оставить переходы для пользователей.
Если вы используете Yoast SEO, Rank Math или другой SEO-плагин, сначала проверьте его настройки для архивов. Не стоит одновременно включать noindex в плагине и дублировать это в теме: потом сложно понять, кто именно генерирует тег.
Сравнение подходов: плагин, код, robots.txt
| Подход | Когда использовать | Плюсы | Минусы |
|---|---|---|---|
| SEO-плагин | Если уже стоит плагин для мета-тегов и архивов | Управление из админки, меньше ручного кода | Легко запутаться в настройках, если включено несколько правил |
| Код в теме/мини-плагине | Нужна точечная логика для поиска или отдельных архивов | Точный контроль, не зависит от интерфейса | Нужно следить за обновлениями темы и не дублировать логику |
| robots.txt | Нужно ограничить обход, а не индексацию | Просто закрыть технические пути | Не заменяет noindex и не решает проблему дублей полностью |
Что делать с robots.txt
robots.txt полезен, когда нужно снизить обход мусорных URL, но он не должен быть единственным инструментом. Если закрыть страницу только через robots.txt, поисковик может оставить её в индексе без содержимого или с устаревшим сниппетом. Для поиска и архивов чаще нужен именно noindex.
Пример точечного ограничения для служебных путей:
User-agent: *
Disallow: /wp-admin/
Disallow: /wp-login.php
Disallow: /search/
Disallow: /*?s=
Disallow: /*?orderby=
Disallow: /*?filter=
Sitemap: https://example.com/sitemap_index.xmlНо не копируйте этот блок без проверки. Если у вас поиск работает по другому пути, а фильтры формируют URL иначе, правила надо подстроить под реальную структуру сайта.
Проверка результата после внедрения
После правок не ограничивайтесь просмотром страницы в браузере. Проверьте три вещи:
- в исходном коде страницы поиска появился
meta name="robots" content="noindex,follow"; - URL не возвращает 200 на пустой поиск, если вы настроили редирект;
- в Search Console новые страницы поиска перестали попадать в отчёт как индексируемые.
Для быстрой локальной проверки можно открыть страницу и посмотреть ответ сервера через DevTools или curl:
curl -I https://example.com/?s=testВ ответе вы не увидите мета-тег, но сможете проверить код ответа, редирект и заголовки. Сам мета-тег смотрится в HTML-ответе:
curl -s https://example.com/?s=test | grep -i robotsЕсли у вас кеш на уровне сервера или CDN, очистите его после изменений. Иначе вы можете смотреть старую версию страницы и думать, что правило не сработало.
Частые ошибки и как их исправить
Закрыли в robots.txt, но не поставили noindex
Это самая частая ошибка. Страница может остаться в индексе, потому что поисковик уже знает URL. Исправление: добавьте noindex на саму страницу и дождитесь переобхода.
Поставили noindex на всё подряд
Иногда в шаблоне темы условие написано слишком широко, и под него попадают не только поиск, но и обычные страницы архива или записи. Проверяйте условия вроде is_search(), is_archive(), is_author() отдельно, а не одной общей проверкой.
Дублируете правила в плагине и теме
Если SEO-плагин уже управляет robots-мета, а в теме добавлен второй блок с тем же тегом, итог может быть непредсказуемым. Оставьте один источник правды: либо плагин, либо код.
Редиректите любой поиск на главную
Это ломает пользовательский сценарий и может скрыть проблему с пустыми запросами. Лучше редиректить только пустой поиск, а для нормального запроса оставить страницу с результатами и noindex.
Не проверили пагинацию архивов
Если закрыли только первую страницу архива, а /page/2/ осталась индексируемой, дубль никуда не делся. Проверяйте не только базовый URL, но и пагинацию, если она есть.
Практические советы по производительности и безопасности
Поисковые страницы и фильтры часто создают лишнюю нагрузку, особенно если сайт большой. Если поиск используется активно, имеет смысл ограничить тяжёлые запросы и не давать пустым страницам строить сложные выборки. Это не только про SEO, но и про экономию ресурсов.
Если вы вносите правки кодом, лучше вынести их в небольшой mu-plugin или отдельный мини-плагин, а не в активную тему. Тогда логика не пропадёт после смены дизайна. И обязательно тестируйте изменения на staging-копии: ошибки в условных тегах WordPress легко ломают шаблон, если вставить код не в то место.
Для сайтов, где нужно быстро навести порядок с дублями, служебными страницами и мета-тегами, иногда удобнее использовать специализированный плагин вроде Clearfy Pro: он закрывает типовые SEO- и технические настройки без ручного вмешательства в шаблон. Но даже в этом случае полезно понимать, какие именно URL вы закрываете и почему.
Если после внедрения вы видите, что в индекс всё ещё попадают старые URL поиска, не спешите менять правила. Сначала проверьте кеш, затем исходный код страницы, затем отчёт Search Console. В таких задачах проблема часто не в WordPress, а в том, что изменения ещё не дошли до поискового робота.