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

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

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

Что именно считать дублем и где его искать

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

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

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

Как быстро проверить проблему

Начните не с кода, а с диагностики. Откройте несколько URL из поисковой выдачи и сравните:

совпадает ли основной контент;
какой URL указан в <link rel="canonical">;
есть ли редирект на один адрес при открытии альтернативной версии;
не индексируются ли технические страницы: поиск, авторы, теги без смысла, параметры сортировки.

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

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

Здесь важно не смешивать инструменты. 301 — это перенос на другой URL. canonical — подсказка поисковику, какая версия основная. noindex — запрет на индексацию, но не на обход. Выбор зависит от сценария.

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

Пошаговое решение для WordPress

Шаг 1. Нормализуйте основной адрес сайта

Сначала убедитесь, что WordPress и сервер отдают один и тот же домен и протокол. В Настройки → Общие проверьте Адрес WordPress (URL) и Адрес сайта (URL). Они должны совпадать по схеме и домену.

Если нужен принудительный редирект на HTTPS и без www, это лучше делать на уровне сервера или через .htaccess, а не в шаблоне темы.

RewriteEngine On
RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} ^www\.example\.ru$ [NC]
RewriteRule ^ https://example.ru%{REQUEST_URI} [L,R=301]

Для Nginx логика та же, но правило пишется в конфиге виртуального хоста. Если доступ к серверу есть, это предпочтительнее, чем городить редиректы в PHP.

Шаг 2. Закройте технические архивы от индексации

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

add_action('wp_head', function () {
    if (is_author() || is_date() || is_search()) {
        echo '<meta name="robots" content="noindex,follow" />' . "\n";
    }
});

Этот вариант простой, но у него есть минус: если тема или SEO-плагин уже выводит robots meta, можно получить дублирующий тег. Поэтому перед внедрением проверьте исходный код страницы.

Шаг 3. Укажите canonical для страниц с параметрами

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

add_filter('wpseo_canonical', function ($canonical) {
    if (is_singular()) {
        return remove_query_arg(array('utm_source', 'utm_medium', 'utm_campaign', 'sort', 'filter'));
    }
    return $canonical;
});

Этот пример относится к Yoast SEO, потому что фильтр wpseo_canonical существует именно там. Если у вас другой SEO-плагин, ищите его собственный фильтр или настраивайте canonical через шаблон темы.

Если не используете SEO-плагин, WordPress сам выводит canonical для записей и страниц через rel_canonical(). Вмешиваться в это стоит только если вы точно понимаете, какой URL должен быть основным.

Шаг 4. Уберите дубли архивов и таксономий

Частая ошибка — открытые теги, которые повторяют категории почти один в один. Если тег не несет отдельной навигационной ценности, его лучше либо не индексировать, либо вообще не использовать как SEO-страницу.

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

категории оставляем как основные архивы;
теги — только если они реально помогают навигации;
тонкие архивы с 1–2 записями закрываем от индексации;
страницы поиска не индексируем.

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

Когда лучше редирект, а когда canonical

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

Например, если у вас есть старая статья по адресу /blog/old-post/, а вы перенесли ее в /articles/new-post/, делайте 301. Если же у товара или записи есть версия с параметром ?sort=popular, редиректить ее на базовую страницу часто нельзя — пользователь потеряет контекст. Здесь лучше canonical.

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

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

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

Для быстрой проверки можно использовать curl:

curl -I https://example.ru/page/
curl -I https://www.example.ru/page/

В первом случае вы должны увидеть 200 на основной странице. Во втором — 301 на канонический адрес, если именно так настроена схема редиректов.

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

Делают и редирект, и canonical одновременно без логики

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

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

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

Оставляют дубли с параметрами

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

Путают canonical и 301

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

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

основной домен и протокол заданы одинаково в WordPress и на сервере;
старые URL отдают 301, а не 200;
на страницах с параметрами canonical указывает на чистый адрес;
поиск, авторы и даты закрыты от индексации, если они не нужны в выдаче;
в исходном коде нет двух canonical или конфликтующих robots meta;
в Search Console не растет количество странных URL с параметрами.

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

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

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

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

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