Rel canonical: что это и как правильно использовать
Rel canonical — это атрибут, которым вы указываете поисковику каноническую (основную) версию страницы среди её дублей: «вот таких адресов у меня несколько, но настоящий — этот». Дубли при этом продолжают работать для людей — фильтры фильтруют, метки считаются, версии для печати печатаются: тег адресован только роботам. В отличие от редиректа, посетитель остаётся на той странице, куда пришёл, — подсказка адресована только роботам. Canonical решает проблемы дублей от фильтров, параметров и сортировок, но у него есть коварная особенность: это рекомендация, которую поисковик вправе проигнорировать. По масштабу последствий это один из самых недооценённых тегов: правильная канонизация большого каталога способна изменить судьбу тысяч страниц одним шаблоном — в обе стороны. Разберём, когда canonical уместен, когда нужен 301, как всё прописать и какие ошибки встречаются чаще всего.
Что такое canonical простыми словами
Технически это строка в блоке <head> страницы — одна из самых коротких настроек в SEO с одним из самых длинных списков последствий:
<link rel="canonical" href="https://site.ru/catalog/divany/" />
Она говорит роботу: «страница, которую ты сейчас читаешь, — вариант вот этой основной; индексируй и ранжируй её, а сигналы обеих склей». Ключевое слово — рекомендация: поисковик сверяет подсказку со своим мнением (похож ли контент, какая версия полезнее) и может выбрать канонической другую страницу. Поэтому canonical работает надёжно только между действительно похожими страницами.
Canonical, 301 или noindex: что выбрать
Три инструмента постоянно путают — между тем они решают разные задачи:
| Инструмент | Что делает | Когда применять |
|---|---|---|
| 301 редирект | Физически перенаправляет и людей, и роботов; старый URL умирает | Адрес изменился навсегда; зеркала; переезд |
| rel canonical | Люди остаются на странице; роботам указана основная версия | Дубли, которые должны работать для людей: фильтры, параметры, сортировки |
| noindex | Страница доступна людям, но исключена из индекса; сигналы не передаются | Служебные страницы: поиск по сайту, корзина, личный кабинет |
Быстрый тест: нужна ли страница-дубль людям? Нет — 301. Да, и она вариант другой страницы — canonical. Да, но в поиске ей делать нечего и «склеивать» не с чем — noindex. Развёрнутый разбор про сами дубли — в статье про дублированный контент.
Ещё один способ запомнить разницу — по судьбе посетителя: после 301 человек оказывается на другом адресе; при canonical остаётся, где был; при noindex тоже остаётся, но страница «не существует» для выдачи. Выбирая инструмент, вы отвечаете на вопрос «что должно случиться с человеком и что — с роботом» — и ответы у этих троих разные.
7 ситуаций, где нужен canonical
- GET-параметры и UTM-метки.
/page/?utm_source=...— тот же контент с хвостом; canonical на чистый URL склеивает их (подробнее о параметрах в URL). Это дежурный случай, ради которого self-canonical ставят «по умолчанию»: рекламные и реферальные хвосты плодятся без вашего участия. - Фильтры и сортировки каталога.
?sort=price&color=redпорождает тысячи комбинаций — все указывают на основную категорию (кроме фильтров, из которых вы осознанно делаете посадочные страницы под спрос: у таких — свой self-canonical, свой title и свой контент; список кандидатов в посадочные даёт кластеризация семантики). - Пагинация. Вторые-десятые страницы списка: сегодня чаще рекомендуют self-canonical на каждой странице пагинации, а не на первую. Логика: страницы 2+ содержат УНИКАЛЬНЫЙ контент (другие товары), склейка их с первой говорит роботу «дальше первой можно не ходить» — и глубокие карточки теряют путь к индексации. Первую страницу дополнительно укрепляют как основную (на неё ведут внутренние ссылки и sitemap), а «канониклить всё на первую» оставляют для случаев, когда пагинация — реальные дубли (одинаковый контент, разбитый параметрами вида
?page=без смысла). - Версии для печати и упрощённые версии страниц.
- Один товар в нескольких категориях, доступный по разным путям (
/divany/model-x/и/rasprodazha/model-x/), — canonical на основную карточку, чтобы отзывы, поведенческие и ссылки копились в одном месте. - Кросс-доменные дубли: легально размещаете статью на двух своих сайтах — canonical с копии на оригинал.
- Self-canonical по умолчанию. Каждая страница ссылается сама на себя — дешёвая страховка от случайных параметров-дублей; большинство CMS так и делает.
Где canonical не место: склейка зеркал сайта (http/https, www) и переехавшие страницы — это работа 301 редиректа: там старый адрес не должен жить.
Способы указать canonical
Основной способ — строка в <head> (пример выше): абсолютный URL с протоколом и доменом, одна на страницу. Есть и дополнительные механики:
- HTTP-заголовок
Link— для файлов без HTML-головы (PDF, изображения-дубли): сервер отдаётLink: <https://site.ru/doc.pdf>; rel="canonical"в заголовках ответа. Настраивается на сервере, спасает документы, у которых «негде» разместить тег. - Косвенные сигналы. Поисковики учитывают и подсказки без тега: какой URL указан в sitemap, куда ведут внутренние ссылки, какая версия в редиректах. Если тег говорит одно, а сигналы другое — доверие к тегу падает; приводите всё к согласию.
В популярных CMS canonical расставляют SEO-модули автоматически, но проверить стоит — автоматика не знает про ваши осознанные посадочные из фильтров:
- WordPress: SEO-плагины ставят self-canonical по умолчанию; точечные переопределения — в настройках страницы.
- Bitrix: модули SEO или свойства инфоблоков; на больших каталогах canonical шаблонизируется по правилам разделов.
- Tilda и конструкторы: self-canonical обычно зашит платформой; проверьте исходный код пары страниц — и особенно страниц с параметрами.
Канонической указывайте страницу, которая реально открывается кодом 200 (не редирект, не 404) и не закрыта от индексации.
Как проверить
- Исходный код страницы (Ctrl+U) — найдите строку
rel="canonical"и посмотрите, куда она ведёт. Особенно на страницах с параметрами: откройте один и тот же URL с UTM-хвостом и без — canonical должен совпадать. - Краулер по всему сайту — колонка canonical в отчёте мгновенно показывает аномалии: страницы без тега, цепочки, канониклы на 404/редиректы. Для каталога это единственный реалистичный способ проверки.
- Яндекс Вебмастер: исключённые страницы со статусом «неканоническая» — список того, что склеилось; проверьте, что там нет нужных посадочных. Точечная проверка — инструментом анализа URL.
- Search Console: инструмент проверки URL показывает «канонический URL, выбранный Google» — если он отличается от вашего, Google с вами не согласился, и это сигнал разобраться: чаще всего противоречат внутренние ссылки или похожесть контента.
- Контрольный ритм: после любых работ с шаблонами и переездов — выборочная проверка; раз в квартал — прогон краулером. Canonical ломается тихо: сломанный шаблон расставит неверные теги на тысячи страниц за один деплой.
Частые ошибки
- Canonical на нерелевантную страницу. «Склеим все дубли на главную» — поисковик увидит, что контент разный, проигнорирует подсказку, а доверие к вашим canonical в целом снизится. Симптом в GSC: у страниц массово «канонический URL, выбранный Google» ≠ ваш — робот вежливо сообщает, что перестал вас слушать.
- Цепочки: A → B, B → C. Робот путается; canonical всегда должен вести на конечную каноническую версию.
- Canonical + noindex вместе. Противоречие: «склей меня с той страницей» и «меня не существует» одновременно. Поведение непредсказуемо — выбирайте что-то одно.
- Относительные URL и ошибки в протоколе — canonical на http-версию при https-сайте тихо ломает склейку; относительный путь в теге браузеру понятен, а роботам в отдельных сценариях — нет: используйте только абсолютные адреса.
- Каноникл на закрытую или редиректящую страницу — подсказка в никуда, робот её отбросит.
- Canonical на пагинации «всё на первую» в большом каталоге — карточки со страниц 5+ месяцами не попадают в индекс: роботу сказали, что дальше первой смотреть нечего (разбор — в блоке про пагинацию).
- Забытый canonical после переезда. Теги, указывающие на старый домен или http-версию, тихо саботируют переезд — включите проверку canonical в чек-лист любого переезда.
Кейс: фильтры каталога до и после склейки
Обезличенный, но типовой сценарий. Симптомы: у магазина мебели в индексе тысячи URL вида ?color=&sort=&page=, Вебмастер массово помечает их «малоценными», позиции категорий стоят. Действия: self-canonical на всех страницах, canonical с параметров-сортировок на базовые категории, три осознанных фильтра-посадочных («диваны угловые», «диваны кожаные», «диваны раскладные») исключены из склейки и получили свой контент. Что происходит дальше: за несколько недель робот пересматривает параметры-дубли, число страниц в поиске сжимается в разы — и это хорошо: вес и лимиты обхода перестают размазываться по мусору, категории и фильтры-посадочные начинают расти. Мораль кейса: canonical — не «уборка ради красоты», а перераспределение ресурсов робота в пользу страниц, которые зарабатывают.
Canonical, hreflang и мультиязычность
Частый конфликт международных сайтов: hreflang говорит «вот русская и казахская версии страницы», а canonical с обеих указывает на русскую — и казахская выпадает из своей выдачи. Правило простое: каждая языковая версия канонична сама себе (self-canonical), а hreflang связывает их между собой. Canonical поверх языков ставится только для настоящих дублей в рамках одного языка.
Canonical и краулинговый бюджет
У робота ограниченный лимит страниц на обход вашего сайта. Когда тысячи параметров-дублей претендуют на обход, лимит сгорает на мусор, а новые статьи и обновления ждут очереди. Склейка дублей canonical’ом (плюс запрет явно мусорных параметров в robots.txt) возвращает бюджет обхода реальным страницам — на больших каталогах это один из самых недооценённых эффектов правильной канонизации.
Canonical и нейровыдача
Небольшой, но растущий бонус: генеративные выдачи (Нейро, AI Overviews) работают с теми же каноническими версиями страниц. Когда факты о товаре или услуге размазаны по десятку URL-дублей, модели сложнее собрать согласованную картину; чистая канонизация означает, что цитируемая версия — одна, свежая и правильная. Это часть той же гигиены данных, что и llms.txt: одна сущность — один адрес — один набор фактов.
Canonical и Яндекс: нюанс
Обе поисковые системы трактуют canonical как рекомендацию, но на практике ведут себя по-разному: Яндекс чаще следует указанию буквально и охотно выкидывает неканонические страницы из поиска, Google чаще «имеет собственное мнение» и пересматривает ваш выбор по своим сигналам. Из этой разницы — два практических вывода. Для Яндекса ошибочный canonical опаснее: неверный тег быстро выносит нужные страницы из поиска — после массовой расстановки первым делом проверьте Вебмастер, не исчезло ли лишнее. Для Google важнее согласованность сигналов: если внутренние ссылки, sitemap и содержимое противоречат тегу, он выберет каноническую страницу сам — и вы узнаете об этом только из отчёта «канонический URL, выбранный Google». Стратегия одна на обе системы: тег + сигналы должны говорить хором.
Чек-лист
- У каждой страницы есть self-canonical с абсолютным URL.
- Дубли от параметров/фильтров указывают на основную версию.
- Осознанные посадочные из фильтров canonical НЕ склеивает.
- Канонические цели отвечают кодом 200 и открыты для индексации.
- Нет цепочек canonical и связки с noindex.
- Пагинация: self-canonical на страницах 2+ (если контент уникален).
- Языковые версии каноничны сами себе, hreflang связывает их.
- Файлы-дубли (PDF) закрыты HTTP-заголовком Link.
- После переезда canonical не указывает на старый домен/протокол.
- Вебмастер/GSC проверены: склейка прошла по плану, нужное не выпало; краулер прогнан по каталогу.
Canonical — тонкий инструмент: правильно расставленный, он тихо чинит дубли, возвращает роботу бюджет обхода и собирает сигналы страниц воедино; расставленный бездумно — так же тихо прячет нужные страницы из поиска, и заметите вы это по проседанию трафика месяцы спустя. Разница между этими исходами — один вдумчивый час с чек-листом выше и контрольная проверка после каждого изменения шаблонов. Проверка canonical и дублей входит в наш аудит сайта — а быстрый взгляд на ваш сайт мы бесплатно дадим на экспресс-аудите.
