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

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

Если в Search Console уже видно рост страниц без трафика, а в выдаче всплывают /tag/, /author/ или /attachment/, проблему лучше решать не точечно, а системно: определить, что именно закрывать, чем закрывать и как проверить, что вы не сломали нормальную индексацию.

Какие дубли WordPress чаще всего попадают в индекс

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

Типовые кандидаты на закрытие

• архивы авторов на сайтах с одним автором;
• архивы меток, если они дублируют рубрики и не несут самостоятельной ценности;
• архивы по датам, если сайт не новостной и эти страницы не нужны в поиске;
• страницы вложений медиафайлов;
• служебные страницы пагинации, если они создают мусор в индексе;
• страницы поиска по сайту, если они доступны для индексации.

Важно не путать «закрыть от индексации» и «удалить из сайта». Страница может оставаться доступной пользователю, но не должна попадать в поиск. Для этого обычно используют noindex, а не редирект на главную.

Диагностика: что именно уже индексируется

Перед правками проверьте, какие URL реально попали в индекс и откуда они берутся. Иначе легко закрыть не то, что нужно, и потом долго разбираться, почему пропали полезные страницы.

Что смотреть в первую очередь

1. Отчет «Страницы» в Google Search Console: ищите типы URL с низкой ценностью и большим количеством дублей.
2. Поиск по сайту в Google: site:example.com tag, site:example.com author, site:example.com attachment.
3. Исходный код проблемной страницы: есть ли meta name="robots" и какой там набор директив.
4. Файл robots.txt: не закрывает ли он то, что нужно сначала убрать из индекса корректно.

Если страница уже проиндексирована, одного robots.txt обычно недостаточно. Поисковик может перестать обходить URL, но не обязан быстро убрать его из индекса. Для удаления нужен noindex или редирект, если страница должна исчезнуть совсем.

Пошаговое решение: закрываем архивы и служебные страницы

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

Шаг 1. Оставьте в индексе только то, что реально полезно

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

Шаг 2. Добавьте noindex на ненужные архивы

Если вы не используете SEO-плагин, можно сделать это через фильтр wp_robots. Это современный способ управлять robots-мета в WordPress без ручной правки шаблонов.

<?php
add_filter( 'wp_robots', function( array $robots ) {
    if ( is_author() || is_tag() || is_date() || is_search() ) {
        $robots['noindex'] = true;
        $robots['follow']  = true;
    }

    if ( is_attachment() ) {
        $robots['noindex'] = true;
        $robots['follow']  = true;
    }

    return $robots;
} );

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

Шаг 3. Для вложений лучше сделать редирект на файл или родительскую запись

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

<?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;
        }

        $url = wp_get_attachment_url( get_queried_object_id() );
        if ( $url ) {
            wp_safe_redirect( $url, 301 );
            exit;
        }
    }
} );

Здесь есть важная оговорка: если у вас медиафайлы используются как самостоятельные посадочные страницы, редирект может быть лишним. Тогда лучше оставить noindex, но не ломать URL.

Шаг 4. Не закрывайте рубрики и пагинацию вслепую

Пагинация сама по себе не всегда вредна. Если у рубрики есть много материалов, страницы /page/2/ и дальше помогают обходу сайта и внутренней перелинковке. Закрывать их стоит только если они действительно создают мусор, а контент на них почти не отличается от первой страницы.

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

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

Что проверить руками

• в исходном коде проблемной страницы появился noindex;
• для вложений сработал редирект, если вы его настраивали;
• страницы рубрик, которые должны индексироваться, не получили случайный noindex;
• в robots.txt нет лишнего запрета на обход важных URL;
• в Search Console новые версии страниц проходят проверку URL.

Если используете командную строку, удобно быстро посмотреть заголовки и редиректы через curl:

curl -I https://example.com/attachment/sample-image/
curl -I https://example.com/tag/sample-tag/

Для страницы с noindex в HTML заголовок ответа может быть обычным 200, это нормально. Важнее наличие директивы robots в HTML или HTTP-заголовке, если вы настраивали ее на уровне сервера.

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

Закрыли архивы в robots.txt, но они остались в индексе

Это частая ошибка. Если URL уже известен поисковику, запрет на обход не гарантирует быстрое удаление. Исправление: сначала поставьте noindex или редирект, потом уже при необходимости ограничивайте обход.

Случайно закрыли полезные рубрики

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

Сделали редирект с вложений на главную

Редирект на главную выглядит как быстрый способ «почистить» сайт, но для SEO это слабое решение. Поисковик получает нерелевантную замену, а пользователь — не то, что ожидал. Лучше вести на родительскую запись или на сам файл, если это оправдано.

Дублируете настройки плагина кодом

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

Безопасность и производительность: что не стоит делать

Не правьте шаблоны напрямую в активной теме, если задача касается только robots-логики. Лучше вынести код в дочернюю тему или небольшой mu-plugin. Так вы не потеряете настройки после обновления.

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

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

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

• определили, какие архивы должны остаться в индексе;
• проверили, что noindex не затронул рубрики с трафиком;
• для вложений выбрали либо редирект, либо noindex;
• убедились, что robots.txt не мешает обходу важных страниц;
• проверили исходный код и заголовки ответа;
• отправили важные URL на повторную проверку в Search Console.

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