Канонический адрес (canonical)

Происхождение и история термина

Научный контекст: «разные адреса с одинаковым текстом». Проблему дублирующих URL исследователи информационного поиска описали раньше, чем появился атрибут rel="canonical". В 2007 году на конференции WWW вышла работа З. Бар-Йосефа, И. Кейдар и У. Шёнфельда о задаче DUST — «Different URLs with Similar Text» ^[11]. По словам авторов, такие адреса порождают псевдонимы и перенаправления серверного ПО, а знание о них помогает эффективнее сканировать сайты, сокращать нагрузку на индексирование и точнее считать популярность страниц, например PageRank ^[11].

2009 год: Google вводит rel="canonical". Запись в блоге Google для вебмастеров «Specify your canonical» (авторы — Joachim Kupke и Maile Ohye; архив блога относит её к февралю 2009 года) объявила о поддержке формата, позволяющего публично указать предпочтительную версию URL ^[10]. Уже тогда это была подсказка: «It's a hint that we honor strongly» ^[10]. Сначала элемент учитывался в пределах домена и его поддоменов, но «not across domains»; в обновлении от 17 декабря 2009 года Google объявил поддержку кросс-доменного элемента: «We now support a cross-domain rel="canonical" link element» ^[10]. В той же записи сказано, что элемент поддерживают Ask.com, Microsoft Live Search и Yahoo! ^[10]. Это исторические сведения 2009 года; о нынешней поддержке другими поисковиками они не говорят.

2012 год: RFC 6596. В апреле 2012 года М. Оэй и Й. Купке опубликовали RFC 6596 «The Canonical Link Relation» ^[1]. Документ описывает тип связи canonical, которым обозначают IRI, предпочтительный по отношению к ресурсам с дублирующимся содержимым ^[1]. Статус RFC 6596 — Informational: он опубликован «for informational purposes» и не входит в число стандартов IETF в строгом смысле (Standards Track) ^[1]. Тип связи внесён в реестр IANA Link Relations с описанием «Designates the preferred version of a resource (the IRI and its contents)» и ссылкой на RFC 6596 ^[2].

Изменения в практике. Яндекс при смене адреса сайта с HTTP на HTTPS требует редирект 301 или 302: «Атрибут rel="canonical" для адресов такого формата больше не поддерживается» ^[12]. Дату этого изменения справка не приводит.

Русская терминология. В русской версии документации Google процесс canonicalization называется «нормализация»: страницы называются «Что такое нормализация» и «Как решить проблемы с нормализацией страниц» ^[3], ^[5]. В отраслевых текстах встречаются также «канонизация» и разговорное «каноникал» — например, в руководстве блога SE Ranking есть раздел «Канонизация междоменных дубликатов» и разбор выражения «закрыть тегом каноникал», которое автор называет «не совсем верным» ^[18].

Суть и механизм

Канонизация (нормализация)

По определению Google, канонизация — это «the process of selecting the representative –canonical– URL of a piece of content» ^[3], то есть выбор одного адреса, который будет представлять содержимое в поиске. Google перечисляет типичные источники дублей: региональные варианты страницы на одном языке, отдельные мобильные и десктопные версии, варианты по протоколу (HTTP и HTTPS), сортировки и фильтры, случайные копии вроде открытого для роботов демо-сайта ^[3]. Откуда берутся дубли и как их найти — в статье Дубли страниц.

При выборе канонического адреса Google учитывает несколько факторов: отдаётся ли страница по HTTPS или HTTP, редиректы, наличие URL в файле Sitemap и аннотации rel="canonical" ^[3].

Что происходит с неканоническими адресами

• Google. Каноническую страницу робот сканирует чаще всего, дубли — реже, чтобы снизить нагрузку на сайт ^[3]. Указание канонического адреса помогает объединить сигналы, например ссылки, с дублей на одном URL и показать в выдаче нужный адрес, скажем, без параметров отслеживания ^[4].
• Яндекс. Если указание учтено, «неканоническая страница пропадет из результатов поиска» и окажется в блоке «Исключённые страницы» Вебмастера ^[12].

Требования RFC 6596

Раздел 3 RFC 6596 формулирует требования к цели связи ^[1]:

• целевой адрес «MUST identify content that is either duplicative or a superset» содержимого исходной страницы, то есть быть её дубликатом или «надмножеством»;
• цель может быть относительным IRI, ссылаться на саму страницу (самоссылка), находиться на другом хосте или домене, иметь другую схему (например, http и https);
• RFC рекомендует указывать для ресурса только один canonical;
• целью не стоит делать адрес, с которого настроен постоянный редирект, адрес с собственным canonical на третью страницу (цепочка) и адрес, отдающий ошибку 4xx.

