На WordPress чаще всего индексируются не те страницы, которые реально нужны пользователю: результаты поиска, архивы с пустым или дублирующимся содержимым, вложения, страницы с параметрами, служебные URL плагинов. Проблема обычно не в одной настройке, а в наборе мелких ошибок: где-то стоит index, follow по умолчанию, где-то в sitemap попали архивы, а где-то robots.txt пытается решить то, что должен решать noindex.
Ниже — рабочая схема, которая помогает закрыть технические страницы от индексации и при этом не сломать важные разделы сайта.
Какие страницы обычно нужно закрывать
Не стоит закрывать всё подряд. Сначала разделите URL на две группы: полезные для поиска и служебные. Для affiliate-сайтов и контентных проектов чаще всего в «служебные» попадают:
- страницы внутреннего поиска вида
?s=; - архивы автора и даты, если они не несут самостоятельной ценности;
- вложения медиафайлов, которые дублируют контент записи;
- страницы с параметрами сортировки, фильтрации и UTM, если они создают дубли;
- служебные страницы плагинов, которые не должны ранжироваться;
- страницы пагинации, если они не нужны в индексе по вашей структуре.
Если закрыть слишком много, можно потерять переходы по длинному хвосту и ухудшить внутреннюю перелинковку. Поэтому сначала нужна диагностика.
Диагностика: что именно попало в индекс
Проверьте, какие типы URL уже индексируются. Самый быстрый способ — поиск по сайту в Google и просмотр отчёта «Страницы» в Google Search Console. Ищите:
- URL с
?s=; - архивы
/author/и/date/; - страницы вложений вида
/attachment/или отдельные медиа-страницы; - URL с параметрами
?replytocom=,?filter=,?sort=и похожими; - дубли, которые отличаются только параметром, но ведут на один и тот же контент.
Полезно открыть исходный код таких страниц и проверить, какой robots-мета-тег отдает шаблон. Если там нет noindex, поисковик получает сигнал индексировать страницу, даже если она вам не нужна.
Что проверить в первую очередь
- Есть ли у служебных страниц мета-тег
noindex. - Не попадают ли они в XML sitemap.
- Не закрыты ли они только в robots.txt без
noindex. - Не создают ли плагины SEO и кеша конфликтующие заголовки.
- Не отдают ли вложения отдельную страницу вместо редиректа на файл или запись.
Пошаговое решение: закрываем технические URL правильно
Лучший подход — не полагаться только на robots.txt. Если страница уже известна поисковику, запрет в robots.txt не гарантирует её выпадение из индекса. Для удаления из индекса нужен noindex или редирект на более полезный URL.
1. Закрываем внутренний поиск и архивы через wp_robots
Начиная с современных версий WordPress, удобнее управлять robots-метатегами через фильтр wp_robots. Это безопаснее, чем вручную править шаблоны, и не зависит от темы.
<?php
add_filter( 'wp_robots', function( array $robots ) {
if ( is_search() || is_author() || is_date() ) {
$robots['noindex'] = true;
$robots['nofollow'] = true;
}
return $robots;
} );Этот вариант подходит, если вы действительно не хотите, чтобы архивы автора и даты участвовали в поиске. Если архив автора у вас — полноценная страница с уникальным контентом, закрывать её не нужно.
2. Убираем страницы вложений из индекса
Страницы вложений почти всегда создают мусорный индекс. Если медиа-страницы не используются как отдельные посадочные, лучше редиректить их на сам файл или на родительскую запись.
<?php
add_action( 'template_redirect', function() {
if ( is_attachment() ) {
$parent = wp_get_post_parent_id( get_queried_object_id() );
if ( $parent ) {
wp_safe_redirect( get_permalink( $parent ), 301 );
exit;
}
$file = wp_get_attachment_url( get_queried_object_id() );
if ( $file ) {
wp_safe_redirect( $file, 301 );
exit;
}
}
} );Если у вложений есть смысл как самостоятельных страниц, редирект не ставьте. Но для большинства сайтов это лишний слой дублей.
3. Исключаем служебные страницы из sitemap
Если страница закрыта от индексации, она не должна оставаться в sitemap. Иначе вы отправляете поисковику противоречивые сигналы: «не индексируй» и «вот URL, который надо обойти».
Если используете Yoast SEO или Rank Math, проверьте настройки типов записей, таксономий и архивов. Убедитесь, что в sitemap не попадают:
- страницы поиска;
- архивы, которые закрыты через
noindex; - вложения;
- служебные таксономии без контента.
Если нужен более быстрый способ почистить сайт от дублей и служебных URL, уместно посмотреть в сторону Clearfy Pro: у него есть настройки для удаления дублей, архивов и части технических страниц, но всё равно нужно проверять итоговую разметку и sitemap вручную: Clearfy Pro.
4. Не закрываем всё через robots.txt
Robots.txt полезен для экономии краулингового бюджета, но не для гарантированного удаления URL из индекса. Если вы запретите обход, но URL уже известен поисковику, он может остаться в выдаче без сниппета. Поэтому:
- для удаления из индекса используйте
noindex; - для дублей — редирект или каноникал;
- robots.txt оставляйте для второстепенных служебных путей, которые не должны тратить обход.
Сравнение подходов: плагин, код или компромисс
| Подход | Когда подходит | Минусы |
|---|---|---|
| SEO-плагин | Если нужно быстро закрыть архивы, поиск и вложения без разработки | Легко пропустить конфликт настроек и оставить дубли в sitemap |
| Код в теме или mu-plugin | Если нужен точечный контроль над noindex и редиректами | Нужно тестировать после обновлений темы и плагинов |
| Комбинация | Если часть URL закрывает SEO-плагин, а часть требует кастомной логики | Нужно следить, чтобы правила не дублировали друг друга |
Проверка результата после внедрения
После изменений не ограничивайтесь просмотром кода страницы. Проверьте результат по цепочке:
- Откройте технический URL в браузере и посмотрите исходный код.
- Убедитесь, что на странице есть
noindexили редирект. - Проверьте, исчез ли URL из XML sitemap.
- Посмотрите ответ сервера через
curl -Iили инструменты разработчика. - В Google Search Console отправьте URL на повторную проверку, если он уже был в индексе.
Пример быстрой проверки заголовков:
curl -I https://example.com/?s=testВ ответе важно увидеть либо редирект, либо отсутствие признаков индексации в HTML-странице. Если URL всё ещё отдается как обычная страница с кодом 200 и без noindex, значит правило не сработало.
Частые ошибки и как их исправить
Закрыли страницу в robots.txt, но не поставили noindex
Это самая частая ошибка. Поисковик может продолжать хранить URL в индексе. Исправление: добавьте noindex или редирект, а robots.txt используйте только как дополнительный слой.
Оставили закрытые URL в sitemap
Такое часто бывает после настройки SEO-плагина. Исправление: проверьте типы записей, архивы и таксономии в настройках sitemap и исключите всё, что закрыто от индексации.
Поставили noindex на важные страницы
Иногда под раздачу попадают страницы категорий, фильтров или полезные архивы. Исправление: пересмотрите логику по типам страниц, а не по шаблону «всё архивное закрыть». Для affiliate-сайта это особенно критично, если категории собирают трафик по коммерческим запросам.
Сделали редирект вложений на главную
Это плохой компромисс: пользователь и поисковик теряют контекст. Лучше редиректить на родительскую запись или на сам файл, если он действительно нужен.
Получили конфликт между плагином и кодом
Если SEO-плагин уже добавляет noindex, а ваш код делает то же самое или, наоборот, переопределяет правила, итог может быть непредсказуемым. Исправление: оставьте один источник истины для каждой группы URL.
Практические советы по безопасности и производительности
Чем меньше технических страниц попадает в индекс, тем меньше мусора приходится обходить поисковым роботам. Но не переусердствуйте: массовое закрытие URL без анализа может скрыть полезные страницы и усложнить диагностику.
- Храните кастомные правила в
mu-plugin, если не хотите потерять их при смене темы. - После обновления SEO-плагина повторно проверяйте sitemap и robots-метатеги.
- Не используйте одинаковые правила в нескольких местах: в теме, в плагине и в functions.php.
- Если сайт большой, проверяйте изменения сначала на staging-копии.
Если задача шире и включает чистку дублей, архивов и служебных URL, иногда проще собрать это в одном месте, чем вручную поддерживать набор разрозненных правил. Но даже в этом случае финальная проверка должна быть ручной: исходный код, sitemap и Search Console.