Статья:
Canonical — это HTML-тег, который говорит поисковику: «вот основная версия страницы, остальные копии считай её вариациями». Выглядит так:
<link rel="canonical" href="https://example.com/page/">
Тег ставится в <head> и решает одну задачу: не дать поисковику размазать вес страницы по нескольким адресам с одинаковым или почти одинаковым контентом. Ниже — не теория, а конкретные сценарии, команды для проверки и разбор реальных статусов Google Search Console.
Где canonical реально нужен — 4 рабочих сценария
1. Параметры и фильтры в URL. Интернет-магазин отдаёт один товар по адресам /tovar/, /tovar/?sort=price, /tovar/?color=red&utm_source=vk. Без canonical поисковик может проиндексировать все варианты как разные страницы и размыть между ними ссылочный вес. Подробнее о том, как правильно указывать canonical для подобных случаев — см. Alternate page with proper canonical: когда это норма, а когда — ошибка
.
2. www/без www, http/https. Если сайт технически отвечает на нескольких вариантах домена, канонический тег — не замена 301-редиректа, а дополнительный сигнал. Действие: сначала жёсткий 301 на основной домен на уровне сервера, потом canonical как подстраховка. Одного canonical без редиректа недостаточно — робот может продолжать заходить на старый вариант.
3. Пагинация листингов. Частая ошибка — ставить на страницы 2, 3, 4 листинга canonical на страницу 1. Так вы фактически просите Google не индексировать страницы 2+, и трафик с длинного хвоста запросов пропадает.
Действие: на страницах пагинации ставьте self-canonical — каждая страница указывает сама на себя (/catalog/page/2/ → canonical на /catalog/page/2/).
4. Синдикация и перепубликации. Отдали статью на VC.ru, Дзен или партнёрский блог — попросите площадку поставить canonical (или хотя бы rel=canonical / ссылку на оригинал) на вашу страницу. Иначе есть риск, что в выдаче окажется чужая копия, а не источник. Подробнее о подобных проблемах читайте в статье Похожие страницы плохо индексируются: как это выявить и починить .
Sitemap.xml в 2026: как составить, проверить и не слить crawl budget→Как проверить canonical у себя — пошагово
Быстрая ручная проверка одной страницы:
- Откройте страницу, нажмите
Ctrl+U(просмотр исходного кода). Ctrl+F→ введитеcanonical.- Смотрите на
href: адрес абсолютный (сhttps://и доменом), совпадает с тем адресом, который должен быть основным, и на странице нет второго конфликтующего тегаrel="canonical".
Проверка через HTTP-заголовок (актуально для PDF и файлов, где <head> физически нет):
curl -IL https://example.com/file.pdf
В ответе ищите строку вида:
Link: <https://example.com/file.pdf>; rel="canonical"
Если её нет и файл существует в нескольких копиях (например, с разными UTM в имени или на поддомене), это дыра — робот сам решит, что считать оригиналом.
Проверка через Google Search Console (для страниц, которые уже в индексе): Duplicate without user-selected canonical: как найти и починить проблему в Search Console — используйте раздел «Проверка URL», вставьте адрес → блок «Индексирование страницы». Там две строки:
- «Canonical, выбранный пользователем» — это тот адрес, что вы указали в теге;
- «Canonical, выбранный Google» — это тот адрес, который Google реально считает основным.
Если строки расходятся — это не баг интерфейса, а сигнал, что Google не доверяет вашему указанию. Причины обычно две: канонический адрес не отвечает 200 или контент на нём беднее, чем на «копии».
Массовая проверка (когда страниц не одна, а сотни или тысячи): Ручной перебор через GSC для крупного сайта нереален. Здесь работают массовые чекеры: Rush Analytics прогоняет список URL и показывает статус индексации и расхождения по каждому адресу разом, а PixelPlus проверяет до 5000 URL за проход и заодно отдаёт дату первой индексации в Яндексе и возраст кэша — удобно сверить это со списком адресов, на которые вы ставили canonical, и найти те, что Google так и не подхватил.
Разбор реальных статусов GSC — что значит и что делать
| Статус в GSC | Что произошло | Что делать |
|---|---|---|
| Дубликат, канонический URL не выбран пользователем | На странице вообще нет тега canonical, а Google нашёл похожий контент на другом адресе | Добавить self-canonical на все версии страницы, включая параметризованные |
| Google выбрал другой canonical, отличный от указанного пользователем | Тег стоит, но Google его игнорирует | Проверить: указанный адрес отвечает 200, не закрыт noindex/robots.txt, и на нём достаточно контента (не тоньше, чем на «копии») |
| Страница является копией, но у неё есть canonical | Всё в порядке, просто информационный статус | Действий не требуется |
| Обнаружено, страница пока не проиндексирована | Google знает про URL, но не приоритизировал обход | Не связано с canonical напрямую — проверить внутреннюю перелинковку и краулинговый бюджет. При необходимости используйте руководство Почему страница не попала в индекс: диагностика по шагам, а не наугад . |
Частый практический кейс: страница висит в статусе «Дубликат, канонический URL не выбран пользователем» уже 3 недели после того, как вы поставили тег. Проверьте три вещи по порядку: 1) canonical действительно попал в отданный HTML (а не только в шаблон, который кэшируется CDN со старой версией) — смотрите curl в обход кэша с заголовком Cache-Control: no-cache; 2) на канонической странице код ответа 200, а не 301/404; 3) контент на канонической странице не тоньше, чем на дублях. Если всё верно, а Google так и не пересчитал — отправьте URL повторно через «Проверка URL → Запросить индексирование» в Search Console, либо ускорьте переобход внешним индексатором вроде SpeedyIndex, который прогоняет список адресов через собственную сеть для более быстрого повторного захода робота.
Типичные ошибки — если видите это, чините сразу
- Цепочка канонизации: страница A → canonical на B, B → canonical на C. Поисковики плохо проходят такие цепочки дальше одного шага. Правило: canonical всегда должен указывать на финальный адрес напрямую, без промежуточных звеньев.
- Canonical на закрытую страницу: тег указывает на URL с 404, 301 или
noindex. Это тупик для робота — он получает сигнал «показывай вон ту страницу», а та страница сама не подлежит показу. Проверяйте код ответа canonical-адреса черезcurl -ILпосле любого изменения структуры сайта. - Canonical на чужой домен без согласования: имеет смысл только в схеме синдикации, когда вы сами — вторичная площадка. Во всех остальных случаях вы дарите свою страницу в индексе другому сайту.
- Расхождение HTML-тега и HTTP-заголовка: если оба присутствуют и указывают на разные адреса, Google выбирает сам, обычно не то, что вы планировали. Проверяйте оба источника, особенно после миграции на новый CMS.
- Sitemap не совпадает с canonical: в карте сайта должны быть перечислены только канонические (предпочтительные) адреса. Если в sitemap попадают параметризованные URL с
?sort=, это прямой конфликт сигналов — Google получает от вас одновременно «это предпочтительный адрес» (из sitemap) и «нет, вот тот» (из canonical на самой странице).
Что делать после массового исправления canonical
Если вы почистили canonical сразу на десятках или сотнях страниц (например, после смены структуры каталога), не ждите пассивно естественного переобхода — это может занять недели. Соберите список изменённых адресов и прогоните его через сервис ускоренной индексации, например 2Index Ninja или тот же SpeedyIndex — так Google и Яндекс быстрее увидят обновлённые сигналы и пересчитают, какая версия страницы основная.
Связанные термины
- robots.txt и meta robots — определяют, какие страницы вообще разрешено обходить и индексировать; canonical на закрытой директиве работать не будет.
- noindex — отдельный жёсткий сигнал «не показывать в выдаче», в отличие от canonical, который лишь рекомендация.
- sitemap.xml — карта предпочтительных адресов; должна совпадать с canonical на страницах.
- Discovered / Crawled, currently not indexed — статусы GSC, где canonical часто оказывается корнем проблемы.
Для полного аудита перед запуском новых страниц используйте Чек-лист перед индексацией сайта: что реально проверяют Google, Яндекс и Bing .