Как запретить индексацию вложенных архивов WordPress без ошибок в SEO

Вложенные архивы в WordPress часто появляются незаметно: архивы рубрик второго и третьего уровня, страницы тегов внутри разделов, пагинация архивов, авторские и датированные страницы, которые дублируют основной контент. На небольшом сайте это может не мешать, но на проекте с активной структурой категорий поисковик быстро начинает тратить обход на технические URL, а в индексе остаются страницы без самостоятельной ценности.

Ниже — рабочая схема, как закрыть такие архивы от индексации аккуратно: без массового удаления URL, без конфликтов с canonical и без ситуации, когда robots.txt блокирует страницу, а поисковик всё равно держит её в индексе как «URL без описания».

Когда проблема уже есть: как это выглядит в индексе и в отчётах

Сначала стоит понять, что именно вы закрываете. Ошибка многих сайтов в том, что они ставят noindex на всё подряд или, наоборот, закрывают архивы в robots.txt, не проверив, есть ли на них внешние ссылки и внутренние переходы. В результате страницы продолжают появляться в поиске, но уже без сниппета, либо выпадают важные разделы.

Типичные признаки

в Search Console растёт число страниц с пометкой «Просканировано — сейчас не проиндексировано»;
в индексе есть URL вида /category/news/page/2/, /tag/..., /author/...;
архивы рубрик дублируют друг друга по заголовкам и описаниям;
страницы пагинации получают трафик, но не несут самостоятельной ценности;
в выдаче всплывают технические страницы, хотя они не нужны пользователю.

Если у вас уже стоит SEO-плагин, проверьте, не конфликтует ли его логика с темой. Иногда тема выводит canonical вручную, а плагин добавляет свой вариант. Тогда поисковик получает две разные подсказки и начинает игнорировать часть настроек.

Что закрывать, а что оставить открытым

Не все архивы одинаково бесполезны. Например, архив основной рубрики может быть нормальной посадочной страницей, если он реально помогает навигации и содержит уникальное описание. А вот вложенные архивы и страницы пагинации часто лучше закрыть от индексации, особенно если они не собирают отдельный спрос.

Вариант	Когда подходит	Минус
Плагин SEO	Если нужно быстро закрыть архивы без кода	Меньше контроля над логикой для отдельных типов архивов
Код в теме / mu-plugin	Если нужна точечная настройка по условиям	Нужно аккуратно тестировать и не ломать canonical
robots.txt	Для экономии обхода на явно технических URL	Не гарантирует удаление URL из индекса

Пошаговое решение через код: закрываем вложенные архивы и пагинацию

Если задача точечная, удобнее сделать это кодом. Ниже пример для functions.php дочерней темы или, что безопаснее, для небольшого mu-plugin. Логика простая: если это архив рубрики глубже первого уровня, теговый архив, архив автора или страница пагинации архива — ставим noindex,follow и не трогаем обычные записи.

<?php
add_action('wp', function () {
    if (is_admin()) {
        return;
    }

    $noindex = false;

    // Вложенные рубрики: category/subcategory/...
    if (is_category()) {
        $term = get_queried_object();
        if ($term instanceof WP_Term) {
            $depth = count(get_ancestors($term->term_id, 'category'));
            if ($depth >= 1) {
                $noindex = true;
            }
        }
    }

    // Теги и архивы авторов чаще всего не нужны в индексе на контентных сайтах
    if (is_tag() || is_author()) {
        $noindex = true;
    }

    // Пагинация архивов
    if (is_paged() && (is_archive() || is_home() || is_search())) {
        $noindex = true;
    }

    if ($noindex) {
        add_filter('wp_robots', function ($robots) {
            $robots['noindex'] = true;
            $robots['follow'] = true;
            return $robots;
        });
    }
});

Этот вариант не меняет контент страницы и не блокирует обход. Поисковик может пройти по ссылкам, но не будет считать такие страницы посадочными для индекса.

Если нужен более жёсткий режим для отдельных архивов

Иногда нужно закрыть только конкретную рубрику или набор рубрик. Тогда лучше проверять ID термина или slug, а не тип архива целиком. Это особенно полезно, если часть категорий у вас действительно должна индексироваться.

