Как найти и убрать дубли canonical в WordPress

Автор: Наталья Боброва | Опубликовано: 01.09.2026

Дубли rel="canonical" в WordPress обычно появляются не из-за одной ошибки, а из-за наложения нескольких источников: тема выводит тег сама, SEO-плагин добавляет свой, а кастомный код или фильтр меняет URL еще раз. В результате поисковик видит несколько канонических адресов на одной странице и может игнорировать часть сигналов.

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

Когда проблема действительно в дублирующемся canonical

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

Типичные признаки

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

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

Сначала проверьте сам HTML, а не настройки на глаз. Откройте страницу и найдите все вхождения rel="canonical". Если их больше одного, дальше нужно понять, кто именно их выводит: тема, плагин или пользовательский код.

<!-- Простой способ проверить исходник через браузер -->
Ctrl+U

<!-- Или через консоль -->
Array.from(document.querySelectorAll('link[rel="canonical"]')).map(el => el.href)

Если у вас есть доступ к серверу, удобно проверить заголовки и HTML через curl. Это полезно, когда проблема проявляется только на части шаблонов.

curl -s https://example.com/page/ | grep -i canonical

Дальше проверьте три места:

настройки SEO-плагина;
функции темы в functions.php и файлы шаблонов;
кастомные плагины, mu-plugins и сниппеты в Code Snippets или аналогах.

Если canonical выводится и в wp_head, и вручную в шаблоне, это почти наверняка и есть причина дубля.

Пошаговое решение без правки ядра

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

Шаг 1. Найдите ручной вывод canonical в теме

Проверьте header.php, single.php, page.php и кастомные шаблоны. Ищите строки вида:

<link rel="canonical" href="<?php echo esc_url( get_permalink() ); ?>" />

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

Шаг 2. Если нужен свой canonical, выводите его через фильтр

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

Ниже пример для WordPress без привязки к конкретному SEO-плагину: мы меняем canonical только для нужного шаблона и не трогаем остальные страницы.

add_filter( 'get_canonical_url', function( $canonical, $post ) {
    if ( is_admin() || ! $post instanceof WP_Post ) {
        return $canonical;
    }

    // Пример: для конкретной записи задаем свой canonical.
    if ( $post->ID === 123 ) {
        return home_url( '/special-page/' );
    }

    return $canonical;
}, 10, 2 );

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

Шаг 3. Уберите конфликтующий вывод из темы

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

remove_action( 'wp_head', 'rel_canonical' );

Этот вариант подходит только для стандартного canonical WordPress. Если его добавляет SEO-плагин, у него будет свой способ отключения или фильтр. Не пытайтесь глушить все подряд в wp_head — так легко сломать другие важные мета-теги.

Что делать, если canonical конфликтует с SEO-плагином

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

Подход	Когда подходит	Минус
Оставить canonical в SEO-плагине	Обычные записи, страницы, архивы	Нужно убрать ручной вывод из темы
Задать canonical через код	Нестандартные шаблоны, фильтры, спецстраницы	Требует аккуратной поддержки при обновлениях
Выводить canonical и в теме, и в плагине	Никогда	Дубли и непредсказуемое поведение

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

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

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

Откройте исходный код и найдите rel="canonical".
Проверьте, что тег один.
Сравните href с фактическим адресом страницы.
Проверьте несколько типов страниц: запись, страница, рубрика, пагинация.
Если есть Search Console, отправьте URL на повторную проверку после индексации.

Для быстрой проверки можно использовать такой PHP-фрагмент в временном файле или через WP-CLI shell, если он у вас настроен:

$html = file_get_contents( 'https://example.com/page/' );
preg_match_all( '/<link[^>]+rel=["\']canonical["\'][^>]+href=["\']([^"\']+)["\']/i', $html, $matches );
print_r( $matches[1] );

Если массив пустой — canonical не выводится. Если элементов больше одного — конфликт остался.

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

Оставили canonical в шаблоне и в плагине

Это самая частая причина. Решение простое: уберите ручной тег из темы или отключите соответствующую опцию в плагине. Не оставляйте оба варианта «на всякий случай».

Поменяли домен, но canonical остался старым

После миграции на HTTPS или смены www canonical может продолжать указывать на старый формат URL. Проверьте настройки home и siteurl, а также кэш страницы и CDN.

Canonical на пагинации указывает не туда

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

Кэш показывает старый HTML

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

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

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

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

И еще один момент: не отключайте все SEO-мета-теги ради борьбы с дублем canonical. Часто достаточно убрать один лишний вывод и оставить остальную разметку нетронутой.