Как убрать дубли из архивов товаров и записей в WordPress

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

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

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

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

Типовые источники дублей

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

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

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

Не стоит сразу ставить noindex на всё подряд. Сначала проверьте, какие URL реально попадают в поиск и чем они отличаются.

1. Откройте Google Search Console и посмотрите разделы с исключёнными страницами и дублирующимися каноническими URL.
2. Сравните заголовки и метаописания у архивов категорий, тегов и страниц пагинации.
3. Проверьте исходный код страниц на наличие rel="canonical".
4. Посмотрите, не индексируются ли страницы поиска и URL с параметрами.
5. Если используете SEO-плагин, проверьте, не конфликтует ли его каноникал с тем, что выводит тема.

Удобный способ быстро увидеть проблему — открыть несколько похожих URL и сравнить HTML-вывод. Если title, description и основной блок почти одинаковые, поисковик тоже увидит их как дубли.

Что делать: рабочая схема без лишних рисков

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

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

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

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

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

    if (is_author()) {
        $robots['noindex'] = true;
    }

    return $robots;
});

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

2. Настроить канонический URL на страницах пагинации

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

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

<?php
add_filter('get_canonical_url', function ($canonical, $post) {
    if (is_home() || is_archive()) {
        return $canonical;
    }

    return $canonical;
}, 10, 2);

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

3. Сократить количество архивов, которые повторяют один и тот же контент

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

Практический подход:

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

Если нужно закрыть теги от индексации через код, можно сделать это точечно:

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

    return $robots;
});

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

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

Проверьте, чтобы:

• внутренние ссылки вели на один основной URL;
• в шаблонах не было лишних ссылок на архивы с параметрами;
• хлебные крошки не создавали цепочки на технические страницы;
• в sitemap не попадали закрытые архивы.

Сравнение подходов: плагин, код или шаблон

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

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

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

• Откройте исходный код и убедитесь, что на нужных страницах есть noindex или корректный canonical.
• Проверьте, что закрытые архивы не попали в XML-карту сайта.
• Сравните title и description у похожих архивов — они не должны быть одинаковыми без причины.
• Посмотрите в Search Console, ушли ли страницы из отчётов о дублях и исключениях.
• Протестируйте пагинацию: страницы /page/2/ должны открываться без 404 и без случайного редиректа на первую страницу.

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

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

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

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

Дублируют canonical в теме и SEO-плагине

Когда canonical выводится из двух мест, поисковик может получить противоречивые сигналы. Проверьте, кто именно отвечает за мета-теги, и оставьте один источник правды.

Закрывают страницы, но оставляют их в sitemap

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

Не проверяют архивы с параметрами

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

Что стоит учесть для безопасности и производительности

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

Ещё один практический момент: не ставьте тяжёлые плагины ради одной настройки, если задача решается фильтром wp_robots или правкой шаблона. Лишний плагин — это ещё один слой совместимости и ещё одна точка отказа.

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

В итоге рабочая схема обычно выглядит так: найти источник дубля, убрать лишние архивы из индекса, не ломать canonical, проверить sitemap и только потом смотреть на изменения в Search Console. Это скучнее, чем «поставить галочку», но именно так обычно и чинятся реальные проблемы WordPress-сайтов.