Если в поиске вместо нужной страницы появляется другая версия URL, а в исходном коде у них разные или странные rel="canonical", проблема обычно не в индексации как таковой, а в том, как WordPress, тема и SEO-плагин собирают канонический адрес. Это особенно заметно на страницах с параметрами, пагинацией, архивами, сортировками и у записей, у которых есть несколько путей доступа.
Ниже разберём, как быстро понять источник ошибки, где именно править canonical и как проверить, что после изменений поисковик увидит нужную страницу, а не её дубль.
Когда canonical в WordPress ломается на практике
Типичный сценарий выглядит так: у страницы есть основной URL, но в коде выводится canonical на архив, на главную, на URL с параметром ?amp, ?replytocom или на старую версию после переезда. Иногда canonical вообще отсутствует, потому что тема переопределила вывод head, а иногда его подменяет SEO-плагин или фильтр в коде.
Проверять нужно не только записи. Ошибка часто всплывает на:
- страницах пагинации;
- архивах рубрик и меток;
- страницах поиска;
- URL с UTM-метками и сортировками;
- страницах, которые отдают несколько версий из-за плагинов кэша, AMP или мультиязычности.
Диагностика проблемы
Сначала откройте проблемную страницу и посмотрите исходный код. Ищите строку вида <link rel="canonical" href="..." />. Если canonical указывает не на текущий URL, нужно понять, кто его печатает: ядро WordPress, SEO-плагин или тема.
Полезно проверить ещё три вещи:
- нет ли в коде второй canonical;
- не меняется ли canonical только на страницах с параметрами;
- не отличается ли адрес в canonical от фактического URL после редиректов.
Если есть доступ к WP-CLI, можно быстро найти плагины, которые часто вмешиваются в head:
wp plugin list --status=activeДальше смотрите, установлен ли SEO-плагин, и не дублирует ли тема его функции. Два canonical на одной странице — частая причина того, что поисковик игнорирует оба.
Как исправить canonical без лишних правок
Лучший путь — не править шаблоны вручную, если это можно сделать через фильтр. В WordPress для canonical есть фильтр get_canonical_url. Он позволяет подменить адрес только там, где это действительно нужно.
Например, если на странице записи canonical должен всегда указывать на чистый URL без параметров, можно добавить такой код в дочернюю тему или в собственный мини-плагин:
<?php
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 );Если проблема возникает на архиве рубрики, логика будет другой. Там canonical должен вести на сам архив, а не на первую запись или на URL с параметрами сортировки. В таких случаях лучше не трогать ядро, а убрать лишний вывод canonical из темы или конфликтующего плагина.
Когда canonical выводит SEO-плагин
Если используется SEO-плагин, сначала проверьте его настройки для архивов, пагинации и страниц с параметрами. Иногда canonical меняется из-за автоматических правил, которые включены по умолчанию. В этом случае кодом лучше исправлять только точечные исключения, а не всю логику.
Если нужно убрать лишний canonical, который печатает тема, ищите в шаблоне header.php или подключаемых файлах вызовы, связанные с wp_head() и ручным выводом meta-тегов. Дубли чаще всего появляются, когда разработчик темы добавил собственный canonical «на всякий случай», не проверив, что SEO-плагин уже делает это сам.
Сравнение подходов: плагин, код или правка темы
| Подход | Когда уместен | Плюсы | Минусы |
|---|---|---|---|
| Настройки SEO-плагина | Если canonical ломается на архивах, пагинации, параметрах | Быстро, без кода | Не решает точечные исключения |
Фильтр get_canonical_url | Если нужна точечная логика для отдельных типов страниц | Гибко и безопаснее правки шаблона | Нужно аккуратно тестировать условия |
| Правка темы | Если тема сама печатает лишний canonical | Можно убрать источник конфликта | Есть риск сломать обновления и head-разметку |
Проверка результата после внедрения
После правки не ограничивайтесь визуальной проверкой страницы. Откройте исходный код и убедитесь, что:
- canonical один;
- он указывает на нужный URL без лишних параметров;
- на страницах пагинации и архивов адрес соответствует логике сайта;
- после очистки кэша canonical не меняется обратно.
Если сайт использует серверный или плагинный кэш, очистите его обязательно. Иначе вы будете смотреть старый HTML и решите, что правка не сработала. Для проверки также полезно открыть страницу в режиме инкогнито и сравнить исходник с тем, что отдает кэш.
Дополнительно можно проверить заголовки и редиректы через консоль:
curl -I https://example.com/stranitsa/
Если URL сначала редиректит, а canonical указывает на другой адрес, поисковик может считать это сигналом о неканонической версии. В таком случае сначала приводят в порядок редирект, а уже потом canonical.
Частые ошибки и как их исправить
Два canonical на одной странице
Обычно это конфликт темы и SEO-плагина. Оставьте один источник вывода. Если canonical печатается вручную в шаблоне, удалите этот код и проверьте, что wp_head() остаётся на месте.
Canonical указывает на URL с параметрами
Такое часто происходит из-за неправильной логики в фильтре или из-за плагина, который считает параметры частью основной страницы. Для канонического адреса используйте чистый permalink, а параметры оставляйте только там, где они действительно меняют контент.
Canonical не меняется после правки
Причина обычно в кэше, но иногда — в том, что фильтр не срабатывает из-за неверного условия. Проверьте, что код подключён в активной теме или плагине, и временно упростите условие до минимального, чтобы убедиться, что сам фильтр работает.
На архиве canonical ведёт на первую запись
Это признак сломанной темы или кастомной логики в SEO-плагине. Для архивов canonical должен указывать на сам архивный URL, а не на контент внутри него.
Чек-лист перед публикацией изменений
- Проверен исходный код страницы.
- Убраны дублирующие canonical-теги.
- Сравнены URL до и после редиректа.
- Очищен кэш сайта и CDN, если он есть.
- Проверены архивы, пагинация и страницы с параметрами.
- Тест выполнен в инкогнито и без авторизации.
Практические советы по безопасности и производительности
Не правьте canonical через случайные вставки в functions.php на боевом сайте без резервной копии. Если тема обновится, правка может исчезнуть. Для точечных изменений лучше использовать дочернюю тему или небольшой собственный плагин.
Если на сайте много дублей из-за параметров, не пытайтесь закрыть всё одним универсальным правилом. Сначала определите, какие параметры реально меняют контент, а какие нет. Иначе можно случайно сломать сортировки, фильтры и страницы поиска.
Если нужен более широкий технический аудит дублей, мета-тегов и индексации, удобнее сначала собрать базовую чистку сайта и SEO-правила в одном месте. В этом сценарии часто помогает Clearfy Pro: https://wpshop.ru/plugins/clearfy?utm_source=wphelper.ru&utm_medium=article&utm_campaign=kak-nayti-i-ispravit-canonical-v-wordpress. Но даже с плагином всё равно стоит проверить исходный HTML вручную — именно там видно, что реально отдает сайт.
Когда canonical исправлен, поисковик не обязан мгновенно переоценить страницу. Но если адрес в коде стал корректным, дубли и неверные сигналы для индексации обычно перестают накапливаться дальше.