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

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

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

Как понять, что проблема именно в дублях архивов

Симптомы обычно видны в Search Console и в логах обхода. Не нужно гадать по одному отчету: лучше сверить несколько признаков.

• В индексе есть страницы /author/..., /date/..., /tag/..., хотя они не несут самостоятельной ценности.
• Одна и та же статья доступна по нескольким URL: с пагинацией, с параметрами, через архивы и через внутренние ссылки.
• В отчетах по страницам много URL с пометкой «Просканировано, но не проиндексировано» или «Дубликат, выбранная каноническая страница отличается».
• В поиске всплывают страницы вложений изображений вместо самих материалов.

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

Откройте сайт в режиме инкогнито и посмотрите, какие архивы реально доступны без авторизации. Затем проверьте исходный код нескольких типов страниц:

• главная;
• запись;
• рубрика;
• архив автора;
• страница вложения;
• страница пагинации рубрики.

Если у всех этих URL есть индексируемый статус и они не несут отдельной пользы пользователю, их нужно разруливать по-разному: что-то закрывать от индексации, что-то редиректить, а что-то оставлять, но с каноникалом.

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

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

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

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

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

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

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

    return $robots;
} );

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

2. Убрать страницы вложений из индекса и редиректить их

Страницы вложений — частый источник мусора. Если на них нет смысла как на самостоятельных страницах, лучше редиректить на родительскую запись или на сам файл. Для этого можно использовать штатный фильтр 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;
        }

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

Если у вас уже настроен редирект в SEO-плагине или на уровне сервера, не дублируйте логику в теме. Иначе получите цепочки редиректов или конфликт правил.

3. Оставить полезные рубрики, но убрать мусорные теги

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

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

    return $robots;
} );

Это не универсальное правило. Если у вас крупный контентный проект и теги реально собирают трафик по отдельным кластерам, закрывать их без анализа не стоит.

4. Проверить canonical и пагинацию

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

Если SEO-плагин ставит каноникал неправильно, сначала ищите причину в настройках темы и фильтрах плагина, а не в robots.txt. Robots.txt не решает проблему дублей на уровне каноникала.

Когда лучше использовать плагин, а когда код

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

Если вам нужна более широкая чистка WordPress от дублей, служебных ссылок и лишних элементов, имеет смысл смотреть в сторону инструментов вроде Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже в этом случае полезно понимать, что именно вы отключаете и почему.

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

• Проверили, какие архивы реально индексируются сейчас.
• Определили, какие страницы должны остаться в поиске.
• Добавили noindex только на лишние типы архивов.
• Настроили редирект для attachment-страниц.
• Не трогали полезные рубрики и важные посадочные страницы.
• Проверили, что нет конфликта с SEO-плагином.

Как проверить, что решение сработало

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

1. Откройте проблемный URL в браузере и убедитесь, что в <head> появился noindex там, где он нужен.
2. Проверьте HTTP-статус для attachment-страниц: должен быть 301, если вы настроили редирект.
3. В Search Console отправьте URL на повторную проверку и посмотрите, как меняется статус через время.
4. Убедитесь, что важные страницы не получили noindex по ошибке.
5. Пройдитесь краулером по сайту и посмотрите, не осталось ли лишних архивов в внутренней перелинковке.

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

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

Закрыли всё через robots.txt

Это частая ошибка. Robots.txt запрещает обход, но не гарантирует удаление URL из индекса, если они уже известны поисковику. Для дублей чаще нужен noindex или редирект.

Поставили noindex на рубрики, которые реально нужны

Так можно случайно убрать из поиска важные страницы-кластеры. Если рубрика собирает трафик и служит точкой входа, не закрывайте её без анализа спроса и структуры сайта.

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

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

Оставили дубли в sitemap

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

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

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

Перед правками сделайте бэкап и проверьте сайт на staging-копии. Особенно если у вас уже есть SEO-плагин, кэш-плагин и редиректы на уровне сервера: три слоя логики легко конфликтуют между собой.

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