<?php
add_filter('wp_robots', function ($robots) {
    if (is_category()) {
        $term = get_queried_object();
        if ($term instanceof WP_Term && in_array($term->slug, ['news', 'archive', 'misc'], true)) {
            $robots['noindex'] = true;
            $robots['follow'] = true;
        }
    }

    return $robots;
});

Что делать с canonical и robots.txt

noindex и robots.txt решают разные задачи. Если цель — убрать страницу из поиска, лучше использовать мета-робот или HTTP-заголовок, а не только запрет в robots. Если цель — сократить обход мусорных URL, можно дополнительно закрыть шаблонные пути в robots.txt, но только там, где это не мешает важным страницам.

Для архивов пагинации обычно достаточно noindex,follow. Canonical при этом должен указывать на саму страницу архива, а не на первую страницу раздела, если у вас нет осознанной стратегии объединения сигналов. Не стоит вручную ставить canonical на все страницы пагинации в первую страницу, если на второй и третьей есть уникальные элементы навигации и внутренние ссылки.

Проверка результата после внедрения

После изменения не ограничивайтесь просмотром исходника. Нужно проверить, что WordPress действительно отдаёт нужные сигналы, а SEO-плагин не перезаписывает их позже.

Откройте страницу архива и посмотрите исходный код: должен быть noindex в meta robots или в заголовке, если плагин использует HTTP header.
Проверьте canonical: он должен быть самоссылочным или соответствовать вашей стратегии.
Посмотрите URL в Search Console через проверку страницы: статус должен обновиться после повторного обхода.
Проверьте, не закрыли ли вы случайно обычные рубрики первого уровня.
Убедитесь, что страницы не заблокированы в robots.txt, если вам важно сохранить обход ссылок.

Если используете кэш, очистите его после правок. Иначе вы будете проверять старую версию страницы и решите, что код не работает.

Частые ошибки и как их исправить

Ставят disallow вместо noindex

Это самая частая подмена. Disallow не удаляет URL из индекса, если он уже известен поисковику. Для удаления из выдачи нужен доступ к странице и сигнал noindex либо корректная обработка через заголовки.

Закрывают архивы, но забывают про пагинацию

В итоге индекс остаётся засорён страницами /page/2/, /page/3/ и дальше. Если у вас много материалов, именно пагинация часто создаёт лишний шум.

Переписывают canonical вручную без проверки темы

Некоторые темы уже выводят canonical через wp_head. Если добавить второй canonical из плагина или собственного кода, поисковик может выбрать не тот вариант. Проверяйте исходник и отключайте дублирующий вывод.

Закрывают все архивы подряд

После этого пропадает полезная навигация, а внутренний вес распределяется хуже. Если рубрика работает как посадочная, её лучше оставить открытой и доработать контентом, а не прятать от индекса.

Чек-лист перед публикацией изменений

Определены конкретные типы архивов, которые нужно закрыть.
Проверено, что важные рубрики первого уровня остаются открытыми.
На страницах есть один canonical, без дублей.
noindex применяется только там, где это действительно нужно.
Кэш очищен на сайте и на уровне сервера/CDN.
Проверка в Search Console добавлена в план после переобхода.

Когда лучше обойтись без кода

Если у вас типовой сайт и нужен быстрый результат, удобнее использовать возможности SEO-плагина. Например, в Clearfy Pro можно закрывать технические страницы и дубли без ручного редактирования шаблонов, а это снижает риск ошибки в теме. Но даже в этом случае полезно понимать, какой именно архив закрывается и почему: иначе легко отключить лишнее и получить просадку по внутренней перелинковке.

Код имеет смысл, когда логика зависит от глубины термина, набора рубрик, роли пользователя или состояния страницы. В остальных случаях проще и безопаснее использовать штатные настройки SEO-плагина и потом проверить исходный HTML.

Если после внедрения в индексе остаются старые URL, не пытайтесь ускорить процесс массовыми редиректами без анализа. Сначала убедитесь, что страница отдаёт правильный noindex, не закрыта от обхода и не имеет конфликтующего canonical. Обычно именно в этой тройке и сидит проблема.