Пример неправильного использования из того же раздела: в многостраничной статье «page-2.html SHOULD NOT designate page-1.html as the target (canonical) IRI because this may cause a loss of data» ^[1] — вторая страница не дублирует первую. Допустимо другое: страница-часть может указывать на страницу «Показать всё», которая содержит весь текст ^[1].

Синтаксис

HTML-страница — элемент <link> в разделе <head> ^[1], ^[4], ^[12]:

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

Не-HTML файл (например, PDF) — HTTP-заголовок Link в ответе сервера ^[1], ^[4], ^[12]:

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

Адреса в примерах условные. Заголовок Google поддерживает только для результатов веб-поиска ^[4].

Сигналы канонизации у Google

Google отмечает, что методы можно сочетать и вместе они действуют сильнее, но ни один из них не обязателен ^[4]. Временные редиректы, по справке Google о перенаправлениях, такого сигнала не дают ^[15].

Виды и классификации

По способу указания (классификация Google и RFC 6596): элемент <link>, HTTP-заголовок Link и, только у Google, косвенные сигналы — редирект и Sitemap ^[1], ^[4]. Яндекс описывает первые два способа ^[12].

По отношению к странице (классификация по ^[1], ^[4], ^[5], ^[12]):

По тому, кто выбрал адрес (терминология Search Console): «Каноническая страница, выбранная пользователем» (User-declared canonical) и «Каноническая страница, выбранная Google» (Google-selected canonical) ^[8]. Справка предупреждает: «There is no guarantee that Google will choose your preferred canonical», но указание учитывается ^[8].

Как применяется на практике

Параметры и метки. Для адресов с GET-параметрами и метками (UTM, from и подобными) Яндекс рекомендует директиву Clean-param в robots.txt ^[12]. В отличие от запрета Disallow, директива позволяет передать основному URL «некоторые накопленные показатели» ^[14]. Синтаксис и ограничения — в статье Директива Clean-param; см. также UTM-метки.

Фильтры и сортировки. Google относит отсортированные и отфильтрованные версии страниц к типичным дублям ^[3]. Если фильтр лишь меняет порядок товаров, canonical на основную версию соответствует требованию RFC 6596 о дублирующемся содержимом ^[1]. Сложнее со страницами фильтров, у которых есть собственный поисковый спрос. Отраслевые публикации предлагают смешанный подход, и это практика, а не норма поисковиков. В колонке Search Engine Journal (К. Гиббонс, 2025) советуют указывать canonical с отфильтрованных страниц на родительскую категорию, а комбинации фильтров, которые ищут пользователи, делать индексируемыми страницами с самоссылающимся canonical ^[16]. По данным блога сервиса Ahrefs (С. Андервуд, обн. 2025), когда краулинговый бюджет не главная забота, canonical — «arguably» лучшее решение, но страницам фильтров с поисковым потенциалом автор разрешает индексирование и отмечает, что у каждого способа (canonical, noindex, robots.txt) есть издержки ^[17]. Яндекс в таком случае может и сам не учесть canonical: одно из условий — неканонические страницы полнее отвечают на запрос ^[12].

Пагинация. Google: «Don't use the first page of a paginated sequence as the canonical page» — каждой странице серии нужен свой канонический адрес ^[6]. Это согласуется с RFC 6596, где пример «page-2 → page-1» приведён как неверный, а canonical на страницу «Показать всё» — как допустимый вариант надмножества ^[1]. Атрибуты rel="next" и rel="prev" Google больше не использует, хотя другие поисковики, по его словам, могут их учитывать ^[6]. В справке Яндекса «Канонический адрес страницы» пагинация отдельно не описана ^[12]. См. Пагинация.

Мультиязычные версии. Canonical не заменяет hreflang. Google не использует для канонизации элементы rel="canonical" с атрибутами hreflang, lang, media или type — для альтернативных версий нужен rel="alternate" ^[4]. Канонической должна быть страница на том же языке или, если её нет, на лучшем заменяющем языке ^[4]. См. hreflang.

Перепечатка (синдикация). Распространённый совет «партнёр ставит canonical на оригинал» Google сейчас не рекомендует; по русской версии справки, «Наиболее эффективное решение – попросить партнеров заблокировать индексирование вашего контента» ^[5]. В Яндексе такой canonical не сработал бы и потому, что указывает на другой домен ^[12]. Это важно для СМИ, которые обмениваются материалами. См. Перепечатка.

Смена адреса сайта. Для переезда на www или без www Яндекс допускает canonical, но советует редирект 301 или 302, а для перехода на HTTPS — только редирект ^[12]. См. 301-редирект, Главное зеркало.

