Канонические ссылки: rel=canonical на практике

Атрибут rel=canonical — один из самых полезных и одновременно самых неправильно используемых инструментов технического SEO. Одной строкой в коде страницы можно навести порядок с сотнями параметрических адресов, а можно случайно выбросить из индекса половину каталога. Разница — в понимании того, как поисковики трактуют этот сигнал.

Канонический адрес — это предпочтительная версия страницы из группы похожих или одинаковых. Указывая canonical, вы говорите поисковой системе: «у этого содержимого есть несколько адресов, но главный — вот этот, показывай в выдаче его и собирай сигналы на нём».

В этой статье — практика: как правильно прописывать canonical, где он нужен, где вреден, как поисковики относятся к нему на самом деле и как проверить, что всё работает так, как задумано.

Как устроен rel=canonical

Канонический адрес указывается в секции head страницы тегом link с атрибутом rel со значением canonical и атрибутом href с полным адресом предпочтительной страницы. Для файлов, у которых нет HTML-разметки, например PDF, тот же сигнал можно передать HTTP-заголовком Link.

Есть несколько технических требований, которые нужно соблюдать неукоснительно:

• адрес должен быть абсолютным — с протоколом и доменом;
• тег должен находиться в head, а не в body — в теле документа поисковики его игнорируют;
• на странице должен быть только один canonical — при нескольких противоречивых поисковик проигнорирует все;
• канонический адрес должен отдавать код 200 и быть открыт для индексации;
• тег должен присутствовать в исходном HTML, а не добавляться скриптом после загрузки — так надёжнее для обоих поисковиков.

Рекомендация, а не директива

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

Если вы указали каноническим адрес A, но все внутренние ссылки ведут на адрес B, в карте сайта стоит B, а содержимое A и B заметно отличается, поисковик может проигнорировать ваш canonical и выбрать B. В Google Search Console это отображается как «Google выбрал другую каноническую страницу, нежели пользователь». В Яндекс Вебмастере — как исключение страницы с указанием причины и выбранного адреса.

Поэтому canonical работает надёжно только тогда, когда все остальные сигналы с ним согласованы. Это главный принцип, и большинство проблем возникает именно из-за его нарушения.

Canonical, редирект или noindex

Три инструмента часто путают, хотя они решают разные задачи.

Практическое правило выбора: если дублирующая страница не нужна людям — редирект. Если нужна людям, но копирует другую — canonical. Если нужна людям, уникальна, но не должна быть в поиске — noindex.

Самоссылающийся canonical

Самоссылающимся называют canonical, который указывает на адрес той же страницы. Казалось бы, зачем странице говорить, что главная версия — она сама? На практике это полезная страховка.

Любая страница может получить «паразитные» версии: кто-то сослался на неё с UTM-меткой, рекламная система добавила идентификатор клика, партнёр приписал реферальный код. Если на странице стоит самоссылающийся canonical с чистым адресом, все эти варианты автоматически указывают на оригинал, и дубли не размножаются.

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

Где canonical нужен в интернет-магазине

Интернет-магазины — главная территория канонических ссылок, потому что каталог порождает множество адресов с похожим содержимым.

Сортировки и отображение

Адреса вида ?sort=price, ?order=desc, ?view=list, ?limit=60 показывают тот же набор товаров в другом порядке или виде. Канонической здесь всегда выступает базовая страница категории без параметров.

Фильтры без спроса

Комбинации фильтров, которые никто не ищет, — «синие куртки 48 размера с капюшоном от определённого бренда дешевле пяти тысяч» — получают canonical на родительскую категорию. Комбинации с реальным спросом, напротив, оформляются как самостоятельные посадочные с собственным каноническим адресом.

Товар в нескольких категориях

Если карточка доступна по путям /muzhskoe/obuv/model и /rasprodazha/model, выберите один основной адрес и укажите его каноническим на обоих. Ещё лучше — сделать так, чтобы у товара был единственный адрес, независимый от категории.

Варианты товара

Цвета и размеры одной модели с одинаковым описанием могут иметь canonical на основную карточку. Но если у варианта есть свой поисковый спрос — например, конкретный цвет популярного смартфона ищут отдельно, — разумнее оставить его самостоятельным и уникализировать.

