Что такое canonical URL

Canonical URL помогает поисковым системам понять, какую версию страницы владелец сайта считает основной, если один и тот же или очень похожий контент доступен по нескольким адресам.

На практике дубли могут появляться из-за параметров URL, www и без www, HTTP/HTTPS, сортировок, фильтров, пагинации, UTM-меток, технических путей CMS и нескольких вариантов маршрута.

Canonical не является редиректом, не запрещает пользователю открывать другой URL и не гарантирует, что поисковая система всегда выберет именно указанный адрес. Это важный SEO-сигнал, который должен быть согласован с sitemap, внутренними ссылками, redirect и фактической структурой сайта.

Что такое canonical URL

Canonical — предпочтительный URL страницы.

В HTML он обычно задаётся так:

<link rel="canonical" href="https://example.com/page">

Зачем нужен canonical

Он помогает объединять сигналы нескольких похожих URL вокруг одного основного адреса.

Например:

https://example.com/product
https://example.com/product?utm_source=telegram
https://example.com/product?ref=partner

Если содержимое одинаковое, canonical может указывать на:

https://example.com/product

Canonical — не redirect

Если пользователь открывает URL с canonical на другой адрес, браузер не обязан переходить туда.

Redirect работает на уровне HTTP и действительно отправляет клиента на другой URL.

Canonical — не noindex

Canonical сообщает предпочтительный адрес среди похожих страниц.

noindex сообщает, что страницу не следует включать в индекс.

Это разные задачи.

Canonical — не robots.txt

robots.txt регулирует crawling.

Canonical работает как сигнал консолидации URL.

Self-referencing canonical

Страница может указывать canonical сама на себя:

<link rel="canonical"
      href="https://example.com/blog/article">

Для многих публичных индексируемых страниц это нормальная практика.

Зачем self-canonical

Он явно сообщает предпочтительную форму URL даже при наличии:

• UTM;
• tracking parameters;
• случайных query parameters;
• альтернативных путей;
• ссылок с разными вариантами адреса.

Absolute или relative canonical

На практике безопаснее использовать абсолютный URL:

https://example.com/page

Это уменьшает вероятность неоднозначной интерпретации при сложной инфраструктуре.

Canonical и HTTP/HTTPS

Если основной сайт работает по HTTPS, canonical обычно должен указывать на HTTPS-версию.

Например, нежелательно:

Page:
https://example.com/page

Canonical:
http://example.com/page

Canonical и www

Если основной хост:

https://example.com

то не стоит случайно ставить canonical на:

https://www.example.com

если именно версия без www является основной.

Canonical и trailing slash

Адреса:

/page
/page/

могут считаться разными URL.

CMS должна выбрать единый канонический формат.

Canonical и регистр символов

В URL-путях регистр технически может иметь значение.

Поэтому варианты:

/Article
/article

не стоит бездумно считать одним URL.

Canonical и параметры URL

Один из самых частых сценариев — параметры.

Например:

/catalog?sort=price
/catalog?sort=name
/catalog?utm_source=vk

Если эти параметры не создают самостоятельный уникальный контент, canonical может вести на основной URL каталога.

Когда параметры создают отдельную страницу

Не все параметры являются дублями.

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

Canonical и UTM

Tracking-параметры обычно не меняют основной контент.

Поэтому:

https://example.com/page?utm_source=telegram

часто должен ссылаться canonical на:

https://example.com/page

Canonical и pagination

Пагинацию нельзя автоматически canonical-ить на первую страницу без понимания структуры.

Например:

/blog?page=2

содержит другой набор материалов, поэтому canonical на первую страницу может быть неправильным.

Canonical и категории

Категория блога может иметь собственный canonical:

https://example.com/blog/dns

Если это самостоятельная индексируемая страница.

Canonical и теги

Если страницы тегов индексируются, каждая должна иметь согласованный canonical.

Если они noindex, архитектуру нужно анализировать отдельно.

Canonical и sitemap

URL в sitemap желательно согласовывать с canonical.

Плохая ситуация:

Sitemap:
https://example.com/page-a

Canonical на page-a:
https://example.com/page-b

Такая конфигурация посылает противоречивые сигналы.

Canonical и внутренние ссылки

Если canonical указывает на URL A, внутренние ссылки тоже желательно вести преимущественно на A.

Не стоит строить сайт так, что:

• canonical → A;
• sitemap → A;
• но 90% внутренних ссылок ведут → B.

Canonical и redirect

Если URL больше не должен существовать как отдельная страница, часто правильнее использовать HTTP redirect, а не только canonical.

Когда нужен 301 вместо canonical

Если старый URL окончательно переехал:

/old-page
→
/new-page

обычно нужен permanent redirect.

Canonical между разными доменами

Canonical технически может указывать на другой домен.

Это используется, например, при синдикации контента.

Но cross-domain canonical должен применяться осознанно.

Можно ли ставить несколько canonical

Нет, страница должна давать однозначный сигнал.

Несколько конфликтующих canonical — ошибка конфигурации.

Canonical в HTTP header

Для некоторых не-HTML ресурсов canonical можно передавать через HTTP Link header.

Например:

Link: <https://example.com/file.pdf>; rel="canonical"