Сайты на JavaScript. Google считает лучшим способом задавать канонический адрес в исходном HTML: «The best way to set the canonical URL is to use HTML» ^[7]. Менять его скриптом на другой адрес не следует; если элемент всё же добавляется скриптом, он должен быть единственным rel="canonical" на странице: «Conflicting or multiple rel="canonical" link tags may lead to unexpected results» ^[7]. См. JavaScript SEO.

Google и Яндекс: где подходы различаются

Как измерить или проверить

Формулы или метрики у канонического адреса нет: проверяется, какой адрес указан и какой выбрал поисковик.

Google Search Console.

• Инструмент проверки URL. Показывает «Каноническую страницу, выбранную пользователем» и «Каноническую страницу, выбранную Google» ^[8]. Выбранный Google адрес виден только в данных проиндексированной версии: проверка опубликованной страницы (live test) «cannot predict whether or not the tested version will be considered canonical» ^[8]. Google советует начинать разбор проблем именно с этого инструмента ^[5].
• Отчёт об индексировании страниц. Статусы, связанные с canonical ^[9]:
  • «Вариант страницы с тегом canonical» (Alternate page with proper canonical tag) — страница помечена как альтернатива проиндексированной и корректно указывает на каноническую, действий не требуется;
  • «Страница является копией. Канонический вариант не выбран пользователем.» (Duplicate without user-selected canonical) — страница дублирует другую и не указывает предпочтительную;
  • «Страница является копией. Канонические версии страницы, выбранные Google и пользователем, не совпадают» (Duplicate, Google chose different canonical than user) — Google считает, что другой URL лучше подходит на роль канонического.
• После исправлений Google может держать страницы в одном кластере дублей до двух недель; для важных адресов можно запросить переиндексацию, но у функции есть квоты ^[5].

Яндекс Вебмастер. Результат проверяют в разделе «Индексирование» → «Страницы в поиске», блок «Исключённые страницы» ^[12]. Для дублей там есть статус «Удалено: Дубль», а в выгружаемом архиве — DUPLICATE ^[13]. Страница, которая должна выпасть из поиска, исключается в течение трёх недель после посещения роботом, на больших сайтах дольше ^[13].

Ручная проверка (порядок редакции по ^[1], ^[4], ^[7], ^[12]):

1. В исходном коде страницы — ровно один <link rel="canonical">, и он внутри <head> ^[4].
2. В HTTP-заголовках нет второго, противоречащего указания через Link ^[4].
3. Если canonical вставляет JavaScript — в инструментах разработчика браузера сверить отрисованный код с исходным ^[5], ^[7].
4. Канонический адрес абсолютный, без фрагмента # ^[4], ^[12].
5. Канонический адрес открывается без редиректа ^[1], ^[12] и без ошибки 4xx ^[1]; не закрыт от индексирования ^[12]; совпадает с адресом в Sitemap и во внутренних ссылках ^[4].

Мини-инструмент «Генератор и проверка rel="canonical"»

Инструмент готовится к запуску; ниже описано, как он будет работать. До запуска пользуйтесь инструментом проверки URL Search Console ^[8] и разделом «Страницы в поиске» Яндекс Вебмастера ^[12].

Инструмент работает в браузере: запросов к сайту он не отправляет и введённые адреса и код не сохраняет. Он помогает составить корректное указание и найти типичные ошибки, но не гарантирует, что поисковая система выберет указанный адрес: canonical остаётся подсказкой ^[3], ^[12].

Режим А — генератор.

• Вход: адрес страницы, которую нужно сделать канонической. Опции: «убрать UTM и служебные параметры» (список редактируется: utm_*, from и другие), «убрать #фрагмент», «привести к https», «слеш на конце: как есть / добавить / убрать».
• Выход: элемент <link rel="canonical" href="https://mediatrone.ru/seo/kanonicheskiy-adres/…" target="_blank" rel="noopener">, вариант HTTP-заголовка Link: <…>; rel="canonical" для PDF и строка Clean-param: для найденных параметров с пометкой «проверьте, что параметр не меняет содержимое страницы» ^[14].
• Предупреждения: относительный адрес дополняется до абсолютного ^[4], ^[12]; фрагмент # ^[4]; адрес на http при наличии https ^[4]; параметры отслеживания в каноническом адресе ^[4].

Режим Б — проверка вставленного кода. Пользователь вставляет HTML страницы или блок <head>, по желанию — адрес самой страницы и HTTP-заголовки. Инструмент повторяет пункты 1, 2 и 4 ручной проверки и дополнительно предупреждает: canonical на другой домен или поддомен («Google может учесть, Яндекс не учтёт») ^[5], ^[12]; одновременно стоит noindex ^[4]; на элементе есть атрибуты hreflang, lang, media или type, с которыми Google его для канонизации не использует ^[4].

