Ситуация типичная: страница открывается по одному URL, а в исходном коде указан canonical на другой адрес, иногда даже на несуществующую или старую версию. Для поисковика это сигнал, что у страницы есть «основной» адрес, но если canonical дублируются или противоречат друг другу, индексация начинает вести себя непредсказуемо. На практике это проявляется в том, что нужная страница не закрепляется в выдаче, а в индекс попадает не тот вариант URL.
Проблема часто возникает после миграции сайта, смены SEO-плагина, правок шаблона темы или при смешении логики из нескольких источников: тема выводит свой canonical, SEO-плагин добавляет второй, а кастомный код — третий. Ниже разберём, как быстро диагностировать конфликт и привести разметку к одному источнику правды.
Как понять, что canonical конфликтует
Сначала не трогаем код, а проверяем симптомы. Если на странице несколько тегов rel="canonical", это уже ошибка. Если canonical указывает на главную, на категорию вместо статьи или на URL с параметрами, нужно искать источник генерации. Ещё один признак — в Google Search Console страница помечается как дубликат, хотя контент у неё уникальный.
Что проверить вручную
- откройте исходный код страницы и найдите все вхождения
rel="canonical"; - сравните canonical с фактическим URL страницы;
- проверьте, не меняется ли canonical на страницах пагинации, архивов и записей с параметрами;
- посмотрите, не добавляет ли canonical тема, SEO-плагин и кастомный
functions.phpодновременно.
Если у вас есть доступ к консоли, удобно быстро проверить заголовок страницы и HTML без браузерных расширений:
curl -L https://example.com/page/ | grep -i canonicalДля более точной проверки можно выгрузить HTML и посмотреть, сколько canonical реально выводится:
curl -L https://example.com/page/ -o page.html
grep -i "rel=\"canonical\"" page.htmlОткуда берутся дубли canonical
В WordPress canonical может появиться из нескольких мест. Самый частый источник — SEO-плагин. Второй по частоте — тема, в которой разработчик вручную добавил wp_head-логику или старый код из до-плагинной эпохи. Третий вариант — кастомный фильтр, который меняет canonical только для части URL, но не учитывает архивы, пагинацию и вложенные страницы.
| Подход | Что делает | Риск |
|---|---|---|
| Плагин SEO | Генерирует canonical автоматически | Конфликтует с темой или кастомным кодом |
| Код в теме | Даёт полный контроль | Легко забыть удалить старую реализацию |
| Смешанный вариант | Несколько источников одновременно | Почти всегда приводит к дублям |
Если сайт уже использует SEO-плагин, обычно лучше оставить один источник canonical и убрать остальные. Не стоит «подправлять» разметку поверх чужой логики, если можно отключить лишний вывод на уровне темы или фильтра.
Пошаговое решение без потери индексации
Ниже безопасный порядок работ. Он подходит для большинства сайтов, где canonical дублируется из-за темы или кастомного кода.
1. Найдите источник лишнего canonical
Проверьте header.php, functions.php, подключаемые файлы темы и mu-plugins. Ищите не только строку canonical, но и прямой вывод в wp_head. Иногда разработчик вставляет готовый тег вручную, не используя фильтры WordPress.
2. Оставьте один механизм генерации
Если canonical должен формировать SEO-плагин, удалите ручной вывод из темы. Если нужен кастомный canonical, отключите стандартный вывод и подключите свой через фильтр wpseo_canonical у Yoast SEO или через соответствующий механизм вашего плагина. Для сайтов без SEO-плагина можно использовать фильтр WordPress get_canonical_url, но только если вы понимаете, какие типы страниц он затронет.
Пример: убрать ручной canonical из темы и оставить генерацию WordPress/SEO-плагина. Если в теме есть прямой вывод в wp_head, его нужно удалить или закомментировать. Если доступ к теме ограничен, безопаснее сделать это в дочерней теме.
// Пример: отключаем лишний вывод canonical, если он добавлен темой вручную.
remove_action('wp_head', 'theme_custom_canonical_output', 10);Имя функции в примере условное: в реальном коде нужно удалить именно ту callback-функцию, которую использует ваша тема. Это не универсальная команда, а шаблон для проверки структуры проекта.
3. Настройте canonical для нестандартных страниц
Если у вас есть фильтры, которые меняют canonical для отдельных типов записей, проверьте логику на пагинации, архивных страницах и URL с параметрами. Частая ошибка — принудительно ставить canonical на первую страницу архива, из-за чего поисковик теряет связь между страницами пагинации.
Пример кастомной логики для записи, где canonical должен указывать на текущий URL без параметров:
add_filter('get_canonical_url', function ($canonical, $post) {
if (! $post instanceof WP_Post) {
return $canonical;
}
if (is_singular('post')) {
return get_permalink($post);
}
return $canonical;
}, 10, 2);Этот вариант подходит только если вы понимаете, что именно возвращает ваш сайт для записи и не ломаете логику плагина SEO. На сайтах с Yoast SEO или Rank Math сначала проверьте их собственные настройки canonical, а уже потом добавляйте фильтры.
Как проверить результат после правки
После изменений не ограничивайтесь визуальной проверкой в браузере. Нужно убедиться, что на странице остался один canonical и он указывает на правильный адрес.
- откройте страницу в режиме просмотра исходного кода;
- найдите
rel="canonical"и проверьте, что тег один; - сравните canonical с фактическим URL без UTM и других параметров;
- проверьте несколько типов страниц: запись, рубрика, архив, пагинация;
- посмотрите, не меняется ли canonical после очистки кеша.
Если сайт под кеширующим плагином или серверным кешем, обязательно очистите кеш страницы и объектный кеш. Иначе вы можете проверять старую версию HTML и думать, что правка не сработала.
Частые ошибки и как их исправить
Оставили два источника canonical
Это самая частая причина. Например, SEO-плагин уже выводит canonical, а тема добавляет второй тег в wp_head. Решение простое: оставьте только один источник и удалите второй.
Ставят canonical на главную для всех страниц
Так делают, когда пытаются «склеить» дубли вручную. В результате поисковик начинает считать все страницы копиями главной. Canonical должен указывать на эквивалентную страницу, а не на любую удобную.
Не учитывают параметры URL
Если canonical формируется из текущего адреса без очистки параметров, в индекс могут попасть URL с ?utm_, ?replytocom и другими хвостами. Для таких случаев canonical должен вести на чистый основной адрес.
Правят шаблон, но не проверяют архивы
На записи всё выглядит нормально, а на рубриках и пагинации остаётся старая логика. Проверяйте не только один URL, а весь набор шаблонов, где выводится canonical.
Что делать, если canonical нужен только для части сайта
Иногда проблема не в дубле, а в том, что canonical должен отличаться для отдельных типов контента. Например, для лендингов, страниц фильтрации или технических архивов. В таком случае не отключайте canonical полностью — настройте условную логику через фильтр и ограничьте её конкретными шаблонами.
Если задача выходит за рамки темы и требует регулярной чистки дублей, полезно держать под рукой инструменты для технической оптимизации. В экосистеме WPShop для таких задач может пригодиться Clearfy Pro, если вам нужно централизованно управлять SEO- и техническими настройками без разрозненных правок в теме: https://wpshop.ru/plugins/clearfy.
Но даже с плагином принцип остаётся тем же: один canonical на страницу, понятная логика генерации и обязательная проверка после правок. Если это не соблюсти, проблема просто переедет из темы в плагин.