Если у сайта в индексе появляются одинаковые или почти одинаковые страницы, одной noindex обычно недостаточно. Поисковик может продолжать обходить URL с параметрами, страницами пагинации, архивами автора, версиями с UTM и техническими дублями. В таких случаях нужен корректный rel="canonical": он подсказывает, какой адрес считать основным.
На практике проблема чаще всего всплывает не на «большом SEO», а в мелочах: один и тот же материал открывается через несколько URL, тема выводит неправильный canonical, плагин кэширования подменяет заголовки, а фильтры и параметры запроса создают лишние копии страниц. Ниже — как это диагностировать и исправить без лишних костылей.
Когда canonical действительно нужен
Canonical полезен там, где контент одинаковый, но URL отличается. Это не замена редиректам и не способ скрыть плохую структуру сайта. Если у страницы есть один очевидный основной адрес, лучше настроить 301-редирект. Canonical нужен, когда редирект невозможен или нежелателен: например, для пагинации, сортировок, параметров фильтра, страниц печати, UTM-меток, архивов и дублей из-за темы или плагина.
Типичные сценарии дублей
- одна запись открывается с
?utm_source=и без параметров; - страница категории доступна через несколько путей из-за старых ссылок;
- архивы автора и таксономий дублируют смысловые страницы;
- плагин SEO уже выводит canonical, но тема добавляет второй тег;
- на сайте есть страницы с пагинацией, где canonical указывает не туда.
Диагностика проблемы: что проверить сначала
Начните с исходного HTML. Откройте проблемную страницу и посмотрите, сколько раз в <head> выводится canonical и какой URL там указан. Если тегов два, поисковик может игнорировать оба. Если canonical ведёт на несуществующий адрес, на URL с параметрами или на главную страницу без причины, это уже ошибка настройки.
Полезно проверить не только код страницы, но и ответы сервера. Иногда canonical в HTML правильный, а редиректы, кэш или CDN отдают старую версию. Для быстрой проверки можно использовать:
curl -I https://example.com/page/?utm_source=testИ отдельно посмотреть HTML:
curl -s https://example.com/page/ | grep -i canonicalЕсли сайт большой, проверьте несколько типов страниц: запись, рубрику, архив автора, страницу с параметрами и пагинацию. Ошибка часто проявляется только в одном шаблоне.
Как настроить canonical в WordPress без конфликтов
В WordPress canonical обычно выводит SEO-плагин или ядро. Поэтому сначала нужно понять, кто именно отвечает за тег. Если у вас уже стоит SEO-плагин, не добавляйте второй canonical вручную в теме без необходимости. Дублирование — самая частая причина проблем.
| Подход | Когда подходит | Минус |
|---|---|---|
| SEO-плагин | Если нужен canonical почти на всех типах страниц | Легко получить конфликт с темой или другим плагином |
| Код в теме/плагине | Если нужен точечный контроль для отдельных шаблонов | Нужно аккуратно поддерживать при обновлениях |
| Редирект вместо canonical | Если дубль не нужен вообще | Меняет URL и может затронуть внешние ссылки |
Вариант 1: задать canonical для конкретного шаблона
Если у вас есть отдельный шаблон страницы, и canonical должен указывать на основной URL без параметров, можно вывести его через wp_head. Но сначала убедитесь, что другой плагин не делает то же самое.
<?php
add_action( 'wp_head', function () {
if ( is_page( 123 ) ) {
$canonical = get_permalink( 123 );
echo '<link rel="canonical" href="' . esc_url( $canonical ) . '" />' . "\n";
}
}, 1 );Здесь приоритет 1 помогает вывести тег раньше, но это не решает конфликт, если SEO-плагин уже печатает canonical позже. В таком случае нужно отключить его вывод для конкретного шаблона или страницы.
Вариант 2: изменить canonical через фильтр
Если canonical генерируется ядром WordPress, можно использовать фильтр get_canonical_url. Это более чистый вариант, чем печатать второй тег вручную.
<?php
add_filter( 'get_canonical_url', function ( $canonical, $post ) {
if ( $post instanceof WP_Post && $post->ID === 123 ) {
return home_url( '/main-page/' );
}
return $canonical;
}, 10, 2 );Такой подход полезен, когда у записи есть несколько технических адресов, но нужен один основной. Главное — не подменять canonical на нерелевантную страницу. Поисковик быстро замечает такие несоответствия.
Вариант 3: убрать лишние параметры из canonical
Если проблема в UTM или служебных параметрах, canonical должен вести на чистый URL без query string. В большинстве случаев WordPress и так формирует его корректно, но если шаблон или плагин вмешивается, проверьте логику генерации. Не стоит строить canonical через $_SERVER['REQUEST_URI'] без фильтрации — так легко утащить мусорные параметры в head.
<?php
function wp0_clean_canonical_url( $url ) {
$parts = wp_parse_url( $url );
if ( empty( $parts['scheme'] ) || empty( $parts['host'] ) ) {
return $url;
}
$clean = $parts['scheme'] . '://' . $parts['host'];
if ( ! empty( $parts['path'] ) ) {
$clean .= $parts['path'];
}
return trailingslashit( $clean );
}Эта функция сама по себе ничего не меняет, но показывает безопасный способ собрать URL без параметров. Используйте её только там, где действительно нужен чистый адрес.
Пошаговое решение для типового сайта
- Определите, кто выводит canonical: ядро, SEO-плагин или тема.
- Проверьте, нет ли второго тега в исходнике страницы.
- Для дублей с параметрами оставьте один основной URL без query string.
- Для страниц, которые должны быть отдельными, не указывайте canonical на родительскую рубрику или главную.
- После правки очистите кэш сайта, сервера и CDN.
- Проверьте HTML и ответ сервера на нескольких типах страниц.
Как проверить, что решение сработало
Проверка должна быть не визуальной, а технической. Откройте исходный код страницы и убедитесь, что:
- в
<head>только один тег canonical; - URL в canonical совпадает с основным адресом страницы;
- на URL с параметрами canonical указывает на чистую версию;
- на пагинации canonical не ведёт на случайную запись или главную;
- после очистки кэша тег не меняется обратно.
Дополнительно можно проверить через Search Console, если страница уже была просканирована. Там видно, какой URL выбран каноническим поисковиком и совпадает ли он с вашим.
Частые ошибки и как их исправить
Два canonical на одной странице
Обычно это конфликт темы и SEO-плагина. Оставьте один источник истины. Если плагин уже управляет canonical, не печатайте второй тег вручную.
Canonical указывает на главную без причины
Так часто ломают архивы, страницы поиска или записи с параметрами. Проверьте шаблон и логику фильтра. Для большинства страниц canonical должен вести на саму страницу, а не на корень сайта.
Canonical не совпадает с редиректом
Если URL реально должен быть один, canonical и 301-редирект должны вести в одну сторону. Иначе поисковик получает противоречивые сигналы.
Кэш отдает старую версию head
После изменений очистите не только плагин кэша, но и серверный кэш, если он есть. Иначе вы будете проверять уже исправленный код в файлах, но видеть старый HTML в браузере.
Безопасность и производительность
Не собирайте canonical из сырых GET-параметров и не подставляйте в него непроверенные значения. Это не только SEO-ошибка, но и лишний риск для шаблона. Если пишете свой код, используйте esc_url(), home_url(), get_permalink() и фильтры WordPress вместо ручной склейки строк.
Если на сайте много технических дублей, иногда быстрее сначала навести порядок в структуре URL, чем пытаться лечить всё canonical. Для массовой чистки дублей, архивов и служебных мета-тегов можно посмотреть в сторону Clearfy Pro: https://wpshop.ru/plugins/clearfy?utm_source=wp0.ru&utm_medium=article&utm_campaign=kak-nastroit-canonical-v-wordpress-dlya-ustraneniya-dubley-stranic. Но даже с плагином важно понимать, какой именно URL должен быть основным.
Если canonical нужен только для нескольких шаблонов, код в небольшом mu-plugin обычно надёжнее, чем правка темы: он не потеряется при обновлении и проще в сопровождении.