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

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

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

Диагностика: какие дубли реально есть в WordPress

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

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

• архивы рубрик и тегов;
• страницы автора, если на сайте один автор или почти одинаковые описания;
• пагинацию архивов: /page/2/, /page/3/;
• страницы вложений медиафайлов;
• результаты внутреннего поиска;
• URL с параметрами: ?replytocom=, ?utm_, сортировка, фильтры;
• дубли главной через версии со слешем и без, http/https, www/без www.

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

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

Откройте HTML и посмотрите, что реально отдаёт тема или SEO-плагин:

<link rel="canonical" href="https://example.com/post-name/" />

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

Как выбрать подход: noindex, canonical или удаление дубля

Не все дубли нужно решать одинаково. Иногда достаточно canonical, иногда нужен noindex, а иногда правильнее вообще убрать источник URL из генерации.

Практически: архивы тегов и авторов часто закрывают через noindex, follow или полностью отключают, если они не дают трафика и не несут смысла. Пагинацию обычно не закрывают массово, но следят, чтобы у неё был корректный canonical и не было мусорных параметров.

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

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

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

    return $robots;
} );

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

Убираем лишнее из XML sitemap

Если вы используете встроенные sitemap WordPress, можно отключить отдельные типы контента через фильтры. Например, если теги не нужны в карте сайта:

<?php
add_filter( 'wp_sitemaps_taxonomies', function( $taxonomies ) {
    if ( isset( $taxonomies['post_tag'] ) ) {
        unset( $taxonomies['post_tag'] );
    }

    return $taxonomies;
} );

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

Редирект для страниц вложений

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

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

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

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

Как закрыть параметры URL и мусорные версии страниц

Если дубль создаётся не архивом, а параметром в адресе, задача сложнее. Например, ?replytocom= может плодить отдельные URL для комментариев, а параметры фильтрации и сортировки — отдельные версии каталога или списка записей.

Здесь важно не пытаться «запретить всё подряд» в robots.txt. Если страница уже в индексе, robots.txt не удалит её оттуда быстро и предсказуемо. Лучше либо поставить canonical на чистый URL, либо отдать noindex там, где это допустимо.

Пример: убрать replytocom из индексации

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

Если у вас есть собственная логика генерации canonical, следите, чтобы она не включала мусорные query string. Базовый принцип простой: canonical должен указывать на канонический адрес без технических параметров.

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

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

Например, в Clearfy Pro есть инструменты для чистки сайта и удаления дублей, и это может быть удобным вариантом, если нужно быстро закрыть типовые источники мусора без ручного кода. Но даже в этом случае полезно понимать, что именно отключено и как это влияет на sitemap, canonical и внутреннюю перелинковку.

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

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

1. Откройте проблемный URL и убедитесь, что в исходном коде появился нужный noindex или canonical.
2. Проверьте sitemap: лишние типы архивов и вложения не должны там присутствовать.
3. В Search Console отправьте на повторную проверку несколько URL и посмотрите, как меняется статус индексации.

Если вы закрывали страницы вложений редиректом, проверьте, что ответ действительно 301, а не 302. Если ставили noindex, убедитесь, что страница не заблокирована в robots.txt: поисковик должен иметь возможность её обойти и увидеть мета-тег.

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

Закрыли страницу в robots.txt и ждёте удаления из индекса

Это частая ошибка. Если URL уже известен поисковику, запрет на обход не равен удалению. Для удаления нужен noindex, canonical на основную страницу или редирект.

Поставили noindex на важные страницы архивов

Иногда рубрики дают трафик, а их закрывают «на всякий случай». В результате теряется полезная посадочная страница. Сначала проверьте реальную роль архива: есть ли у него трафик, уникальный текст, полезная навигация и внутренняя перелинковка.

Отключили теги, но оставили их в sitemap

Это создаёт противоречие: вы говорите поисковику не индексировать, но одновременно предлагаете URL в карте сайта. Сначала уберите источник из sitemap, потом проверьте meta robots и canonical.

Сломали canonical на пагинации

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

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

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

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

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

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

• Проверены все типы дублей: архивы, вложения, параметры URL.
• Решено, что закрываем через noindex, что через редирект, а что оставляем.
• Sitemap очищен от лишних URL.
• Canonical указывает на правильную основную страницу.
• После обновления кэш сброшен и страница проверена в исходном HTML.
• В Search Console отправлены на переобход ключевые URL.

Если нужна быстрая типовая чистка без ручного кода, можно посмотреть Clearfy Pro: https://wpshop.ru/plugins/clearfy?utm_source=wpstuff.ru&utm_medium=article&utm_campaign=zakryt-dubli-stranits-ot-indeksacii-v-wordpress. Но даже с плагином полезно понимать, какие именно URL вы закрываете и почему: в SEO это решает не кнопка, а корректная логика индексации.