Устранение дублей страниц с canonical и noindex в WordPress

Автор: София Тарасова | Опубликовано: 02.09.2026

Дубли в WordPress обычно появляются не из-за одной ошибки, а из-за набора мелких настроек: архивы тегов, страницы автора, пагинация, UTM-параметры, сортировки, версии с /page/2/, а иногда и из-за темы или плагина, который генерирует отдельные URL для одного и того же контента. Если это не контролировать, поисковик тратит обход на мусорные адреса, а в индексе остаются страницы, которые не должны конкурировать между собой.

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

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

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

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

страницы с параметрами вида ?utm_, ?sort=, ?filter=;
архивы тегов и рубрик, если они дублируют смысловые страницы;
страницы автора на сайте с одним редактором;
страницы вложений медиафайлов;
пагинацию архивов, если она индексируется без необходимости;
версии с и без слеша, http и https, www и без www.

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

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

Самый быстрый путь — открыть несколько подозрительных URL и сравнить исходный код. Важно не гадать, а посмотреть, какой canonical реально отдает страница и есть ли на ней noindex.

<link rel="canonical" href="https://example.com/post/" />
<meta name="robots" content="noindex,follow" />

Если на странице с параметром ?utm_source=... canonical указывает на чистый URL записи — это нормально. Если же canonical остается с параметрами или вообще отсутствует, поисковик может считать адрес отдельной страницей.

Для быстрой проверки удобно смотреть заголовки и HTML через curl:

curl -I https://example.com/post/?utm_source=test
curl -s https://example.com/post/?utm_source=test | grep -i canonical

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

Что делать: canonical, noindex или редирект

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

Ситуация	Что делать	Комментарий
UTM и служебные параметры	canonical на чистый URL	Обычно этого достаточно
Страницы автора на сайте с одним автором	noindex,follow или отключение архива	Если архив не несет пользы
Страницы вложений	редирект на файл или родительскую запись	Лучше не оставлять отдельную индексируемую страницу
Дубли http/https, www/без www	301-редирект	Это не задача canonical
Пагинация архивов	обычно оставить, но контролировать индексацию	Зависит от структуры сайта

Когда canonical достаточно

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

Когда нужен noindex

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

Когда нужен редирект

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

Пошаговое решение в WordPress

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

Шаг 1. Закрыть или перенаправить страницы вложений

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

<?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);
        } else {
            $file = wp_get_attachment_url(get_queried_object_id());
            if ($file) {
                wp_safe_redirect($file, 301);
            }
        }
        exit;
    }
});

Такой подход убирает отдельную индексируемую страницу вложения и не ломает доступ к самому файлу.

Шаг 2. Убрать архивы, которые не нужны

Если у вас один автор, архив автора часто не несет ценности. Его можно отключить или перевести в noindex. Для этого не надо переписывать ядро — достаточно фильтра в теме или плагине:

<?php
add_filter('wpseo_robots', function ($robots) {
    if (is_author()) {
        return 'noindex,follow';
    }
    return $robots;
});

Этот пример работает, если на сайте используется Yoast SEO. Для других SEO-плагинов фильтр будет другим, поэтому сначала проверьте, какой плагин управляет robots-мета.

Шаг 3. Нормализовать canonical для параметров

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

<?php
add_filter('get_canonical_url', function ($canonical, $post) {
    if ($post instanceof WP_Post && is_singular('post')) {
        return get_permalink($post);
    }
    return $canonical;
}, 10, 2);

Этот фильтр полезен, когда canonical начинает «плыть» из-за нестандартной логики темы. Но применять его надо аккуратно: не ломайте каноникал на страницах архивов, таксономий и кастомных типов записей без проверки.

Шаг 4. Отключить индексацию пустых таксономий

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

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

<?php
register_taxonomy('topic', ['post'], [
    'label'        => 'Темы',
    'public'       => true,
    'show_ui'      => true,
    'show_in_rest' => true,
    'rewrite'      => ['slug' => 'topic'],
    'hierarchical' => false,
]);

Само по себе это не ставит noindex, но помогает не плодить лишние сущности с непредсказуемой структурой URL.

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

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

Откройте страницу с параметром и проверьте canonical в исходнике.
Проверьте, что страницы вложений отдают 301, а не 200.
Посмотрите заголовок X-Robots-Tag, если вы настраивали его на уровне сервера.
В Search Console отправьте проверку URL и сравните выбранный canonical с вашим.
Проверьте, не остались ли старые URL в индексе через поиск по сайту и отчет об индексировании.

Для быстрой технической проверки полезна команда:

curl -I https://example.com/attachment-page/
curl -s https://example.com/post/?utm_source=test | grep -i -E 'canonical|robots'

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

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

Ставят noindex вместо редиректа

Это типичная ошибка для дублей протокола, домена и страниц вложений. noindex не решает проблему URL как сущности. Если адрес не нужен, делайте 301.

Закрывают от индексации полезные архивы

Иногда под нож попадают рубрики, которые реально помогают навигации и собирают трафик. Перед массовым noindex проверьте, есть ли у архива уникальный текст, хлебные крошки, внутренние ссылки и понятная структура.

Конфликтуют SEO-плагин и код темы

Если в теме вручную выводится canonical, а SEO-плагин делает то же самое, в HTML может оказаться две версии тега. Это уже явная ошибка. Оставьте один источник правды: либо плагин, либо код.

Оставляют страницы вложений без редиректа

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

Не проверяют пагинацию

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

Что можно улучшить дополнительно

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

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

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