Если в Search Console начинают всплывать странные URL с параметрами, а в исходнике страницы одновременно есть несколько rel="canonical", проблема обычно не в поисковике, а в связке темы, SEO-плагина и кода в functions.php. На практике это приводит к двум типовым сценариям: поисковик выбирает не тот канонический адрес или страница получает лишние редиректы, которые мешают обходу и замедляют загрузку.
Ниже разберём рабочий порядок: как найти источник дублей, как убрать конфликт canonical, как проверить редиректы и что делать, если проблема появляется только на части страниц — например, в категориях, пагинации или на URL с UTM-параметрами.
Как понять, что проблема именно в canonical и редиректах
Сначала стоит отделить технический дубль от обычной индексационной ошибки. Если страница открывается по нескольким адресам, но в HTML есть один canonical и один 301-редирект на основной URL, это нормальная схема. Проблема начинается, когда:
- в коде страницы есть два и более тега
rel="canonical"; - canonical указывает на URL с параметрами, а не на чистый адрес;
- страница редиректит несколько раз подряд;
- SEO-плагин и тема одновременно выводят canonical;
- редирект с http на https, с www на без www и с косой чертой на конце работает не в одном месте, а в нескольких слоях.
Что проверить в первую очередь
Откройте проблемную страницу и посмотрите исходный код. Важно не просто увидеть canonical, а понять, сколько их и кто их добавил. Если у вас есть доступ к серверу, полезно сразу проверить цепочку редиректов через curl.
curl -I https://example.com/page/?utm_source=testВ ответе смотрите на статус, заголовок Location и количество переходов. Если сначала идёт редирект на URL с параметрами, а потом ещё один на чистый адрес, это уже лишняя цепочка.
Откуда берутся дубли canonical в WordPress
Самая частая причина — одновременно активны SEO-плагин и кастомный код в теме. Например, плагин уже выводит canonical через wp_head, а разработчик добавил свой вариант в шаблон header.php. Вторая распространённая ситуация — плагин кеша или оптимизации не виноват напрямую, но он отдаёт старую версию страницы, где canonical уже устарел.
Ещё один источник проблемы — фильтры, которые меняют URL на лету. Если в теме есть код, который подменяет permalink, canonical может остаться старым. Тогда поисковик видит несоответствие между фактическим адресом и каноническим.
Типовые места, где искать код
header.phpтемы;functions.phpдочерней темы;- SEO-плагин: настройки canonical, редиректов и архивов;
- кастомный плагин сайта;
- хуки
wp_head,template_redirect,redirect_canonical.
Пошаговое решение без ломки SEO
Лучше идти от простого к сложному: сначала убрать дублирующий вывод canonical, затем проверить редиректы, потом — исключить конфликт с параметрами URL.
Шаг 1. Оставьте один источник canonical
Если SEO-плагин уже формирует canonical, не добавляйте его вручную в шаблон. В большинстве случаев это правильный вариант. Если же нужен свой canonical для конкретного типа страниц, отключайте стандартный вывод точечно, а не глобально.
add_action('wp', function () {
if (is_singular('post')) {
remove_action('wp_head', 'rel_canonical');
}
});Этот пример уместен только тогда, когда вы действительно хотите заменить стандартный canonical своим. Если задача — просто убрать дубль в теме, удалите лишний <link rel="canonical"> из шаблона и не трогайте ядро WordPress.
Шаг 2. Проверьте, не добавляет ли тема свой canonical
В header.php иногда встречается ручная вставка вроде:
<link rel="canonical" href="<?php echo esc_url( get_permalink() ); ?>" />Если SEO-плагин уже активен, такой код почти всегда лишний. Оставляйте его только в случае, когда сайт без SEO-плагина и вы осознанно берёте canonical на себя.
Шаг 3. Уберите лишние редиректы
WordPress сам умеет нормализовать часть URL через redirect_canonical(). Но если поверх этого стоит ещё и серверный редирект в .htaccess или настройка в плагине, цепочка может удлиниться. Проверьте, чтобы один и тот же переход не выполнялся в двух местах.
Пример безопасного серверного редиректа на один основной вариант домена:
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
RewriteRule ^(.*)$ https://example.com/$1 [L,R=301]Если это уже сделано на уровне хостинга или CDN, не дублируйте правило в WordPress-плагине.
Шаг 4. Исключите параметры, которые не должны менять canonical
UTM-метки, ?replytocom=, сортировка и фильтры часто создают URL, которые не должны становиться отдельными страницами. Для таких случаев canonical должен вести на чистый адрес без параметров. Если параметр нужен только для аналитики, он не должен влиять на индексацию.
Когда нужна точечная правка, можно использовать фильтр wpseo_canonical в Yoast SEO или аналогичный механизм вашего SEO-плагина. Ниже пример для чистого WordPress без привязки к конкретному плагину: меняем canonical только для URL с UTM-параметрами.
add_filter('get_canonical_url', function ($canonical, $post) {
if (empty($_GET['utm_source']) && empty($_GET['utm_medium']) && empty($_GET['utm_campaign'])) {
return $canonical;
}
return remove_query_arg(
array('utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content'),
$canonical
);
}, 10, 2);Этот код стоит применять осторожно и только после проверки, что ваш SEO-плагин не делает то же самое сам. Иначе получите второй конфликт.
Сравнение подходов: плагин, код или сервер
| Подход | Когда подходит | Минус |
|---|---|---|
| Настройки SEO-плагина | Если проблема только в canonical или архивных страницах | Не решает конфликт с темой, если там уже есть свой код |
| Код в дочерней теме или мини-плагине | Если нужен точечный контроль над отдельными типами страниц | Легко сломать при обновлении, если править не в дочерней теме |
| Редирект на сервере | Если нужно жёстко нормализовать домен, www, http/https | Можно создать цепочку редиректов, если WordPress делает то же самое |
Проверка результата после внедрения
После правок не ограничивайтесь открытием страницы в браузере. Проверьте три вещи: исходный HTML, цепочку редиректов и видимость URL в поисковой системе.
- В исходнике должен быть один canonical.
curl -Iдолжен показывать один понятный редирект или вообще его отсутствие, если URL уже канонический.- В Search Console нужно отправить на переобход проблемные страницы и посмотреть, не меняется ли выбранный Google canonical.
Если используете кэш-плагин, очистите кэш после правок и проверьте страницу в режиме инкогнито. Иначе можно увидеть старую версию и решить, что исправление не сработало.
Частые ошибки и как их исправить
Два canonical из-за темы и SEO-плагина
Решение простое: оставьте один источник. Обычно это SEO-плагин. Уберите ручной тег из header.php или отключите стандартный вывод через хук, если у вас есть замена.
Редирект на URL с параметрами
Такое часто происходит, если редирект написан слишком широко и не исключает query string. Проверьте правила в .htaccess, настройках CDN и в плагинах редиректов.
Canonical меняется только на части страниц
Обычно виноваты шаблоны архивов, пагинация или кастомные типы записей. Проверьте, не переопределяется ли canonical в шаблоне архива и не влияет ли на него фильтр в теме.
После очистки кэша проблема возвращается
Это признак того, что источник дублирования не убран, а только скрыт. Сначала исправьте код, потом чистите кэш. Иначе ошибка будет появляться снова после очередной генерации страницы.
Что делать, если сайт уже в индексе с дублями
Если поисковик уже выбрал неправильный canonical, не пытайтесь резко закрывать страницы от индексации. Сначала приведите в порядок адреса, затем дождитесь переобхода. Для старых дублей можно ускорить процесс через обновление sitemap и повторную отправку важных URL в Search Console.
Если проблема массовая и связана с дублями служебных страниц, иногда помогает аудит на уровне сайта: убрать лишние архивы, закрыть технические страницы от индексации и проверить, не создаёт ли плагин SEO лишние URL. Для этого удобно использовать инструменты, которые умеют чистить дубли и служебные настройки, например Clearfy Pro: https://wpshop.ru/plugins/clearfy.
Мини-чек-лист перед публикацией правок
- Один canonical на странице, без дублей в исходнике.
- Нет ручного canonical в теме, если его уже выводит SEO-плагин.
- Редиректов не больше одного на канонический URL.
- UTM и другие параметры не меняют основной адрес страницы.
- Кэш очищен, а проверка сделана в инкогнито и через
curl. - Проблемные URL отправлены на переобход в Search Console.
Если после всех правок canonical всё ещё прыгает между несколькими адресами, почти всегда проблема не в WordPress как таковом, а в конфликте между темой, SEO-плагином и серверными правилами. В таком случае быстрее всего помогает временное отключение по одному слою: сначала тема, затем плагины редиректов, затем кэш, и только после этого — проверка на чистой конфигурации.