Как настроить canonical в WordPress для борьбы с дублями страниц

Автор: Кирилл Кузнецов | Опубликовано: 16.10.2026

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

Но canonical не лечит все дубли автоматически. Если поставить его неправильно, можно получить обратный эффект: поисковик начнёт игнорировать нужные страницы или склеит не то, что нужно. Ниже разберём, как canonical работает в WordPress, где его настраивать и какие ошибки встречаются чаще всего.

Что делает canonical и когда он нужен

Canonical — это ссылка на предпочтительный адрес страницы, которая размещается в коде в виде тега <link rel="canonical" href="...">. Для поисковика это сигнал: «если есть несколько похожих URL, индексируй и ранжируй вот этот».

В WordPress canonical особенно полезен, когда одна и та же сущность доступна по нескольким адресам:

страница открывается со слэшем и без него;
в URL есть UTM-метки, фильтры, сортировка или другие параметры;
пост доступен из рубрики, архива автора, страницы поиска или меток;
категория, тег и пагинация создают похожие страницы с повторяющимся контентом;
сайт работает на http и https, либо с www и без www, а редиректы настроены не до конца.

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

Как WordPress формирует canonical по умолчанию

В актуальных версиях WordPress canonical для записей, страниц, архивов и части других типов контента обычно выводится автоматически. Это делает ядро, а не тема. Поэтому в базовом случае вручную ничего добавлять не нужно.

Проблемы начинаются, когда:

тема или плагин SEO отключает стандартный canonical и подставляет свой;
на странице выводится несколько canonical-тегов;
canonical указывает на неправильный URL, например на главную или на другую запись;
страница отдает один адрес, а в canonical прописан другой формат URL.

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

Как проверить, какой canonical сейчас стоит на странице

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

Проверьте три вещи:

canonical вообще есть в коде;
он один, а не несколько;
адрес в href совпадает с той версией, которую вы хотите считать основной.

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

Настройка canonical через SEO-плагин

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

Если у вас установлен плагин SEO, откройте настройки конкретной записи или страницы и найдите блок с каноническим URL. В зависимости от плагина он может называться Canonical URL, Канонический URL или быть скрыт в расширенных настройках. Для обычной страницы canonical должен указывать на её основной адрес без лишних параметров.

Когда canonical имеет смысл задавать вручную:

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

Не ставьте один и тот же canonical на разные страницы «по шаблону». У каждой страницы должен быть свой логичный основной адрес, иначе поисковик начнёт склеивать несвязанные документы.

Когда canonical лучше задавать вручную в теме

Ручная настройка в шаблоне нужна редко. Обычно она оправдана, если:

у вас кастомная тема без SEO-плагина;
плагин не покрывает нужный тип страниц;
нужно исправить нестандартную логику URL в собственном шаблоне.

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

Пример для случая, когда нужно явно вывести canonical для текущей страницы:

add_action( 'wp_head', function () {
    if ( is_singular() ) {
        echo '<link rel="canonical" href="' . esc_url( get_permalink() ) . '" />' . "\n";
    }
}, 1 );

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

Типичные ошибки при настройке canonical

Самая частая ошибка — canonical указывает на URL, который сам по себе не является доступной страницей. Например, в теге стоит адрес с редиректом, 404 или неканонической версией. Поисковик может проигнорировать такой сигнал.

Ещё несколько распространённых проблем:

Несколько canonical на одной странице. Это часто бывает, когда их выводят и тема, и SEO-плагин.
Canonical на главную для всех страниц. Так делать нельзя: поисковик перестаёт различать документы.
Canonical на страницу с параметрами. Если параметры не меняют содержимое, лучше указывать чистый URL без них.
Canonical и редирект конфликтуют. Если страница редиректит на другой адрес, canonical должен быть согласован с этим редиректом.
Каноникал на неиндексируемую страницу. Если целевая страница закрыта от индексации, сигнал становится слабым или бессмысленным.

Отдельно проверьте пагинацию. Если у вас есть страницы рубрики /category/page/2/, canonical обычно должен вести на саму эту страницу, а не на первую страницу рубрики. Иначе поисковик может начать путать разные страницы выдачи внутри архива.

Как понять, что canonical настроен правильно

После правок откройте несколько проблемных URL и сравните исходный код. У правильной версии должны совпадать три вещи: открываемый адрес, canonical в HTML и конечный URL после редиректов.

Практическая проверка выглядит так:

Откройте основной URL страницы.
Убедитесь, что canonical указывает на него же.
Откройте дубль с параметром или альтернативным путем.
Проверьте, что либо срабатывает 301-редирект, либо canonical указывает на основной адрес.

Если у вас есть доступ к Google Search Console, полезно посмотреть, какую страницу поисковик считает канонической. Иногда он выбирает не ту версию даже при корректном теге, если сайт подаёт противоречивые сигналы: разные внутренние ссылки, дубли в sitemap, одинаковые заголовки и слабую различимость страниц.

Что делать, если поисковик всё равно выбирает не тот URL

Canonical — это подсказка, а не приказ. Если поисковик упорно выбирает другую версию, обычно проблема не в одном теге, а в наборе сигналов. Тогда проверьте:

есть ли 301-редирект с дубля на основной URL;
не ссылаются ли внутренние ссылки на дубль чаще, чем на основную страницу;
не попали ли дубли в XML-карту сайта;
не отличается ли содержимое страниц слишком слабо;
не закрыта ли основная версия от индексации случайно.

Если дубли создаёт фильтр, поиск или сортировка, canonical часто нужно сочетать с ограничением индексации параметров и с нормальной структурой внутренних ссылок. Иначе поисковик продолжит видеть несколько равнозначных URL и выбирать их по собственным сигналам.

Для типового сайта на WordPress рабочая схема обычно такая: технические дубли закрываются редиректами, страницы с параметрами получают canonical на чистый адрес, а у каждой основной записи canonical совпадает с её постоянным URL. Это несложно, но требует аккуратности: один лишний тег или неверный шаблон быстро ломают всю логику.

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