Canonical и JavaScript

Лучше, чтобы критически важный canonical присутствовал в исходном HTML и не зависел исключительно от JavaScript.

Почему поисковик может игнорировать canonical

Canonical — сильный сигнал, но не абсолютная команда.

Поисковая система может выбрать другой URL, если видит противоречия.

Например:

• разный контент;
• canonical ведёт на 404;
• canonical редиректит;
• страница назначения noindex;
• сильные внутренние ссылки ведут на другую версию;
• sitemap указывает другой URL.

Ошибка: canonical ведёт на 404

Canonical должен указывать на существующий рабочий URL.

Ошибка: canonical ведёт на redirect

Лучше указывать сразу конечный канонический URL.

Ошибка: canonical ведёт на noindex

Это противоречивый сигнал.

Ошибка: canonical на совершенно другой контент

Canonical предназначен для одинаковых или существенно похожих страниц, а не для произвольной передачи SEO-сигналов.

Ошибка: все страницы сайта canonical на главную

Это грубая ошибка.

Статья, товар, категория и справочная страница не должны автоматически canonical-иться на homepage.

Ошибка: staging попал в canonical

После переноса проекта иногда остаётся:

https://staging.example.com/page

вместо production URL.

Такую ошибку важно проверять после миграций.

Ошибка: localhost в canonical

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

Ошибка за reverse proxy

Если приложение не понимает, что исходный запрос был HTTPS, оно может генерировать:

http://example.com/page

вместо HTTPS.

Проверяйте proxy headers и доверенные proxy.

Как посмотреть canonical через curl

curl -sS https://example.com/page \
  | grep -i 'rel="canonical"'

Как проверить HTTP status canonical URL

curl -I https://example.com/page

Как проверить redirect chain

curl -IL https://example.com/page

Как проверить canonical вручную

Сравните:

1. текущий URL;
2. canonical;
3. HTTP status canonical;
4. redirect chain;
5. robots;
6. meta robots;
7. sitemap;
8. внутренние ссылки.

Canonical в NexIP

SEO-проверка NexIP должна уметь определять canonical страницы и выявлять конфликты.

Полезные проверки:

• canonical отсутствует;
• canonical пустой;
• несколько canonical;
• canonical относительный;
• canonical на HTTP вместо HTTPS;
• canonical на redirect;
• canonical на 404/5xx;
• canonical на noindex;
• canonical mismatch с sitemap.

Canonical и архитектура блога NexIP

У статьи canonical должен вести на её основной URL:

/blog/category/article-slug

UTM и другие tracking-варианты не должны создавать новые канонические страницы.

Canonical для пагинации блога

Страницы пагинации представляют разные наборы материалов.

Поэтому нельзя автоматически canonical-ить все страницы на первую.

В NexIP дополнительные страницы блога могут быть noindex, follow, сохраняя собственный URL для навигации.

Canonical и интеллектуальный поиск

Страницы вида:

/blog/search?q=dns

не должны становиться каноническими контентными страницами.

Для внутреннего поиска правильнее использовать noindex, follow.

Связь с sitemap.xml

Подробно карта сайта разобрана в статье «Что такое sitemap.xml».

Связь с robots.txt

Правила обхода разобраны в статье «Что такое robots.txt».

Правильный порядок проверки canonical

1. Определить текущий URL.
2. Найти rel=canonical.
3. Проверить, что canonical абсолютный и корректный.
4. Проверить HTTP status.
5. Проверить redirects.
6. Проверить noindex.
7. Сравнить с sitemap.
8. Сравнить с внутренними ссылками.
9. Проверить HTTP/HTTPS.
10. Проверить www/non-www.

Что важно запомнить

• Canonical сообщает предпочтительную версию URL.
• Он не является redirect.
• Он не является noindex.
• Canonical должен вести на рабочий релевантный URL.
• Sitemap желательно согласовывать с canonical.
• Внутренние ссылки тоже должны поддерживать канонический URL.
• UTM обычно не должны создавать отдельные canonical.
• Пагинацию нельзя бездумно canonical-ить на первую страницу.
• После миграций нужно проверять host и scheme.
• NexIP должен выявлять canonical-конфликты автоматически.

FAQ

Canonical удаляет дубль из поиска?

Не является прямой командой удаления. Он сообщает поисковой системе предпочтительный URL.

Нужен ли canonical на каждой странице?

Self-referencing canonical часто полезен для публичных индексируемых страниц, но архитектура зависит от сайта.

Можно ли canonical на главную?

Только если текущая страница действительно является дублем главной. Делать это для всех страниц неправильно.

Можно ли canonical на другой домен?

Да, cross-domain canonical существует, но применять его нужно осознанно.

Canonical и 301 — что выбрать?

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

Можно ли canonical на noindex страницу?

Это противоречивая конфигурация, которой лучше избегать.

Почему поисковик выбрал другой canonical?

Проверьте контент, sitemap, внутренние ссылки, redirects, HTTP status и другие сигналы.

Как быстро проверить canonical?

curl -sS https://example.com/page \
  | grep -i canonical

По теме: Дубли страниц и SEO: откуда берутся и что с ними делать.