Если на сайте появляются дубли из-за сортировок, фильтров, UTM-меток или нескольких версий одной и той же страницы, canonical помогает подсказать поисковикам основную URL-версию. Но это не универсальная «кнопка от дублей»: в одних случаях canonical действительно нужен, в других он только запутает индексацию или замаскирует проблему, которую лучше решать на уровне структуры сайта.
В WordPress canonical обычно уже выводится автоматически, но на практике этого часто недостаточно. Плагины, темы, фильтры, параметры в URL и нестандартные архивы могут ломать логику. Ниже разберём, где canonical полезен, как его проверить и как настроить вручную для страниц, архивов и URL с параметрами.
Когда canonical нужен, а когда его лучше не трогать
Canonical стоит использовать там, где у одной и той же контентной сущности есть несколько доступных URL, но индексироваться должна только одна основная версия. Классические примеры: страница товара или статьи с UTM-метками, архив с сортировкой по цене или дате, пагинация, фильтры, которые не меняют смысл страницы.
Не стоит ставить canonical на разные страницы, если они реально отличаются по содержанию и должны ранжироваться отдельно. Например, если у вас есть отдельные посадочные страницы под разные запросы, у каждой должен быть свой self-canonical, а не ссылка на «главную» версию. То же относится к страницам категорий, которые отличаются текстом, набором товаров или статей.
Есть ещё важный момент: canonical — это рекомендация для поисковика, а не жёсткая директива. Google может её проигнорировать, если увидит противоречия: разные title, разные внутренние ссылки, несогласованные sitemap или явные признаки того, что страницы не являются дублями.
Что WordPress делает сам и где этого обычно не хватает
В актуальных версиях WordPress в большинстве шаблонов в <head> уже выводится canonical для записей, страниц, архивов и некоторых других типов контента. За это отвечает встроенная функция WordPress, а не только SEO-плагин. Но на практике проблемы возникают в трёх типичных случаях:
- тема не вызывает стандартные функции WordPress в
headили переопределяет вывод; - SEO-плагин добавляет свой canonical поверх встроенного, и в коде появляется два тега;
- URL с параметрами формируются динамически, а canonical остаётся на «грязном» адресе или, наоборот, указывает не туда.
Поэтому начинать стоит не с правки кода, а с проверки фактического HTML. Откройте страницу и посмотрите исходный код: в нём должен быть один тег <link rel="canonical" href="...">. Если их два или больше, сначала нужно убрать дублирование на уровне темы или плагинов.
Как задать canonical для обычной страницы или записи
Для стандартной страницы чаще всего достаточно self-canonical, то есть canonical на саму себя. Это нормальная и ожидаемая схема: страница доступна по одному основному адресу, и он же указан как канонический.
Если вы используете SEO-плагин, canonical обычно задаётся автоматически. Но если нужно явно переопределить его для конкретной страницы, удобнее делать это через метаполе плагина или через фильтр в теме. Вручную править шаблон страницы ради одного URL не стоит: при обновлении темы изменения легко потеряются.
Для кастомной правки в WordPress чаще используют фильтр wpseo_canonical в Yoast SEO или аналогичный механизм в другом SEO-плагине. Но такой подход нужен только тогда, когда стандартный canonical действительно неверный. Например, если одна и та же страница доступна по двум адресам из-за особенностей маршрутизации или старого редиректа, а поисковику нужно показать только один вариант.
Если у вас нет SEO-плагина, а canonical нужен на уровне темы, можно вывести его через wp_head. Делать это стоит только после проверки, что в теме уже нет другого canonical, иначе получите дубли.
Пример для дочерней темы, если нужно добавить canonical вручную на конкретную страницу:
add_action('wp_head', function () {
if (is_page(42)) {
echo '<link rel="canonical" href="' . esc_url('https://example.com/landing/') . '" />' . "\n";
}
}, 1);Здесь 42 — ID страницы. Такой код имеет смысл только как точечное решение. Если canonical нужен для большого числа страниц, лучше искать общую логику в шаблоне или SEO-плагине, а не размножать условия в теме.
Архивы: категории, теги, пагинация и архивы автора
С архивами нужно быть аккуратнее, потому что не все они являются дублями. Категория, тег, архив автора и архив по дате могут выглядеть похоже, но это разные страницы. Canonical здесь нужен не для того, чтобы «склеить всё в одно», а чтобы правильно указать основную версию конкретного архива.
Для первой страницы архива canonical обычно должен вести на сам архив без лишних параметров. Для пагинации ситуация зависит от реализации сайта. Если у вас обычный архив с постраничной навигацией, каждая страница пагинации должна иметь свой canonical на саму себя, а не на первую страницу архива. Иначе поисковик может начать игнорировать страницы 2, 3 и дальше.
Если же архив создаётся только для навигации по каталогу и не несёт самостоятельной ценности, иногда лучше не пытаться «склеить» его canonical-ом, а пересмотреть структуру фильтров, индексацию и внутреннюю перелинковку. Canonical не заменяет нормальную архитектуру архива.
Для архивов автора и даты полезно проверить, не дублируют ли они друг друга или рубрики. Если архив автора пустой или почти пустой, его часто закрывают от индексации, а не лечат canonical-ом. Это разные задачи: canonical указывает предпочтительный URL, а noindex говорит поисковику не индексировать страницу. Не смешивайте их без причины.
Параметры URL: сортировки, фильтры и UTM-метки
Именно здесь canonical чаще всего нужен на практике. Параметры в URL могут менять только способ отображения контента, но не сам контент. Например, ?sort=price, ?filter=red, ?utm_source=... и похожие параметры часто создают технические дубли.
Для UTM-меток canonical почти всегда должен указывать на чистый URL без параметров. Это стандартная и безопасная практика: рекламные и аналитические метки не должны становиться отдельными страницами в индексе.
Для сортировок и фильтров всё зависит от того, что именно меняется. Если параметр меняет только порядок карточек, canonical обычно ведёт на базовую страницу без параметра. Если фильтр формирует отдельную полезную посадочную страницу, которую вы хотите продвигать, canonical на базовую страницу уже может быть ошибкой.
Практическое правило простое: если параметр не создаёт новый самостоятельный документ, а лишь меняет представление существующего, canonical должен указывать на чистую версию. Если же параметр создаёт действительно отдельную страницу с уникальной ценностью, её нельзя бездумно канонизировать на общий URL.
Что делать с UTM-метками на WordPress-сайте
Если вы видите, что страницы с UTM попадают в индекс или появляются в отчётах как отдельные URL, сначала проверьте canonical в исходном коде. На нормальной странице с метками он должен вести на адрес без параметров. Если этого не происходит, проблема обычно в теме, SEO-плагине или в том, что страница отдаёт нестандартный шаблон.
Дополнительно полезно убедиться, что внутренние ссылки на сайте не содержат UTM. Если метки попадают в меню, хлебные крошки или карточки, поисковик будет чаще обходить «грязные» URL и дольше воспринимать чистую версию как основную.
Когда canonical для фильтров не сработает как вы ожидаете
Если фильтр меняет набор товаров или записей настолько сильно, что страница становится по сути новой посадочной страницей, canonical на базовую страницу может мешать её ранжированию. В таком случае лучше оценить, нужна ли отдельная SEO-страница под этот фильтр, а не пытаться склеить всё canonical-ом.
Ещё одна частая ошибка — ставить canonical на страницу без параметров, но оставлять в индексе десятки URL с параметрами, которые активно перелинкованы внутри сайта. Тогда поисковик продолжит их обходить, даже если canonical указан правильно. Canonical помогает, но не отменяет необходимость убрать лишние ссылки и продумать, какие URL вообще должны существовать.
Как проверить, что canonical настроен правильно
Проверка занимает несколько минут и лучше делать её после любых изменений в теме или SEO-плагине. Откройте страницу в браузере и посмотрите исходный код. В нём должен быть один canonical, без дублей и без очевидных ошибок в адресе.
Проверьте три сценария:
- обычная страница или запись — canonical на саму себя;
- архив — canonical на соответствующий архивный URL без лишних параметров;
- URL с параметрами — canonical на чистую основную версию, если параметры не создают отдельную страницу.
Если используете Google Search Console, можно дополнительно сравнить выбранный вами canonical и тот, который выбрал Google. Если поисковик систематически игнорирует ваш вариант, значит, на сайте есть противоречия: дублирующие страницы, разные внутренние ссылки, конфликтующие редиректы или несколько canonical в HTML.
Что не стоит делать при настройке canonical
Самая частая ошибка — ставить canonical на главную страницу для всех дублей подряд. Это выглядит как быстрый способ «собрать вес», но на деле ломает смысл страниц и мешает поисковику понять структуру сайта.
Вторая ошибка — использовать canonical вместо редиректа там, где нужен именно редирект. Если у вас есть две одинаковые версии одной страницы и одна из них больше не должна открываться, лучше настроить 301-редирект, а не оставлять обе доступными с canonical. Canonical не убирает дубль из обхода, он только подсказывает предпочтительную версию.
Третья ошибка — одновременно ставить canonical, noindex и несколько вариантов URL в sitemap. Это противоречивые сигналы. Сначала определите, какая страница основная, какие URL должны существовать технически, а какие нужно убрать или закрыть. Только после этого настраивайте canonical.
Если коротко: canonical в WordPress нужен для управления дублями, а не для маскировки проблем. На страницах и архивах чаще всего достаточно штатного вывода WordPress или SEO-плагина, а для параметров URL важно отделять технические дубли от реально полезных посадочных страниц. Когда canonical настроен аккуратно, поисковик получает понятный сигнал, а сайт — меньше мусора в индексе и меньше путаницы с основными URL.