Если в индексе появляются одинаковые или почти одинаковые страницы, canonical часто решает проблему без редиректов и без удаления контента. Но в WordPress этот тег легко настроить неправильно: поставить на все страницы один и тот же URL, забыть про пагинацию или случайно конфликтовать с SEO-плагином.
Ниже разберём, когда canonical действительно нужен, как добавить его в тему или плагин, как проверить, что поисковик видит нужный адрес, и какие ошибки встречаются чаще всего.
Когда canonical нужен, а когда нет
Canonical указывает поисковику предпочтительную версию страницы. Это полезно, если один и тот же контент доступен по разным адресам: с параметрами, через архивы, через пагинацию, в нескольких категориях или в версиях для сортировки и фильтрации.
Но canonical не заменяет редирект. Если у вас есть явный дубль, который не должен открываться пользователю, сначала лучше убрать причину дубля: настроить 301, закрыть служебный URL от индексации или убрать лишний маршрут. Canonical — это подсказка для поисковика, а не жёсткое правило.
Типичные сценарии дублей в WordPress
- страницы с параметрами
?utm_source=,?replytocom=, сортировкой или фильтрами; - архивы категорий и тегов с похожими сниппетами;
- страницы пагинации архивов;
- один и тот же материал, доступный через несколько таксономий;
- страницы поиска сайта, авторские архивы и служебные URL.
Диагностика: что именно дублируется
Перед правкой canonical стоит понять, где проблема. Откройте несколько подозрительных URL и сравните:
- одинаков ли заголовок страницы;
- совпадает ли основной контент;
- меняется ли URL только из-за параметра или пагинации;
- какой canonical уже выводится в исходном коде;
- не подставляет ли его SEO-плагин автоматически.
В браузере откройте исходный код страницы и найдите строку вида <link rel="canonical" href="..." />. Если canonical уже есть, не добавляйте второй такой же тег вручную: поисковики это не любят, а поведение становится непредсказуемым.
Для быстрой проверки удобно смотреть исходник через view-source: или использовать инструменты вроде Google Search Console и любой валидатор HTML. Важно не просто увидеть тег, а убедиться, что он указывает на канонический URL без параметров и без лишних слэшей.
Как добавить canonical в WordPress без плагина
Если тема или SEO-плагин не выводят canonical, его можно добавить через wp_head. Но сначала проверьте, не делает ли это уже wp_get_document_title() или SEO-плагин: дублировать тег не нужно.
Ниже пример для functions.php дочерней темы или собственного мини-плагина. Он выводит canonical для обычных записей, страниц и архивов, а для пагинации добавляет текущую страницу архива.
<?php
add_action( 'wp_head', 'wppay_output_canonical', 1 );
function wppay_output_canonical() {
if ( is_admin() || is_feed() ) {
return;
}
$canonical = '';
if ( is_singular() ) {
$canonical = get_permalink();
} elseif ( is_category() || is_tag() || is_tax() || is_post_type_archive() ) {
$canonical = get_pagenum_link( get_query_var( 'paged' ) ? absint( get_query_var( 'paged' ) ) : 1, false );
} elseif ( is_home() ) {
$canonical = home_url( '/' );
}
if ( $canonical ) {
echo '<link rel="canonical" href="' . esc_url( $canonical ) . '" />' . "\n";
}
}
Этот вариант рабочий, но его нельзя включать вслепую на сайт, где canonical уже выводит Yoast SEO, Rank Math или другой SEO-плагин. В таком случае сначала отключите дублирующий вывод в настройках плагина или используйте фильтр самого плагина, если он предусмотрен.
Если нужен canonical для страниц с параметрами
Самый частый практический случай — страница открывается с UTM-метками, параметрами сортировки или внутренними переменными, а в индекс должна попасть чистая версия URL. Для таких страниц canonical лучше строить от базового адреса без query string.
<?php
add_action( 'wp_head', 'wppay_canonical_without_query_args', 2 );
function wppay_canonical_without_query_args() {
if ( is_admin() || is_feed() || ! is_singular() ) {
return;
}
$canonical = get_permalink();
if ( ! $canonical ) {
return;
}
echo '<link rel="canonical" href="' . esc_url( $canonical ) . '" />' . "\n";
}
Здесь логика простая: если пользователь пришёл на /post/?utm_source=..., поисковику показываем /post/. Это не мешает аналитике, но помогает не размазывать сигналы по копиям URL.
Сравнение подходов: плагин, код, редирект
| Подход | Когда подходит | Минус |
|---|---|---|
| SEO-плагин | Если canonical нужен на большинстве типов страниц | Легко получить конфликт с темой или другим плагином |
| Код в теме/мини-плагине | Если нужен точечный контроль над отдельными шаблонами | Нужно следить за обновлениями и логикой шаблонов |
| 301-редирект | Если дубль не должен открываться вообще | Не всегда подходит для фильтров, пагинации и параметров |
На практике canonical и редирект часто работают вместе: редирект убирает лишний URL из пользовательского сценария, canonical подсказывает поисковику основную версию там, где редирект нежелателен.
Проверка результата после внедрения
После изменения откройте несколько страниц из проблемной группы и проверьте три вещи:
- в исходном коде есть только один тег canonical;
- URL в canonical совпадает с нужной канонической версией;
- на страницах пагинации canonical не указывает на первую страницу, если это не было вашей целью.
Дальше проверьте индексацию в Google Search Console: URL должен попадать в отчёт как выбранный канонический или хотя бы не конфликтовать с другой версией. Если поисковик выбирает свой canonical, значит на странице есть более сильный сигнал: дублирующий контент, внутренние ссылки на альтернативный URL, редиректы или противоречивые мета-теги.
Быстрый чек-лист
- canonical выводится один раз;
- он ведёт на чистый URL без параметров;
- на архивных страницах canonical соответствует логике пагинации;
- SEO-плагин не дублирует тег;
- внутренние ссылки ведут на ту же каноническую версию.
Частые ошибки и как их исправить
Ошибка 1: canonical на все страницы указывает на главную. Так делают, когда пытаются «быстро почистить индекс». В результате поисковик теряет смысл отдельных страниц. Исправление: canonical должен вести на саму страницу или на действительно основную версию группы дублей.
Ошибка 2: два canonical на одной странице. Обычно это конфликт темы и SEO-плагина. Исправление: оставьте один источник генерации тега.
Ошибка 3: canonical игнорирует пагинацию. Если все страницы архива указывают на первую, поисковик может хуже понимать структуру архива. Исправление: для paged-страниц используйте корректный URL страницы архива.
Ошибка 4: canonical и редирект противоречат друг другу. Например, canonical указывает на один URL, а редирект ведёт на другой. Исправление: сначала выровняйте поведение URL, потом проверьте тег.
Ошибка 5: canonical строится из $_SERVER['REQUEST_URI'] без очистки. Это часто тащит параметры и мусор. Исправление: используйте get_permalink(), home_url() и функции WordPress для построения адресов.
Безопасность и производительность
Canonical сам по себе не нагружает сайт, но ручная логика в wp_head должна быть простой и предсказуемой. Не делайте внутри неё запросы к базе, не собирайте URL через тяжёлые вычисления и не выводите тег на основе непроверенных пользовательских данных.
Если у вас уже стоит SEO-плагин, сначала проверьте его настройки. Иногда проще включить или отключить canonical там, чем писать свой код. Если нужен более широкий набор технических правок — например, чистка дублей, управление индексируемыми архивами и служебными страницами — удобнее собрать это в одном инструменте, а не размазывать по теме и нескольким сниппетам. В экосистеме WPShop для таких задач есть Clearfy Pro: https://wpshop.ru/plugins/clearfy?utm_source=wppay.ru&utm_medium=article&utm_campaign=kak-nastroit-canonical-v-wordpress-dlya-ubrat-dubli-stranic
Если после настройки canonical дубли всё равно остаются в индексе, обычно проблема не в самом теге, а в общей структуре URL и внутренних ссылках. Тогда имеет смысл отдельно проверить архивы, поиск по сайту, параметры фильтрации и карту сайта.