Если в поиске начинают всплывать одинаковые или почти одинаковые страницы, проблема часто не в контенте, а в том, что поисковик видит несколько URL с одним и тем же смыслом. Для WordPress это обычная ситуация: одна запись может открываться с параметрами, архивами, пагинацией, UTM-метками или через несколько путей. В таких случаях помогает canonical — каноническая ссылка, которая подсказывает поисковым системам, какой адрес считать основным.
Ниже разберём, где в WordPress задаётся canonical, когда его нужно править вручную, а когда лучше оставить стандартное поведение. Это как раз тот случай, где важно не «добавить canonical везде», а сделать его корректным для конкретного типа страниц.
Что делает canonical и когда он нужен
Canonical — это тег <link rel="canonical" href="..."> в <head> страницы. Он не запрещает индексацию и не удаляет дубли сам по себе. Его задача проще: указать поисковику предпочтительный URL, если одна и та же страница доступна по нескольким адресам.
В WordPress canonical особенно полезен, когда:
- одна запись открывается с параметрами вроде
?utm_source=...или?replytocom=...; - архивы категорий, тегов и авторов дублируют смысловые страницы;
- есть пагинация архивов и страниц записей;
- сайт доступен с разными вариантами URL, например со слешем и без него, через http и https, с www и без www;
- один и тот же контент доступен по нескольким шаблонам темы или через плагины фильтрации.
Если canonical настроен правильно, поисковик обычно выбирает основную страницу и реже склеивает мусорные адреса в отдельные результаты.
Как WordPress формирует canonical по умолчанию
В актуальных версиях WordPress canonical для большинства страниц добавляется автоматически. За это отвечает ядро, и в типовом случае ничего вручную прописывать не нужно. Для записей, страниц, рубрик, архивов и пагинации WordPress старается вывести корректный основной URL.
Но есть важная оговорка: стандартный canonical не всегда учитывает особенности темы, плагинов и нестандартной логики сайта. Если у вас:
- фильтры меняют содержимое страницы через GET-параметры;
- страницы генерируются плагином и имеют несколько вариантов одного и того же адреса;
- тема или SEO-плагин переопределяют canonical;
- нужен canonical на пользовательском типе записей или в нестандартном архиве;
тогда автоматического варианта может быть недостаточно.
Где задавать canonical в WordPress
На практике есть три уровня, где canonical может появляться или меняться: ядро WordPress, SEO-плагин и код темы или плагина. Понимать это важно, чтобы не получить два canonical на одной странице или конфликт между разными источниками.
1. Ядро WordPress
Если вы ничего не настраивали, canonical часто уже выводится ядром. Это нормальная отправная точка. Для обычного сайта с типовыми записями и страницами этого достаточно.
Проверять нужно не факт наличия тега вообще, а его содержимое: ведёт ли он на правильный основной URL без лишних параметров и без ошибочного адреса архива.
2. SEO-плагин
Многие SEO-плагины умеют управлять canonical для отдельных типов страниц. Это удобно, если нужно задать правила без правки кода. Но здесь важно не смешивать настройки нескольких плагинов одновременно. Если один плагин уже выводит canonical, а второй делает то же самое, в HTML может появиться конфликт.
Если вы используете SEO-плагин, сначала проверьте, не управляет ли он canonical автоматически. В большинстве случаев ручная правка нужна только для отдельных страниц или нестандартных шаблонов.
3. Тема или собственный код
Если задача точечная, canonical можно задать через код в теме или в небольшом плагине. Это полезно, когда нужно изменить canonical только для конкретного шаблона или типа страниц.
Для вывода собственного canonical в WordPress обычно используют хук wp_head. Пример нужен только тогда, когда стандартный механизм не подходит. Перед изменением кода обязательно сделайте резервную копию или работайте в дочерней теме, иначе обновление темы может затереть правки.
add_action('wp_head', function () {
if (is_singular('post')) {
echo '<link rel="canonical" href="' . esc_url(get_permalink()) . '" />' . "\n";
}
}, 1);Этот пример показывает принцип, но использовать его нужно осторожно: если canonical уже выводится ядром или SEO-плагином, вы получите дублирующий тег. В реальном проекте сначала проверьте исходный HTML страницы.
Как исправить дубли из-за параметров в URL
Самая частая проблема — когда одна и та же страница доступна с параметрами. Например, ?utm_source, ?utm_medium, ?sort=, ?filter= или ?replytocom=. Для пользователя это один и тот же контент, а для поисковика — разные URL.
В таких случаях canonical должен указывать на чистый адрес без служебных параметров. Обычно это делает WordPress или SEO-плагин, но если параметр создаёт отдельный шаблон или плагин фильтрации, canonical может указывать на сам параметризованный URL. Это уже ошибка.
Что проверить:
- на странице с параметром canonical ведёт на чистый URL;
- в HTML нет второго canonical от другого плагина;
- страница не отдаёт разные canonical в зависимости от параметра;
- внутренние ссылки на сайте ведут на основной URL, а не на параметризованный вариант.
Если параметр не нужен для индексации, canonical — это только часть решения. Иногда дополнительно стоит убрать такие URL из внутренних ссылок и формировать ссылки без лишних параметров. Иначе поисковик будет снова и снова находить новые варианты адреса.
Что делать с архивами и пагинацией
Архивы рубрик, тегов, авторов и дат часто создают дубли не потому, что canonical сломан, а потому что сам тип страницы похож на другие страницы сайта. Здесь важно не пытаться «склеить всё в одну страницу» без разбора. У архивов есть своя логика, и canonical должен соответствовать этой логике.
Для первой страницы архива canonical обычно указывает на сам архив. Для второй и последующих страниц пагинации canonical, как правило, тоже должен указывать на текущую страницу пагинации, а не на первую. Иначе поисковик может игнорировать контент со страниц 2, 3 и далее.
Типичная ошибка — вручную ставить canonical всех страниц пагинации на первую страницу архива. Это удобно только на бумаге, но на практике ломает понимание структуры сайта. Если у вас есть полезный контент на второй и третьей странице архива, поисковику нужен именно их собственный адрес.
Если же архив не несёт ценности и вам не нужен в поиске, canonical сам по себе не решит задачу. Тогда уже нужно смотреть на индексацию и доступность, но это отдельная история. Для canonical здесь правило простое: не подменяйте адрес страницы на чужой, если эта страница реально должна существовать как отдельная.
Как проверить, что canonical работает правильно
После настройки не стоит полагаться только на визуальную проверку в админке. Надёжнее открыть исходный код страницы и посмотреть, какой canonical реально отдается браузеру и поисковому роботу.
Проверка вручную:
- Откройте нужную страницу в браузере.
- Посмотрите исходный код страницы.
- Найдите строку
rel="canonical". - Убедитесь, что URL совпадает с основным адресом страницы без лишних параметров.
Если есть доступ к инструментам для проверки URL в поисковой системе, используйте их тоже. Там видно, какой canonical распознан поисковиком, а не только что написано в коде страницы. Это полезно, если у вас несколько уровней переопределения: ядро WordPress, SEO-плагин и тема.
Ещё один практичный тест — открыть страницу с параметром и сравнить canonical с чистым URL. Если canonical меняется в зависимости от параметра так, как вы и ожидали, настройка работает. Если нет — ищите конфликт плагинов или шаблон, который выводит свой тег.
Типичные ошибки при настройке canonical
Чаще всего проблемы возникают не из-за самого canonical, а из-за неправильного места настройки.
- Два canonical на одной странице. Обычно это конфликт ядра WordPress и SEO-плагина или ручного кода в теме.
- Canonical ведёт на несуществующий URL. Такое бывает после смены структуры постоянных ссылок или переноса сайта.
- Все страницы пагинации указывают на первую. В результате поисковик теряет смысл второй и следующих страниц.
- Canonical оставляет UTM и другие параметры. Тогда дубли не склеиваются как надо.
- Canonical ставят вместо исправления внутренних ссылок. Это не убирает источник дублей, а только подсказывает поисковику предпочтительный адрес.
Если дублей много, сначала проверьте, откуда они появляются: из параметров, архивов, пагинации или нескольких версий одного URL. После этого уже выбирайте способ правки. Для одного шаблона достаточно кода или настроек SEO-плагина, для массовой проблемы — нужно смотреть на структуру ссылок и шаблоны генерации URL.
Когда лучше не трогать canonical вручную
Если сайт работает на стандартном WordPress без нестандартных фильтров и без конфликтующих плагинов, ручная правка canonical часто не нужна. В такой ситуации безопаснее оставить автоматическую логику ядра или SEO-плагина и только проверить, что она выдаёт правильный адрес.
Ручное вмешательство оправдано, когда есть конкретная причина: неправильный canonical на параметризованных страницах, конфликт нескольких плагинов, особый шаблон архива или нестандартный тип страниц. Во всех остальных случаях лишний код только повышает риск ошибки при обновлении темы или плагина.
Если вам нужно не только настроить canonical, но и системно убрать дубли на WordPress-сайте, удобнее решать это на уровне SEO-настроек и очистки лишней служебной разметки. В таких задачах может помочь Clearfy Pro, если он уже используется в вашем проекте и подходит под текущую схему плагинов.
Главная идея простая: canonical должен указывать на тот URL, который вы действительно хотите видеть в поиске. Если этот адрес выбран правильно, а дубли не создаются внутренними ссылками и параметрами, поисковикам становится намного проще понять структуру сайта.