Технические страницы в WordPress часто попадают в индекс не потому, что сайт «плохой», а потому что поисковик видит доступный URL и не получает явного сигнала, что его индексировать не нужно. Это касается страниц поиска, архивов авторов на небольших сайтах, вложений медиафайлов, страниц пагинации с пустым контентом, служебных результатов фильтрации и некоторых URL с параметрами.
Если такие страницы уже попали в индекс, проблема обычно не в одном теге noindex. Нужно проверить, откуда URL вообще берутся, не отдаются ли они в sitemap, нет ли внутренних ссылок на них и не конфликтуют ли настройки SEO-плагина с кодом темы или плагинов.
Какие страницы обычно нужно закрывать от индексации
Не стоит закрывать всё подряд. Сначала разделите URL на полезные и технические. Для большинства проектов под «техническими» понимаются страницы, которые не несут самостоятельной ценности в поиске и часто создают дубли.
- страницы внутреннего поиска вида
?s=; - архивы вложений медиафайлов;
- страницы с параметрами сортировки и фильтрации, если они не продвигаются отдельно;
- служебные архивы автора на сайтах, где один автор и нет редакционной ценности;
- страницы пагинации, если они пустые или почти пустые;
- страницы тегов и рубрик, если они не заполнены и создают мусорный индекс.
Если у сайта уже есть SEO-плагин, часть этих настроек может быть доступна в интерфейсе. Но на практике часто остаются исключения: тема выводит лишние архивы, плагин создаёт отдельные страницы, а в sitemap продолжают попадать URL, которые вы уже закрыли.
Диагностика: где именно возникает проблема
Перед правкой проверьте три вещи: как страница отдаётся в HTML, есть ли она в sitemap и не ведут ли на неё внутренние ссылки. Если закрыть только один слой, поисковик всё равно может продолжить обход.
1. Проверяем мета-тег robots
Откройте проблемный URL и посмотрите исходный код. Ищите строку вида:
<meta name="robots" content="noindex,follow" />Если её нет, страница может индексироваться, даже если вы ожидали обратного. Если тег есть, но URL всё равно в индексе, проверьте, не был ли он найден раньше или не отдаёт ли сервер другой вариант страницы без этого тега.
2. Проверяем sitemap
Если URL есть в sitemap, поисковик получает прямой сигнал, что страница важна для обхода. Для технических страниц это лишнее. В XML-карте не должны оставаться URL, которые вы уже закрыли от индексации.
3. Проверяем внутренние ссылки
Даже закрытая страница будет обходиться, если на неё ведут меню, хлебные крошки, блоки похожих записей, виджеты или ссылки в контенте. Это не всегда плохо, но для мусорных URL лучше убрать источник ссылок.
Пошаговое решение через код
Если нужно закрыть конкретные типы страниц без зависимости от интерфейса плагина, можно добавить фильтры в тему или в небольшой mu-plugin. Такой подход полезен, когда у вас кастомная логика и нужно контролировать результат на уровне кода.
1. Добавляем noindex для поиска, вложений и архивов автора
Пример ниже работает через фильтр wp_robots, который WordPress использует для формирования robots-мета. Это безопаснее, чем вручную печатать тег в шаблоне, потому что не ломает совместимость с другими компонентами.
<?php
add_filter( 'wp_robots', function( array $robots ) {
if ( is_search() || is_attachment() ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
if ( is_author() && count_users()['total_users'] <= 1 ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
} );Здесь есть важная оговорка: проверка count_users() не самая дешёвая операция, поэтому для высоконагруженного сайта лучше не вызывать её на каждом запросе. Если авторский архив нужно закрывать всегда, проще сделать это без дополнительной логики.
2. Закрываем вложения и пустые архивы через pre_get_posts
Если проблема не только в robots, но и в том, что WordPress формирует отдельные архивные страницы без полезного контента, можно перенаправить или отключить их вывод на уровне запроса.
<?php
add_action( 'template_redirect', function() {
if ( is_attachment() ) {
wp_redirect( home_url( '/' ), 301 );
exit;
}
} );Такой редирект уместен, если страницы вложений не нужны как отдельные посадочные. Для медиа-сайтов или проектов, где вложения используются осознанно, этот шаг может быть лишним.
3. Убираем технические URL из sitemap
Если вы используете SEO-плагин, лучше отключать лишние типы архивов в его настройках. Но если нужен кодовый вариант, в WordPress можно исключить отдельные типы записей из XML-карты через фильтры плагина. Для wp_sitemaps в ядре доступно управление провайдерами, но не все сценарии одинаково удобны. На практике чаще проще отключить ненужные архивы в SEO-плагине, чем писать сложный кастомный фильтр.
Если у вас нет SEO-плагина, а sitemap собирается ядром, проверьте, не попадают ли туда вложения и служебные типы записей. Для этого откройте XML и найдите проблемные URL вручную.
Когда лучше использовать SEO-плагин, а когда код
Для типового сайта удобнее закрывать индексацию через интерфейс SEO-плагина: меньше риска сломать шаблон и проще поддерживать при обновлениях. Код нужен там, где есть нестандартные типы записей, отдельные правила для разных ролей или конфликт между плагинами.
| Подход | Когда подходит | Минус |
|---|---|---|
| SEO-плагин | Стандартные архивы, поиск, вложения, теги, рубрики | Не всегда покрывает кастомные сценарии |
| Код в теме или mu-plugin | Нестандартные правила, точечные исключения, кастомные типы | Нужно тестировать после обновлений |
| Комбинированный вариант | Когда часть URL закрывается в интерфейсе, а часть — кодом | Легко получить дубли настроек |
Если на сайте уже используется Clearfy Pro, часть задач по чистке дублей и служебных страниц можно закрыть через его настройки, но всё равно стоит проверить итоговый HTML и sitemap. Автоматическая галочка в админке не гарантирует, что URL исчез из всех источников.
Проверка результата после внедрения
После изменений не ограничивайтесь просмотром страницы в браузере. Нужна проверка на трёх уровнях: HTML, sitemap и ответ сервера.
- откройте проблемный URL и убедитесь, что в исходнике есть
noindex; - проверьте, что URL больше не присутствует в XML-карте сайта;
- посмотрите, не ведут ли на него внутренние ссылки из меню, хлебных крошек и блоков;
- если настроен редирект, убедитесь, что вложение или служебная страница отдают
301, а не200; - в Search Console отправьте страницу на повторную проверку, если она уже была в индексе.
Для быстрой проверки ответа сервера удобно использовать curl:
curl -I https://example.com/?s=testВ заголовках вы не увидите noindex, но сможете проверить код ответа, редиректы и канонический маршрут. Сам robots-тег смотрите в HTML.
Частые ошибки и как их исправить
Страница закрыта от индексации, но всё равно в индексе
Чаще всего причина в том, что URL уже был проиндексирован раньше. В таком случае поисковику нужно время на переобход. Если страница ещё и есть в sitemap, процесс затянется. Уберите её из карты сайта и дождитесь переобхода.
Поставили noindex, но забыли про внутренние ссылки
Это типичная ошибка на сайтах с большим количеством блоков и виджетов. Поисковик продолжает находить URL через навигацию. Если страница не нужна, уберите ссылки на неё из шаблонов и контента.
Закрыли всё подряд, включая полезные архивы
Иногда под раздачу попадают рубрики, которые реально приводят трафик. Не закрывайте архивы только потому, что они «похожи на дубли». Сначала посмотрите, есть ли у страницы уникальный контент, входящий трафик и смысл для пользователя.
Редирект на главную вместо осмысленной страницы
Для вложений и мусорных URL это допустимо не всегда. Если у страницы есть логичный аналог, лучше вести на него. Массовый редирект на главную выглядит как техническая заглушка и может ухудшить поведение пользователей.
Практические советы по безопасности и производительности
Если вы вносите правила через код, не правьте файл темы напрямую. Лучше использовать дочернюю тему или mu-plugin, чтобы изменения не потерялись после обновления. Для небольших правил это особенно важно: один файл с понятной логикой проще сопровождать, чем искать правки по шаблонам.
Не добавляйте тяжёлые проверки в каждый запрос. Например, подсчёт пользователей, запросы к внешним API и сложные выборки из базы в фильтре robots — плохая идея. Для robots-логики нужны быстрые условия: тип страницы, тип записи, наличие параметра, статус авторизации.
Если сайт большой, после внедрения проверьте нагрузку на обход. Иногда закрытие технических страниц уменьшает количество мусорных URL, но одновременно выявляет старые внутренние ссылки и битые маршруты. Это нормально: лучше увидеть проблему сейчас, чем держать её в индексе месяцами.
И ещё один практический момент: не смешивайте noindex, nofollow и редирект без понимания цели. Для большинства технических страниц достаточно noindex,follow. Редирект нужен только там, где есть понятный целевой URL.