Как убрать дубли контента в WordPress из архивов, фильтров и параметров URL

Автор: Михаил Титов | Опубликовано: 20.09.2026

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

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

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

В реальных проектах чаще всего дубли создают не «вредные» страницы, а штатные механизмы CMS:

архивы автора и даты, если на сайте один автор или даты не несут ценности;
страницы с параметрами сортировки и фильтрации, например ?orderby=, ?filter=, ?utm_;
страницы пагинации, если они повторяют заголовки и сниппеты без добавочной ценности;
страницы вложений, если они не закрыты отдельно;
поисковые страницы и внутренние результаты, которые уже должны быть закрыты;
дубли из-за неправильного canonical в теме или SEO-плагине.

Если у вас уже настроены robots.txt и sitemap, это не означает, что проблема решена. Robots.txt не убирает URL из индекса, а только ограничивает обход. Для дублей важнее понять, что именно должно быть доступно для пользователя, а что — только для робота.

Диагностика: где WordPress создаёт лишние URL

Начинать стоит не с правок в коде, а с проверки фактических URL в индексе и на сайте. Иначе легко закрыть не ту страницу или убрать полезный архив.

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

откройте несколько страниц сайта с параметрами в адресной строке и посмотрите, меняется ли контент;
проверьте canonical в исходном коде страницы;
посмотрите, есть ли одинаковые title и description у разных URL;
сравните архивы автора, рубрик и тегов: не дублируют ли они друг друга почти полностью;
проверьте, не индексируются ли URL с ?replytocom=, ?amp, ?orderby и UTM-метками.

Что смотреть в Search Console и логах

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

grep -E "\?(orderby|filter|utm_|replytocom|amp)=" access.log | awk '{print $7}' | sort | uniq -c | sort -nr | head

Команда не чинит проблему сама по себе, но даёт список URL, с которых стоит начать. Если у вас nginx или другой формат логов, шаблон фильтра придётся адаптировать.

Пошаговое решение: что закрывать кодом, а что — настройками

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

1. Оставьте полезные архивы, лишние — уберите из индекса

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

Для точечной правки можно использовать фильтр wpseo_robots, если у вас установлен Yoast SEO, или аналогичный механизм вашего SEO-плагина. Ниже пример для случаев, когда нужно добавить noindex,follow на архивы автора и даты:

add_filter('wpseo_robots', function ($robots) {
    if (is_author() || is_date()) {
        return 'noindex,follow';
    }

    return $robots;
});

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

2. Закройте страницы с параметрами, которые не должны индексироваться

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

Пример для параметров orderby, filter и UTM-меток:

add_filter('wp_robots', function (array $robots) {
    $query = $_GET;

    $has_tracking_params = false;
    foreach (array_keys($query) as $key) {
        if (str_starts_with($key, 'utm_')) {
            $has_tracking_params = true;
            break;
        }
    }

    if (isset($_GET['orderby']) || isset($_GET['filter']) || $has_tracking_params) {
        $robots['noindex'] = true;
        $robots['follow'] = true;
    }

    return $robots;
});

Этот пример не запрещает обход страницы, но просит поисковик не индексировать её. Для сортировок и маркетинговых параметров это обычно безопаснее, чем блокировать всё через robots.txt.

3. Настройте canonical для страниц, где контент одинаковый

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

Проверять canonical нужно не только в SEO-плагине, но и в теме. Иногда шаблон выводит свой canonical вручную, а плагин — свой. В результате в HTML появляется конфликт или дублирующий тег.

Подход	Когда подходит	Минус
Плагин SEO	Большинство сайтов	Меньше гибкости для нестандартных условий
Код в теме/плагине	Точечные правила для архивов и параметров	Нужно следить за совместимостью
Robots.txt	Только ограничить обход	Не решает проблему индексации дубля

Если дубли создаёт тема или плагин

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

Проверка шаблона и хуков

Посмотрите, не подключён ли в header.php или через wp_head лишний canonical, robots meta или alternate URL. Также проверьте, не создаёт ли плагин собственные архивы или endpoints. Если вы используете кастомные таксономии, убедитесь, что у них корректно настроены public, publicly_queryable и rewrite.

Для таксономии, которая нужна только для внутренней фильтрации и не должна жить как отдельный SEO-объект, настройка может выглядеть так:

register_taxonomy('catalog_filter', array('post'), array(
    'label'             => 'Фильтр каталога',
    'public'            => false,
    'publicly_queryable' => false,
    'show_ui'           => true,
    'rewrite'           => false,
    'show_in_rest'      => true,
));

Такой вариант не создаёт публичные URL для таксономии, но оставляет её доступной в админке и REST, если это нужно редакторам или блоку в Gutenberg.

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

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

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

Полезно сравнить исходный HTML до и после. Если у вас есть staging, сделайте это там, а не на боевом сайте. Для массовых изменений удобнее сначала проверить несколько типовых страниц: главную архивную, страницу с параметром сортировки, архив автора и одну запись с UTM в URL.

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

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

Это частая ошибка: URL перестаёт обходиться, но уже попавшие в индекс страницы могут там остаться. Для дублей важнее canonical и noindex, а robots.txt нужен только там, где действительно надо ограничить обход.

Поставили noindex на полезные архивы

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

Оставили конфликтующие canonical

Иногда canonical выводит SEO-плагин, а тема — свой. В итоге поисковик получает два сигнала и может выбрать не тот URL. Проверьте шаблон header.php, функции в functions.php и подключённые плагины оптимизации.

Закрыли параметры, но не убрали внутренние ссылки на них

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

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

Не добавляйте слишком много логики в wp_head, если можно решить задачу на уровне фильтра SEO-плагина или отдельного мини-плагина. Так проще обновлять тему и меньше риск сломать разметку при апдейте.

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

<?php
/**
 * Plugin Name: Site Robots Rules
 */

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

    return $robots;
});

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

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

проверены URL с параметрами сортировки, фильтров и UTM;
у архивов автора и даты определён статус: оставить, закрыть или удалить из индекса;
canonical указывает на одну основную версию;
нет конфликтующих meta robots из темы и плагина;
внутренние ссылки не ведут массово на дубль-URL;
после правок протестированы несколько страниц в исходном коде и Search Console.

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