Где canonical нужен в блогах и на контентных сайтах

• Версии для печати и AMP-страницы — canonical на основную статью.
• Статьи с параметрами отслеживания из рассылок и соцсетей — самоссылающийся canonical отрезает метки.
• Синдикация контента. Если ваша статья перепубликована на партнёрской площадке, можно попросить партнёра поставить кросс-доменный canonical на оригинал. Поисковики поддерживают межсайтовые канонические ссылки, хотя и учитывают их как ещё более мягкую подсказку.
• Комментарии с постраничной разбивкой — если каждая страница комментариев дублирует текст статьи, canonical на основную версию.

Пагинация: частая ловушка

Пожалуй, самая распространённая ошибка — ставить на все страницы пагинации canonical на первую страницу. Логика понятна: «это же одна категория». Но содержимое второй, третьей и последующих страниц разное — на них другие товары или статьи. Поисковик видит, что canonical указывает на страницу с иным содержимым, и либо игнорирует его, либо перестаёт сканировать глубокие страницы. В итоге товары, доступные только со страниц пагинации, хуже индексируются.

Правильный подход: каждая страница пагинации имеет самоссылающийся canonical. Чтобы избежать дублирования мета-тегов, к title добавляют номер страницы, а текстовое описание категории выводят только на первой. Исключение — страница «показать все», если она существует и грузится быстро: тогда canonical со всех страниц пагинации можно направить на неё.

Типичные ошибки

Особенно опасна первая ошибка. Она часто возникает при неправильной настройке SEO-плагина или шаблона, когда в поле canonical по умолчанию подставляется адрес главной. Одно обновление темы — и через пару недель в индексе остаётся только главная страница. Поэтому после любых изменений шаблонов проверяйте canonical хотя бы на нескольких типах страниц.

Как проверить канонические адреса

1. Просмотр кода страницы. Откройте исходный код и найдите тег canonical в head. Убедитесь, что он один, адрес абсолютный и правильный.
2. Краулер. Массовая выгрузка всех страниц с их каноническими адресами позволяет найти страницы, у которых canonical не совпадает с собственным адресом, ведёт на редиректы или ошибки.
3. Проверка URL в Search Console. Показывает, какой адрес указан пользователем и какой выбрал Google.
4. Страницы в поиске в Яндекс Вебмастере. Исключённые неканонические страницы с указанием, на какой адрес они склеены.
5. Сверка с картой сайта. Все адреса в sitemap должны быть каноническими — то есть canonical каждого из них указывает на него самого.

Проводите такую проверку после каждого крупного обновления сайта и как минимум раз в квартал в рамках планового технического аудита.

Canonical и мультиязычные сайты

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

Частая ошибка — ставить canonical со всех языковых версий на основную, например русскую. В этом случае поисковик склеивает их, и англоязычная или казахстанская версия перестаёт показываться пользователям в своих регионах. Hreflang при этом теряет смысл, поскольку ссылается на неканонические страницы.

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

Как внедрять canonical на большом сайте

На проекте с десятками тысяч страниц правка канонических адресов — потенциально опасная операция. Ошибка в шаблоне затронет сразу целый тип страниц. Поэтому внедряйте изменения поэтапно.

1. Составьте правила для каждого типа страниц: какие параметры отбрасываются, куда указывает canonical у фильтров, пагинации, вариантов товаров.
2. Проверьте логику на тестовой копии сайта краулером.
3. Выкатите изменения на один тип страниц, например только на сортировки каталога.
4. Через две-три недели оцените отчёты индексации и трафик по затронутым страницам.
5. Если всё в порядке, распространите правила на следующий тип.

Такой подход медленнее, но позволяет поймать ошибку на небольшой группе страниц, а не на всём сайте сразу.

Итог

Rel=canonical — мощный инструмент консолидации сигналов, но он работает только в согласованной системе. Указывайте абсолютный адрес, размещайте тег в head, используйте самоссылающийся canonical на всех индексируемых страницах, не ставьте канонические ссылки на страницы с другим содержимым и не смешивайте их с noindex.

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