rel="canonical" — это просьба, а не команда. Google принимает её как один из сигналов и может выбрать для индекса совсем другой URL, чем ты указал, — если контент, ссылки и sitemap говорят ему другое. Разбираем, как на самом деле работает консолидация дублей, три источника дублей, которые видел на 9 из 10 аудитов, и когда canonical надо заменить на noindex или 301, а не ставить поверх.
Канонический тег — самый недопонятый инструмент технического SEO. Половина верит, что это команда «индексируй вот эту страницу». Вторая половина вообще не ставит его, потому что «у нас и так одна страница на товар». Обе ошибаются. Разбираем по порядку.
Что canonical не делает
Он не редиректит. Пользователь как зашёл на страницу с параметром, так и останется на ней — canonical видят только роботы, в разметке head. Он не блокирует индексацию страницы, на которой стоит, — это не noindex. И главное: он не гарантирует, что Google покажет в выдаче именно ту страницу, которую ты назначил канонической.
Официально это называется консолидацией дублирующихся URL — подробности в документации Google по канонизации. Canonical — один из сигналов в этом процессе, наравне с 301-редиректами, внутренней перелинковкой, sitemap и совпадением контента. Не главный сигнал. Один из.
Самоссылающийся canonical: ставь всегда, даже если дублей нет
Правило по умолчанию: каждая страница должна содержать canonical на саму себя. Не потому что это что-то чинит прямо сейчас, а потому что это защита на будущее — от параметров, которые кто-то добавит в ссылку, от версий с UTM, от сортировки, которую включат через полгода. Страница без самоссылающегося canonical — открытая дверь для дублей, которых пока нет, но будут.
Когда Google выбирает не твою каноническую страницу
Вот тут начинается самое интересное — и самое раздражающее для тех, кто думает, что canonical это switch. Google может решить, что каноническая страница — не та, что ты указал, если:
- На альтернативный URL ведёт больше или более сильных ссылок — внешних или внутренних. Робот доверяет странице с большим весом, даже если ты пометил её как неосновную.
- Альтернативный URL проиндексирован раньше и у него накопилась история — это тоже сигнал «эта версия главная».
- Контент на страницах заметно различается, а не дублируется один в один. Тогда это для Google вообще не пара дублей, а две разные страницы — canonical просто проигнорируется, потому что консолидировать нечего.
- В sitemap лежит другой URL, чем тот, что указан как canonical. Противоречивые сигналы — Google разбирается сам, и не всегда в твою пользу.
Интернет-магазин мебели, 2024 год: на карточки с параметром цвета (?color=krasnyy) поставили canonical на чистый URL без параметра — всё правильно по учебнику. Но товар активно продвигали через прайс-агрегаторы, и у двух цветовых вариантов набралось в разы больше внешних ссылок, чем у «чистой» версии. Google месяцами держал в индексе именно параметрические URL, а не канонические. Починили не правкой тега, а убрав сам источник противоречия — перестали отдавать параметрические ссылки во внешние каналы и прибили страницы сортировки в robots.txt.
Проверить, что Google выбрал канонической на самом деле, можно только одним способом: «Проверка URL» в GSC → раздел «Индексирование» → строка «Пользовательская каноническая страница» против «Google выбрал другую каноническую страницу». Если во второй строке не пусто — у тебя именно эта ситуация.
Три источника дублей, которые встречаются чаще всего
1. Параметры и сортировка
UTM-метки, параметры фильтра, сортировка «по цене», «по популярности» — создают десятки версий одного URL. Canonical на базовую версию без параметров закрывает это почти полностью, но только если сам URL без параметров реально существует и доступен. Если фильтр «только по URL с параметром» — ставить canonical некуда, нужен другой подход, разбирал его в статье про SEO-фильтры интернет-магазина.
2. Протокол и www
http/https и с www/без www — должно быть настроено 301-редиректом на сервере, а canonical — подстраховка, а не основной механизм. Я видел сайты, где на обе версии домена отдаётся одинаковый контент без редиректа, а разработчик надеется на canonical, чтобы «разрулить» это программно. Так не работает — робот обходит обе версии, тратит на это краулинговый бюджет, и canonical лишь частично компенсирует то, что должно быть исправлено на уровне сервера.
3. Пагинация каталога
Самая спорная тема: Google официально рекомендует не ставить canonical со второй страницы листинга на первую, потому что контент разный. Ставить self-referencing canonical на каждую страницу пагинации — и всё. Подробный разбор пагинации каталога, где Яндекс и Google расходятся во мнениях, — в статье про пагинацию интернет-магазина.
Canonical vs noindex vs 301 — когда что
| Ситуация | Инструмент | Почему |
|---|---|---|
| Страница должна существовать для пользователя, но не нужна в индексе отдельно от основной | canonical | Передаёт сигналы качества и ссылочный вес на основную версию |
| Страница вообще не нужна в индексе, и пользователю её видеть незачем (служебная, тестовая, с параметром debug) | noindex | Прямая команда не индексировать — не рекомендация |
| Страница переехала или удалена навсегда, старый URL не нужен никому | 301 | Единственный способ передать и ссылочный вес, и трафик пользователей |
| Нужно временно скрыть страницу, но URL ещё понадобится | 302 + ничего из вышеперечисленного | 301 на время — ошибка, он воспринимается как постоянный |
Частая ошибка — вешать canonical на страницу, которая одновременно закрыта через noindex. Это противоречивый сигнал: canonical говорит «консолидируй сюда вес», noindex говорит «эту страницу не трогай вообще». Google в этом случае обычно слушает noindex и выбрасывает страницу из обработки консолидации, то есть canonical просто сгорает впустую.
Кросс-доменный canonical: синдикация контента
Если материал публикуется и на твоём сайте, и на партнёрском (синдикация, перепечатка с разрешения), canonical можно указать на домен-оригинал даже через границу доменов. Это легальный и рабочий способ не плодить дубли контента между сайтами — но работает он только если оба домена подтверждены в Search Console и площадка-перепечатчик реально ставит ссылку на оригинал, а не копирует её «для вида» без тега в head.
Частые ошибки, которые я вижу на аудитах
- Цепочки canonical. Страница A ссылается на B, B ссылается на C. Google может не дойти до конца цепочки и не консолидировать ничего. Canonical должен указывать сразу на финальную версию, без промежуточных прыжков.
- Относительный URL вместо абсолютного.
<link rel="canonical" href="/catalog/item">вместо полногоhttps://site.by/catalog/item— формально разрешено спецификацией, но увеличивает риск, что при миграции протокола или домена тег начнёт указывать не туда, куда думаешь. - Canonical на 404 или редиректящую страницу. Встречается после неаккуратных миграций — ссылка на то, чего уже нет. Сигнал просто теряется.
- Разные способы нормализации на разных страницах сайта. Где-то canonical с www, где-то без — противоречие на уровне всего домена, а не отдельной страницы.
Чеклист проверки своими руками
- Screaming Frog, краул всего сайта → отчёт «Canonicals» → фильтр «Missing» и «Non-Indexable Canonical».
- Выборочно 10-15 ключевых URL → GSC «Проверка URL» → сравни «Пользовательскую» и «Google выбрал» канонические страницы.
- Проверь, что sitemap.xml содержит именно канонические версии, а не параметрические дубли.
- Проверь на противоречие noindex + canonical одновременно — это баг, а не стратегия.
- На https/www — убедись, что редирект настроен на сервере, а не держится только на теге.
Про то, что бывает, когда Google в принципе отказывается индексировать страницу — не из-за выбора другого канонического URL, а потому что посчитал её малоценной целиком, — отдельный разбор в статье «Просканировано, но не проиндексировано». А в октябрьском дайджесте Google прямо сказал, что теряет доверие к сайтам с массой шаблонных страниц — писал об этом в разборе отчёта за октябрь. Дубли и неправильный canonical — ровно то, что такое доверие подрывает быстрее всего.
Официальная справка по нормализации URL, если хочешь первоисточник целиком, а не мой пересказ, — здесь.
Сколько у тебя на сайте страниц, где canonical вообще не прописан — ты проверял, или просто предполагаешь, что движок поставил его сам?