Один материал нередко доступен по нескольким адресам: с UTM-меткой, параметром сортировки, печатной версией или другим вариантом слеша. Для посетителя содержание почти одинаково, а для робота это разные URL. Элемент rel="canonical" сообщает, какой адрес владелец сайта считает основным.

Что такое canonical простыми словами

Canonical — ссылка на предпочтительную версию страницы. Поисковая система может объединить сигналы похожих URL и показывать в выдаче выбранный адрес. Это помогает не делить внешние ссылки и статистику между дублями, а роботу — реже тратить обход на повторяющееся содержание.

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

Canonical не удаляет страницу, не перенаправляет посетителя и не запрещает обход. Неканонический URL по-прежнему открывается в браузере.

Когда канонический URL действительно нужен

  • страница открывается с рекламными и аналитическими параметрами: ?utm_source=...;
  • CMS создаёт несколько адресов одного материала или товара;
  • сортировка и представление меняют URL, но не основное содержание;
  • есть версия для печати или близкая техническая копия;
  • одинаковый материал опубликован в нескольких разделах;
  • один документ доступен как HTML и, например, PDF.

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

Не объединяйте через canonical страницы, которые решают разные задачи: товары разных цветов с самостоятельным спросом, статьи на разные темы или фильтры с уникальной полезной выдачей. Чем сильнее различается основной контент, тем выше вероятность, что рекомендация будет проигнорирована.

Как правильно указать rel=canonical

Для HTML-страницы элемент помещают внутрь <head>. Используйте полный HTTPS-адрес:

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

Абсолютный URL надёжнее относительного: он явно задаёт протокол и домен и снижает риск того, что тестовая копия сайта начнёт ссылаться сама на себя. Целевая страница должна возвращать статус 200, быть доступна роботу и не содержать запрета на индексирование.

Canonical в HTTP-заголовке

Для PDF и других документов без HTML можно передать канонический адрес в ответе сервера:

Link: <https://example.ru/guides/report/>; rel="canonical"

Не задавайте одновременно разные адреса в HTML и HTTP-заголовке. Технически оба способа поддерживаются, но конфликт сложнее заметить и диагностировать.

Типовые сценарии настройки

Метки и параметры

Страницы /article/ и /article/?utm_source=dzen содержат один материал. На обеих версиях укажите чистый адрес https://example.ru/article/. Внутренние ссылки и sitemap также должны вести на него без меток.

HTTP, HTTPS, www и слеш

Для вариантов протокола и хоста одного canonical недостаточно: настройте постоянный серверный редирект на единую версию. Canonical на конечной странице должен совпадать с адресом после редиректа. Яндекс отдельно рекомендует использовать редирект при переходе с HTTP на HTTPS.

Печатная версия

Если /article/print/ полностью повторяет статью, она может ссылаться canonical на /article/. Но если печатная версия нужна пользователям из поиска как отдельный документ, сначала оцените её самостоятельную ценность — автоматическое склеивание не всегда оправдано.

Публикация на другом домене

Google поддерживает canonical между доменами для синдицированного контента, хотя не гарантирует выбор указанного адреса. У Яндекса правило строже: в документации указан canonical в пределах одного домена или поддомена, а междоменная ссылка может быть проигнорирована. Для публикации в партнёрских медиа заранее согласуйте индексирование копии и не полагайтесь на один тег во всех поисковых системах.

Пагинация, фильтры и сортировка

Страницы пагинации обычно содержат разные элементы, поэтому не следует механически направлять страницы 2, 3 и далее на первую. Практичный базовый вариант — self-referencing canonical для каждой страницы серии: /news/page/2/ указывает на себя. Так робот может обходить ссылки на более старые материалы и оценивать каждую часть списка.

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

Сортировка «сначала новые» или «по цене» часто меняет порядок, а не состав. Тогда canonical на основную категорию логичен. Если фильтр радикально меняет содержимое, поисковик может не признать страницы дублями и проигнорировать такую ссылку.

Canonical, редирект, noindex и robots.txt

ИнструментКогда использоватьЧто происходит
rel="canonical"Похожие страницы должны оставаться доступнымиПоисковику передаётся предпочтительный URL
301/308 redirectСтарый или лишний URL больше не нуженПользователь и робот переходят на новый адрес
noindexСтраница не должна участвовать в поискеURL исключается из индекса после повторного обхода
robots.txtНужно ограничить обход раздела или параметровРобот не загружает содержание; это не надёжный способ удалить уже известный URL

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

Закрывать дубль в robots.txt и одновременно ждать, что поисковик увидит его canonical, — противоречие: робот не сможет загрузить HTML с тегом. Google прямо не рекомендует robots.txt как инструмент канонизации.

Согласуйте все сигналы сайта