Проверка по адресу страницы (загрузка чужого сайта, код ответа канонического URL) требует серверной части и в инструмент не входит; цепочки перенаправлений разбирает инструмент статьи Цепочка редиректов, правила 301 составляет генератор в статье 301-редирект.

Как пользоваться. Новая страница — режим А: скопируйте готовый элемент в <head> шаблона. Готовая страница — режим Б: вставьте код страницы и устраните предупреждения, затем после переобхода проверьте результат в Search Console и Вебмастере.

Пример условный. Введён адрес http://example.com/catalog/shoes?utm_source=mail&sort=price#top, отмечены «привести к https», «убрать UTM» и «убрать фрагмент». Инструмент выведет <link rel="canonical" href="https://example.com/catalog/shoes?sort=price">, строку Clean-param: utm_source и предупреждение: «Параметр sort оставлен. Если он лишь меняет порядок товаров, решите, должен ли он входить в канонический адрес».

Ошибки, ограничения и спорные вопросы

Canonical — подсказка. Google может выбрать другую страницу «for various reasons» ^[3]. Яндекс перечисляет случаи, когда указание не учитывается ^[12]:

1. неканонические страницы на момент обхода полнее отвечают на запрос, и их содержимое существенно отличается;
2. канонический адрес недоступен роботу — перенаправляет на другую страницу или закрыт от индексирования;
3. канонический адрес находится на другом домене или поддомене;
4. указано несколько канонических адресов;
5. указана цепочка канонических адресов (например, example.com/1 → example.com/2 → example.com/3).

Относительные адреса: стандарт и практика расходятся. RFC 6596 разрешает относительный IRI ^[1], а поисковики строже: Google относительные пути поддерживает, но не рекомендует ^[4], Яндекс просит абсолютный путь ^[12]. Это не ошибка стандарта; надёжнее следовать требованиям поисковиков (вывод).

Несколько указаний и конфликт методов. RFC 6596 рекомендует один canonical на ресурс ^[1]. Google советует не указывать разные канонические адреса разными методами — например, один в Sitemap, другой в rel="canonical" — и не сочетать элемент с HTTP-заголовком, потому что так легче ошибиться ^[4]. Яндекс при нескольких канонических адресах указание не учитывает ^[12].

Canonical вне <head>. Google принимает элемент <link rel="canonical"> только в разделе <head> ^[4].

canonical + noindex, robots.txt, удаление URL. Noindex полностью убирает страницу из поиска Google, поэтому для канонизации внутри сайта Google его не рекомендует и предпочтительным решением называет rel="canonical" ^[4]. robots.txt для канонизации тоже не подходит: заблокированные адреса могут попасть в индекс без содержимого ^[4]. Инструмент удаления URL скрывает из поиска все версии страницы ^[4].

Фрагменты #. Указывать адрес с фрагментом как канонический Google не рекомендует ^[4].

Ошибки CMS и взлом. Некоторые CMS и плагины прописывают canonical на нежелательные адреса; Google советует сообщить об ошибке разработчику CMS ^[5]. При взломе злоумышленники добавляют кросс-доменный rel="canonical" на спам-сайт, и Google может выбрать такой адрес ^[5]; риск злонамеренного использования связи описан и в разделе 7 RFC 6596 ^[1].

Слеш на конце. Для дублей «со слешем / без слеша» Яндекс не рекомендует canonical, так как он «может игнорироваться», и советует редирект ^[13]. Главную страницу это не касается: http://example.com и http://example.com/ Яндекс считает одинаковыми ^[13].

Спорные вопросы.

• Кросс-доменный canonical. Позиции систем различаются (см. таблицу «Google и Яндекс» выше), и усреднять их нельзя: сайту, ориентированному на обе системы, надёжнее не полагаться на кросс-доменный canonical (вывод).
• Фильтры. Документация задаёт только рамки: canonical — для дублей и надмножеств ^[1], сортировки и фильтры — типичный источник дублей ^[3]. Как поступать со страницами фильтров, у которых есть спрос, решает практика: отраслевые авторы советуют смешанный подход и признают издержки каждого способа ^[16], ^[17], а руководство SE Ranking подчёркивает, что «в каждом конкретном случае canonical нужно рассматривать индивидуально» ^[18].

Canonical и соседние механизмы

Частые вопросы

Связанные термины

• Дубли страниц
• 301-редирект
• Директива Clean-param
• noindex / Мета-тег robots
• hreflang
• Пагинация
• Главное зеркало / Зеркало сайта
• Индексация
• Карта сайта (sitemap.xml)
• robots.txt