Как закрыть дублирующиеся archive-страницы WordPress от индексации без потери трафика

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

Задача здесь не в том, чтобы «удалить всё лишнее», а в том, чтобы оставить полезные архивы открытыми, а технические дубли закрыть аккуратно. Ниже — рабочая схема без выдуманных хуков и без опасных массовых правок в базе.

Какие archive-страницы обычно дублируются

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

страницы тегов, которые повторяют категории почти без отличий;
архивы автора на небольших сайтах, где один автор публикует всё;
архивы по датам, если они не несут самостоятельной ценности;
страницы пагинации вида /category/page/2/ и дальше;
внутренний поиск WordPress;
страницы вложений медиафайлов, если они открыты как отдельные URL.

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

Диагностика: как понять, что у вас именно дубли archive-страниц

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

/tag/;
/author/;
/date/;
/page/2/;
/?s=;
страницы вложений изображений.

Полезный признак: если title, H1 и список записей на двух разных URL почти совпадают, это кандидат на дубль. Ещё один сигнал — когда архив не даёт пользователю нового смысла, а только повторяет уже существующий список материалов.

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

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

Пошаговое решение: закрываем лишнее, не ломая полезные архивы

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

1. Закрыть архивы тегов, авторов и дат от индексации

Если на сайте теги и даты не несут самостоятельной ценности, добавьте noindex,follow для этих архивов. Это не удаляет страницы, но просит поисковик не включать их в индекс.

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

    return $robots;
});

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

2. Не индексировать страницы вложений

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

add_action('template_redirect', function () {
    if (is_attachment()) {
        $parent = wp_get_post_parent_id(get_queried_object_id());

        if ($parent) {
            wp_redirect(get_permalink($parent), 301);
            exit;
        }

        wp_redirect(home_url('/'), 301);
        exit;
    }
});

Такой редирект убирает отдельные страницы вложений из обхода и снижает риск появления бесполезных URL в индексе.

3. Ограничить индексацию пагинации там, где она не нужна

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

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

    return $robots;
});

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

4. Убрать архивы, которые вообще не должны существовать

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

add_action('init', function () {
    global $wp_rewrite;

    $wp_rewrite->author_base = 'author';
});

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

Сравнение подходов: плагин, код или ручная настройка

Подход	Когда подходит	Плюсы	Минусы
SEO-плагин	Нужно быстро закрыть архивы без разработки	Понятный интерфейс, меньше риска сломать шаблон	Не всегда хватает точности для отдельных типов архивов
Код в теме или мини-плагине	Нужны точечные правила для конкретного сайта	Гибкость, контроль над логикой	Нужна проверка после обновлений темы и плагинов
Ручная правка шаблонов	Нужно изменить разметку archive.php или taxonomy.php	Можно убрать лишние блоки и заголовки	Выше риск ошибок и регрессий

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

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

После правок не стоит сразу считать задачу закрытой. Сначала проверьте, что поисковик видит именно то, что вы задумали.

Что проверить вручную

Откройте проблемный archive-URL и посмотрите исходный код страницы.
Убедитесь, что в <meta name="robots"> есть noindex там, где он нужен.
Проверьте, что полезные категории остались индексируемыми.
Посмотрите, не появились ли циклические редиректы на вложениях.
Пройдитесь по пагинации и убедитесь, что она не закрыла важные разделы.

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

Быстрая проверка через код

Для отладки удобно временно вывести robots-правила в HTML-источник или проверить их в браузере. Например, можно открыть страницу архива и найти строку с noindex. Если её нет, значит фильтр не сработал или его перезаписал другой плагин.

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

Ставят noindex на всё подряд

Это самая частая ошибка. В итоге из индекса исчезают не только теги и даты, но и полезные категории, которые приводят трафик. Исправление простое: разделите архивы по типам и применяйте правила выборочно.

Закрывают страницу, но оставляют её в меню

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

Делают 301-редирект на главную без логики

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

Не проверяют конфликт с SEO-плагином

Если на сайте уже есть Yoast SEO, Rank Math или другой SEO-инструмент, он может управлять robots-мета и canonical сам. Тогда код из functions.php нужно тестировать отдельно, иначе получится дублирование правил или неожиданный результат.

Практические советы по безопасности и производительности

Любые правки лучше вносить не в родительскую тему, а в child theme или мини-плагин. Так обновление темы не сотрёт изменения. Перед внедрением сделайте резервную копию и проверьте сайт на staging-копии, если она есть.

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

не генерирует ли тема лишние термины и пустые таксономии;
не создаются ли отдельные страницы для медиа без необходимости;
не дублируются ли архивы через разные URL-форматы;
не выводятся ли одинаковые блоки в категориях, тегах и авторских архивах.

Если задача шире и нужно одновременно убрать дубли, почистить технические страницы и настроить SEO-правила, удобнее делать это в одном месте, а не разносить по нескольким плагинам и кускам кода. Тогда проще отследить, что именно изменилось после релиза.