Как исправить canonical и переадресацию в WordPress без потери индексации

Автор: Диана Ковалева | Опубликовано: 19.08.2026

Если в Search Console одна и та же страница индексируется по разным адресам, а в выдаче всплывают версии с ?utm=, со слешем и без, с www и без него, проблема часто не в «плохом SEO», а в конфликте между canonical, редиректами и настройками самого WordPress. На практике это ломают темы, плагины кеша, SEO-плагины и ручные правила в .htaccess.

Ниже разберём, как найти источник расхождений, что исправить в первую очередь и как проверить, что поисковик видит только один канонический URL.

Когда canonical и редиректы начинают конфликтовать

Типичный сценарий выглядит так: страница открывается по нескольким адресам, но в HTML указан один rel="canonical", а сервер отдаёт другой редирект или вообще не редиректит. В результате бот получает противоречивые сигналы. Это особенно заметно на:

страницах с параметрами сортировки, фильтров и UTM-меток;
архивах рубрик и тегов;
страницах с разными вариантами слеша в конце URL;
адресах с www и без него;
страницах, где SEO-плагин и тема одновременно выводят canonical.

Если проблема проявляется только на части URL, не спешите менять общие настройки. Сначала нужно понять, кто именно подменяет canonical: WordPress, SEO-плагин, тема, серверный редирект или кеш.

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

Проверьте фактический ответ сервера

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

curl -I https://example.com/page/

Смотрите на:

HTTP/1.1 301 или 302;
заголовок Location;
не возникает ли цепочка из нескольких переходов;
совпадает ли конечный URL с тем, который вы считаете каноническим.

Сравните canonical в HTML и в SEO-плагине

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

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

просмотр исходного кода страницы;
инструменты разработчика в браузере;
проверку URL в Google Search Console;
команду curl с фильтрацией по canonical.

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

Проверьте, не генерирует ли WordPress лишние варианты URL

WordPress может сам создавать альтернативные адреса для архивов, вложений, пагинации и вложенных страниц. Если к этому добавляются параметры из фильтров или UTM, появляются десятки URL с одинаковым контентом.

Особенно внимательно смотрите на:

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

Пошаговое решение: привести canonical и редиректы к одному правилу

Шаг 1. Выберите один канонический формат URL

Сначала зафиксируйте правило, а потом подгоняйте под него сайт. Обычно это один из вариантов:

с https;
с www или без него;
со слешем в конце или без него;
без параметров, если они не нужны для индексации.

Это правило должно быть одинаковым для сервера, WordPress и SEO-плагина. Если сервер редиректит на один формат, а canonical указывает на другой, конфликт останется.

Шаг 2. Уберите дублирующий canonical из темы

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

Пример: если в теме есть лишний вывод canonical, его можно убрать через remove_action(), но только если вы точно знаете, где он добавлен.

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

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

Шаг 3. Настройте редирект с параметров на чистый URL

Если UTM-метки и служебные параметры не должны индексироваться, сервер должен отдавать 301 на чистый адрес. Для WordPress это лучше делать аккуратно, чтобы не сломать рабочие страницы с параметрами, которые реально нужны.

Ниже пример для functions.php или небольшого плагина. Он убирает только очевидные маркетинговые параметры и не трогает остальные запросы.

add_action('template_redirect', function () {
    if (is_admin() || wp_doing_ajax()) {
        return;
    }

    $utm_keys = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content'];
    $has_utm = false;

    foreach ($utm_keys as $key) {
        if (isset($_GET[$key])) {
            $has_utm = true;
            break;
        }
    }

    if (!$has_utm) {
        return;
    }

    $clean_url = remove_query_arg($utm_keys);

    if ($clean_url !== home_url(add_query_arg([], $_SERVER['REQUEST_URI']))) {
        wp_safe_redirect($clean_url, 301);
        exit;
    }
});

Важно: не используйте такой редирект для страниц, где параметры реально меняют контент, например для фильтров каталога или поиска по сайту.

Шаг 4. Закройте от индексации технические архивы, которые не нужны

Если у вас есть архивы авторов, тегов или вложений, которые дублируют основной контент, лучше не пытаться «лечить» их только canonical. Иногда правильнее убрать их из индексации или вообще отключить генерацию таких страниц.

Для вложений часто достаточно редиректа на файл или на родительскую запись. Для архивов — настройки SEO-плагина или фильтры темы. Здесь важно не мешать всё в одну корзину: canonical и noindex решают разные задачи.

Сравнение подходов: плагин, код или сервер

Подход	Когда подходит	Плюсы	Минусы
SEO-плагин	Нужно быстро задать canonical и noindex	Удобно, меньше кода	Легко получить конфликт с темой или другим плагином
Код в теме/плагине	Нужна точечная логика для отдельных URL	Контроль над условиями	Нужно тестировать после обновлений
Серверный редирект	Фиксированный формат домена и URL	Быстро и прозрачно для ботов	Ошибки в правилах ломают доступ к сайту

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

После правок не ограничивайтесь открытием страницы в браузере. Проверьте цепочку целиком:

Откройте URL с параметрами и убедитесь, что он отдаёт 301 на чистый адрес.
Проверьте исходный код и убедитесь, что canonical один.
Сравните адрес в адресной строке и canonical в HTML.
Проверьте, нет ли повторного редиректа на уровне кеша или CDN.
В Search Console отправьте проверку URL и посмотрите, какой адрес выбран как канонический.

Если canonical в HTML правильный, но Google всё равно выбирает другой URL, обычно проблема в слабом сигнале: дубли доступны без редиректа, внутренние ссылки ведут на разные версии, а sitemap содержит лишние адреса.

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

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

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

Редирект 302 вместо 301

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

Canonical указывает на URL с параметрами

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

Внутренние ссылки ведут на разные версии

Даже правильный canonical не спасает, если меню, хлебные крошки, блоки похожих записей и sitemap ссылаются на разные варианты URL. Приведите внутренние ссылки к одному формату.

Чек-лист перед публикацией правок

Один формат домена выбран и зафиксирован.
301-редирект с альтернативных URL работает без цепочек.
На странице один canonical, без дублей.
UTM и служебные параметры не индексируются.
Архивы, которые не нужны в поиске, закрыты или удалены из индекса.
В sitemap остались только канонические адреса.
После очистки кеша проверка в браузере и через curl даёт одинаковый результат.

Безопасность и производительность: что не стоит делать

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

Если у вас много технических дублей, иногда полезно сначала убрать их на уровне генерации контента и шаблонов, а уже потом настраивать canonical. В таких задачах помогает аккуратная чистка SEO-обвязки и дублей через инструменты вроде Clearfy Pro, если он уже используется в проекте, но только как часть общей схемы, а не вместо нормальной настройки редиректов и sitemap.