Как найти и устранить canonical-ошибки в WordPress

Автор: Марина Егорова | Опубликовано: 29.08.2026

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

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

Когда canonical в WordPress ломается

Типовые симптомы довольно узнаваемы: в выдаче отображается не та версия страницы, в Search Console растёт число «дубликатов, Google выбрал другой canonical», а в исходном коде у разных URL стоит один и тот же адрес канонической страницы или, наоборот, canonical ведёт на несуществующий URL.

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

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

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

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

Начинайте не с кода, а с проверки фактического HTML. Откройте проблемную страницу и посмотрите, какой canonical реально отдан в <head>. Если на странице есть несколько тегов canonical, это уже конфликт: один может добавлять ядро WordPress, второй — SEO-плагин, третий — тема.

Удобно проверить это через консоль:

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

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

неправильной логики в фильтре wpseo_canonical или аналогичном фильтре плагина;
ручного вывода canonical в теме через wp_head;
кэширования старого HTML после исправления;
редиректа на новый адрес без обновления канонического URL;
пагинации, где canonical указывает на первую страницу вместо текущей.

Как исправить canonical в WordPress без лишнего риска

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

Вариант 1. Исправить canonical через фильтр SEO-плагина

Если вы используете Yoast SEO, canonical можно подменить фильтром wpseo_canonical. Это подходит, когда нужно исправить только отдельные типы страниц или конкретные условия.

add_filter( 'wpseo_canonical', function( $canonical ) {
    if ( is_singular( 'post' ) ) {
        $post_id = get_queried_object_id();

        // Пример: для записей из определённой рубрики задаём канонический URL вручную.
        if ( has_category( 'news', $post_id ) ) {
            return home_url( '/news/' );
        }
    }

    return $canonical;
} );

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

Вариант 2. Убрать лишний canonical, если его выводит тема

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

add_action( 'after_setup_theme', function() {
    remove_action( 'wp_head', 'theme_output_canonical', 10 );
} );

Здесь theme_output_canonical — условное имя функции из темы. В реальном проекте нужно найти фактический callback в файлах темы или дочерней темы и убрать именно его.

Вариант 3. Задать canonical для нестандартных шаблонов

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

add_action( 'wp_head', function() {
    if ( is_page_template( 'templates/landing.php' ) ) {
        echo '<link rel="canonical" href="' . esc_url( home_url( '/landing/' ) ) . '" />' . "\n";
    }
}, 1 );

Важно: если вы выводите canonical вручную, убедитесь, что больше нигде он не печатается для этой же страницы.

Сравнение подходов

Подход	Когда подходит	Риск
Фильтр SEO-плагина	Нужно точечно менять canonical для отдельных страниц	Можно сломать логику плагина, если не ограничить условия
Удаление лишнего вывода из темы	Canonical дублируется в `wp_head`	Нужно точно найти источник, иначе можно удалить не то
Ручной canonical в шаблоне	Кастомные посадочные и нестандартные шаблоны	Легко получить дубли, если плагин тоже выводит canonical

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

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

Откройте страницу в режиме инкогнито и проверьте исходный код.
Сделайте curl-проверку и убедитесь, что canonical один.
Очистите серверный и плагинный кэш.
Проверьте страницу в Google Search Console через проверку URL.
Посмотрите, не остались ли старые canonical в sitemap, если он генерируется отдельно.

Если canonical исправлен, но Google всё ещё показывает старый адрес, это не всегда ошибка кода. Поисковику нужно время, чтобы переоценить сигналы, особенно если раньше на странице были дубли и редиректы.

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

Два canonical на одной странице

Это самая частая проблема после установки SEO-плагина поверх темы с самописным <link rel="canonical">. Решение простое: оставьте только один источник.

Canonical ведёт на URL с редиректом

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

Canonical не совпадает с индексируемой версией

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

Кэш не обновился после правки

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

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

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

Для проектов с частыми изменениями URL полезно держать список страниц, где canonical задан вручную. Это упрощает аудит после редизайна и миграции. Если вы используете плагины для технической чистки сайта, например Clearfy Pro, проверяйте, не отключают ли они часть метатегов или не дублируют ли их вывод. Подобные настройки лучше тестировать на staging-окружении, а не на боевом сайте.

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