Надёжная канонизация строится не на одном элементе. Основная версия должна фигурировать во внутренних ссылках, XML Sitemap, hreflang и структурированных данных. На неё же должны вести редиректы со старых адресов. Когда sitemap содержит URL A, canonical указывает на B, а меню ведёт на C, поисковику приходится самостоятельно разрешать конфликт.

  1. Выберите единую схему адресов: HTTPS, основной хост, регистр и формат слеша.
  2. Используйте эти адреса во всех внутренних ссылках.
  3. Добавляйте в sitemap только канонические индексируемые URL.
  4. Для hreflang указывайте каноническую страницу того же языка.
  5. Не создавайте цепочки A → B → C: каждая копия должна ссылаться сразу на C.

Для клиентского JavaScript лучше отдать canonical уже в исходном HTML. Google рекомендует не менять его скриптом: два последовательно увиденных значения делают сигнал неоднозначным.

Частые ошибки canonical

  • Цель перенаправляет или возвращает ошибку. Ссылка должна вести прямо на рабочий индексируемый документ.
  • Несколько тегов. Плагины CMS и шаблон могут независимо добавить разные canonical.
  • Один URL для всех страниц. Ошибка в переменной шаблона иногда направляет весь сайт на главную.
  • Canonical на noindex. Основная версия одновременно просит включить и не включать себя в поиск.
  • Слишком разный контент. Нельзя передать релевантность любой страницы другой только с помощью тега.
  • Тестовый домен. Относительные настройки окружения или копия шаблона оставляют ссылки на staging.
  • Параметр в каноническом URL. Основным случайно становится рекламный или сессионный адрес.
  • Несовпадение с og:url. Это не всегда критическая SEO-ошибка, но создаёт разные идентификаторы страницы для поиска и соцсетей.

Как проверить canonical страницы

Начните с исходного HTML, а не только с инспектора элементов: найдите rel="canonical" в секции <head>. Убедитесь, что тег один, URL абсолютный и соответствует странице. Затем откройте целевой адрес и проверьте конечный статус, редиректы, robots и доступность.

Проверка мета-тегов по URL показывает canonical вместе с Title, Description, Robots и H1. Это помогает обнаружить ошибку шаблона, но решение о выборе основной страницы всё равно проверяют в панелях поисковых систем.

В Google Search Console инструмент проверки URL показывает canonical, заявленный владельцем, и URL, выбранный Google. В Яндекс Вебмастере сведения об исключённых дублях находятся в разделе индексирования. Расхождение не всегда означает сбой: сначала сравните содержание страниц и все сопутствующие сигналы.

Проверяйте не один пример, а выборку: статьи, категории, пагинацию, фильтры, URL с UTM, старые адреса и документы. Шаблонная ошибка обычно охватывает целый тип страниц.

Как расследовать расхождение

Если поисковик выбрал другой адрес, составьте пару «заявленный URL — выбранный URL» и сравните ответы сервера, содержимое и ссылки. Проверьте, не попадает ли выбранная версия в навигацию чаще основной, не имеет ли она больше внешних ссылок и не обновляется ли быстрее. Затем найдите конфликтующие canonical, редиректы, hreflang и записи в sitemap.

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

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

Чек-лист перед публикацией и после переноса

  1. На каждой индексируемой странице есть один осмысленный canonical.
  2. Адрес абсолютный, использует HTTPS и основной домен.
  3. Цель возвращает 200 без промежуточного редиректа.
  4. Целевая страница не закрыта noindex или robots.txt.
  5. Дубликат и основная версия действительно совпадают по смыслу.
  6. Внутренние ссылки, sitemap, hreflang и структурированные данные согласованы.
  7. Пагинация не направлена целиком на первую страницу без причины.
  8. Нет цепочек и нескольких конфликтующих тегов.
  9. Проверены URL с параметрами и старые адреса после миграции.
  10. Выбор поисковой системы проконтролирован после повторного обхода.

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

Обязателен ли canonical на каждой странице?

Нет, поисковая система умеет выбирать основную версию самостоятельно. Но self-referencing canonical делает предпочтение явным и упрощает единообразную работу шаблонов.

Передаёт ли canonical ссылочный вес?

Корректнее говорить об объединении сигналов похожих URL, а не о гарантированной передаче фиксированного «веса». Решение о канонической странице остаётся за поисковой системой.

Можно ли направить canonical на главную?

Только если страница действительно является дублем главной, что встречается редко. Массовая ссылка внутренних страниц на главную обычно будет проигнорирована и может скрыть настоящую ошибку архитектуры.

Как быстро поисковик учтёт изменение?

После повторного обхода и обработки страниц. Точного срока нет: он зависит от частоты сканирования и масштаба изменений. Обновите sitemap и запросите проверку важных URL в вебмастерах.

Для полной технической ревизии используйте также руководство по проверке мета-тегов страницы. А если canonical должен совпадать с идентификатором карточки ссылки, проверьте настройку Open Graph и og:url.

Источники: руководство Google по каноническим URL и документация Яндекс Вебмастера.