Проверка канонических адресов начинается не с тега, а с вопроса: совпадает ли то, что вы считаете главной версией страницы, с тем, что выбрал поисковик. В половине проектов, приходящих ко мне на диагностику, эти два ответа не совпадают, и владелец узнаёт об этом, когда посадочная перестаёт находиться по своему же запросу. Тег стоит, синтаксис верный, валидатор молчит, а страницы в поиске нет. Ниже — механика того, как canonical принимает решения за вас, и что смотреть, чтобы поймать расхождение до падения трафика.
Что делает канонический адрес и почему это подсказка, а не приказ
Атрибут rel="canonical" — ссылка в секции <head>, которой страница сообщает поисковику: «у меня есть двойники, главным считай вот этот адрес». Тот же смысл передаётся HTTP-заголовком Link: <https://site.ru/file.pdf>; rel="canonical" — так помечают файлы без HTML-разметки: PDF, изображения, выгрузки.
Ключевое, что переворачивает работу с тегом: canonical не обязателен к исполнению, и Яндекс, и Google описывают его как рекомендацию. Директива — это 301-й редирект и Disallow в robots.txt: сервер физически не отдаёт страницу или робот на неё не заходит. Рекомендация — мнение сайта, которое робот сверяет с наблюдениями и может отклонить: если содержимое канонической цели заметно отличается, если цель закрыта от индексации или не существует, если сотни разных страниц указывают на один адрес. Базовая механика самого атрибута разобрана отдельно — Rel=canonical — канонические ссылки, здесь речь про случаи, когда тег начинает вредить.
Практический вывод: canonical нельзя использовать как инструмент управления индексом. Им нельзя закрыть страницу от поиска, гарантированно склеить два разных документа или заменить редирект после смены адресов. Он умеет одно — помогать выбрать главную версию среди похожих документов. Из попыток натянуть на него чужую функцию растут все ошибки ниже.
Как поисковик выбирает канон, когда сигналы противоречат друг другу
При обходе робот собирает: адрес из тега, адрес из HTTP-заголовка, адрес из карты сайта, внутренние ссылки, внешние ссылки, наличие редиректов, hreflang, схожесть текстов. Дальше решается задача кластеризации: похожие документы объединяются в группу, внутри назначается представитель — версия, которая покажется в выдаче.
Когда сигналы совпадают, представителем становится адрес из canonical. Когда расходятся, вес получает фактическое поведение сайта, а не его декларация. Пример: страница объявляет каноническим адрес А, но всё меню и карта сайта ведут на Б, а с А стоит редирект на Б. Робот увидит, что сайт живёт на Б, и выберет Б. Отсюда первое правило технического аудита: canonical должен подтверждать то, что сайт и так делает. Тег на адрес без слеша при сервере, редиректящем на версию со слешем, бесполезен. Тег на HTTP при сайте на HTTPS вреден: робот тратит обход впустую.
Второе правило: у канонической страницы тег должен указывать на саму себя. Самоссылающийся canonical снимает целый класс проблем — от параметров в адресе до сессионных хвостов. Страница без него не защищена ни от чего: любой адрес с добавленным параметром робот увидит как самостоятельный документ.
Canonical на главную со всех страниц и другие ошибки внутри тега
Самая разрушительная конфигурация — когда каждая страница объявляет каноническим адресом главную. Возникает почти всегда одинаково: адрес прописали статически в шаблоне шапки вместо подстановки текущего. Робот заходит на карточку товара, читает «главная важнее меня», и при тонком содержимом карточка выпадает из поиска. Внешне сайт цел, ошибок сервера нет, трафик уходит за две-три недели, а причина не видна ни в одном отчёте о критических ошибках. В Вебмастере статус таких страниц меняется на «неканоническая» — что он означает, разобрано в материале Неканоническая страница.
Родственная ошибка — canonical на раздел вместо самой страницы, по логике «карточки похожи, пусть вес идёт на категорию». Логика поисковика другая: карточка и категория — разные документы, поэтому тег часто игнорируется, и результат непредсказуем: часть карточек склеится, часть нет, а пропорция меняется от обхода к обходу.
Третья группа — синтаксис адреса. Относительный путь href="/catalog/" работает, но при сбое базового адреса в шаблоне превращается в мусор, поэтому пишите полный адрес с протоколом и доменом. Дальше — расхождения по протоколу, по www, по слешу, по регистру: для робота /Catalog/ и /catalog/ — два разных адреса.
Четвёртая — цепочки и петли. Цепочка: А канонизирует Б, Б канонизирует В; робот не всегда проходит её до конца, и часть страниц зависает в промежуточном состоянии. Петля: А указывает на Б, Б на А — оба указания отбрасываются. Пятая — два разных canonical на странице: один в шаблоне, второй от SEO-плагина. При конфликте игнорируются оба, и страница остаётся без указания вовсе.
Конфликт canonical с редиректом, robots.txt и noindex
Когда canonical сталкивается с другими техническими сигналами, работает жёсткая иерархия: реализованное на уровне сервера и протокола всегда сильнее написанного в разметке.
| Сочетание сигналов | Что делает робот | Как исправлять |
|---|---|---|
| Canonical указывает на адрес, с которого стоит 301-й редирект | Идёт по редиректу, тег теряет смысл, страница остаётся в подвешенном состоянии | Переписать тег на конечный адрес цепочки |
| Canonical указывает на адрес, закрытый в robots.txt | Не может прочитать цель, склейка не выполняется, обе версии живут отдельно | Открыть целевой адрес для обхода либо сменить цель тега |
| На странице одновременно canonical и метатег noindex | Страница просится и в склейку, и вон из индекса; результат непредсказуем | Оставить одно: noindex для выброса, canonical для склейки |
| Canonical ведёт на страницу, отдающую 404 или 410 | Тег отбрасывается, текущая страница индексируется как самостоятельная | Найти живой адрес или поставить самоссылающийся тег |
| Canonical на странице, которая сама отдаёт 301 | Тег не читается — робот получает заголовок редиректа раньше тела ответа | Убрать тег, он тут бесполезен по определению |
| Canonical указывает на другой домен при разном содержимом | Отклоняется как недостоверный, иногда трактуется как манипуляция | Применять только для зеркал и синдикации идентичных текстов |
Пару «canonical плюс noindex» ставят из соображения «перестрахуемся, вдруг одно не сработает». Получается наоборот: в худшем сценарии noindex переносится на каноническую цель, и вы теряете из поиска именно ту страницу, которую продвигали. Это выключатель с двумя положениями: либо документ участвует в поиске, либо нет.
Со связкой robots.txt похоже: закрытая от обхода страница не читается, значит, её тег не будет прочитан. Если вы закрыли фильтры в robots и проставили на них canonical, работает только первое, а адреса продолжают попадать в индекс по ссылкам. Разница инструментов разобрана в статье Мета-тег Robots и файл robots.txt. Третий конфликт — попытка заменить тегом редирект после смены структуры адресов. При переезде нужен именно 301: он передаёт ссылочный вес и убирает старый адрес из выдачи. Canonical оставляет старый адрес рабочим, и робот сохраняет обе версии — последствия показаны в разборе Отличие 301 от 302 редиректа.
Пагинация и фильтры: где canonical помогает, а где вредит
В пагинации ошибаются чаще всего, потому что интуитивное решение неверно. Интуиция подсказывает канонизировать страницы 2, 3, 4 листинга на первую. На практике робот перестаёт считать их самостоятельными и хуже доходит до товаров, которые на них лежат. В крупном каталоге так теряются карточки, ссылки на которые есть только с глубоких страниц.
Рабочая схема другая: на каждой странице пагинации самоссылающийся canonical. Тексты и описания выводятся только на первой, а title второй и дальше получает пометку с номером страницы, чтобы заголовки не дублировались. Атрибуты rel="next" и rel="prev" Google больше не использует как индексирующий сигнал, но вреда от них нет.
С фильтрами каталога логика обратная: тег нужен, но не сплошняком. Первая группа — фильтры со спросом, обычно одиночные значения вроде бренда, размера, цвета. Под них есть запросы в Вордстате, и такие страницы делают полноценными посадочными: свой title, заголовок, короткий текст, самоссылающийся canonical. Вторая группа — сортировки и пересечения трёх и более параметров; они канонизируются на чистый адрес раздела.
Отдельная история — GET-параметры, не меняющие содержимое: рекламные метки, идентификаторы сессий, хвосты аналитики. Здесь самоссылающийся canonical решает почти всё, потому что версия с параметром отдаёт в теге адрес без параметра. Почему такие адреса попадают в индекс, описано в материале Страницы дубли с GET-параметрами. Дополнительно в robots.txt Яндекса помогает директива Clean-param: она прямо говорит роботу, какие параметры игнорировать при склейке.
Как проверить канонические адреса массово
Единичная проверка делается за десять секунд: открываете исходный код страницы и ищете строку с rel="canonical". Но она почти ничего не даёт — ошибка обычно системная, сидит в шаблоне и повторяется на тысячах адресов. Нужен обход всего сайта краулером с выгрузкой четырёх колонок: адрес страницы, код ответа, значение canonical, код ответа по адресу из canonical. Дальше идите по списку конкретных проверок.
| Что проверяем | Признак проблемы в выгрузке | Насколько срочно |
|---|---|---|
| Массовое указание на один адрес | Одно значение повторяется на сотнях страниц с разным содержимым | Критично, чинить в тот же день |
| Отсутствие тега | Пустая ячейка canonical у продвигаемых страниц | Высокая, особенно при параметрах в адресах |
| Целевой адрес не отдаёт 200 | В колонке кода ответа по цели стоит 301, 404 или 5xx | Высокая |
| Цепочки и расхождения в написании | Адрес из canonical сам имеет canonical на третий адрес либо отличается протоколом, www, слешем | Средняя |
| Два тега на странице | Краулер помечает страницу как имеющую несколько canonical | Высокая, оба указания аннулируются |
| Конфликт с noindex | На одной строке есть и canonical, и запрет индексации | Высокая |
| Расхождение с картой сайта | В sitemap.xml лежит адрес, канонизированный на другой | Средняя, ломает переобход |
Две тонкости, из-за которых проверка даёт ложный результат. Первая: часть сайтов подставляет canonical скриптом на стороне браузера, и краулер в режиме простого запроса HTML такой тег не увидит — проверяйте выборочно с включённым выполнением скриптов, расхождение значений само по себе проблема. Вторая: закрытые в robots.txt адреса краулер по умолчанию пропускает, поэтому нужен отдельный проход с отключённым учётом robots. Канонические адреса нельзя чинить в отрыве от редиректов и карты сайта, поэтому берите за основу общий порядок работ — Технический SEO-аудит своими руками: пошаговый чек-лист из 40 пунктов.
Что смотреть в Вебмастере и Search Console
Краулер показывает, что вы объявили. Панели поисковых систем — что из этого принято. Расхождение между двумя картинами и есть предмет разбора.
В Яндекс.Вебмастере откройте «Индексирование» — «Страницы в поиске», вкладку исключённых. Статус «Неканоническая» означает, что робот прочитал ваш тег и согласился: страница исключена намеренно, и если в списке лежат продвигаемые адреса, у вас та самая системная ошибка в шаблоне. Статус «Дубль» означает обратное: робот объединил страницы сам, не спрашивая тег, и рядом указывает выбранного представителя. Если этот адрес отличается от вашего canonical — тег отклонён, и надо искать, какой сигнал его перебил. Ключевые посадочные добавьте в «Мониторинг важных страниц», чтобы узнавать о выпадении сразу, а не через месяц по факту падения трафика.
В Google Search Console нужны отчёт «Индексирование страниц» и инструмент проверки URL. В проверке сравнивайте две строки: канонический адрес, указанный пользователем, и канонический адрес, выбранный Google. Не совпали — тег отклонён, и в отчёте появляются статусы «Страница является копией, канонический вариант не выбран пользователем» либо «Google выбрал другую каноническую страницу». Второй читается буквально: система нашла более достоверный вариант, обычно тот, на который ведёт больше внутренних ссылок.
После правок запросите переобход: в Вебмастере через «Переобход страниц», в Search Console через запрос на индексирование. Иначе исправленный тег будет ждать планового визита робота, а на крупных сайтах это недели. Заодно убедитесь, что в sitemap.xml лежат только канонические адреса. Общая логика поиска и устранения дублей разобрана в статье Дубли страниц в Яндексе: как найти, почему возникают и как устранить.
Когда canonical не нужен и когда он не сработает
Тег лепят по инерции, хотя не нужен он в трёх случаях: на сайте из нескольких десятков страниц без параметров в адресах, без фильтров и пагинации — там нечего склеивать; на страницах с уникальным содержимым без двойников; вместо редиректа при смене адреса или как способ убрать страницу из поиска — для этого есть noindex.
Не сработает: при склейке страниц с существенно разным содержимым — робот сравнивает тексты и отклоняет указание. Между языковыми версиями нужен hreflang, а canonical просто выбросит все версии, кроме одной. Не сработает на странице, закрытой в robots.txt, и на чужом домене, разметку которого вы не контролируете. Не сработает и тогда, когда внутренние ссылки массово ведут на неканонический адрес: поведение сайта перевесит декларацию.
Частые вопросы
Можно ли поставить canonical на страницу, закрытую в robots.txt? Технически можно, практически бессмысленно: робот не зайдёт на закрытый адрес и не прочитает тег. Работать будет только запрет обхода, а страница может остаться в индексе без описания, если на неё ведут ссылки.
Сколько ждать результата после исправления тега? На небольшом сайте изменения видны через одну-две недели после переобхода. На каталоге в десятки тысяч адресов пересборка занимает от месяца до квартала: робот приходит на разные разделы с разной частотой.
Нужен ли canonical, если уже стоит 301-й редирект? Нет. Страница, отдающая редирект, не возвращает тело ответа, и тег из неё никто не прочитает. Ставьте самоссылающийся тег на конечном адресе цепочки.
Что делать, если Google выбрал другую каноническую страницу? Проверьте по порядку: куда ведут внутренние ссылки на эту страницу, какой адрес лежит в sitemap.xml, нет ли редиректа с вашего канонического адреса. Обычно расхождение объясняется тем, что весь сайт ссылается на один адрес, а тег указывает на другой.
Как быть с AMP и мобильной версией на поддомене? Ускоренная версия канонизируется на основную. Для мобильного поддомена схема парная: мобильная указывает canonical на десктопную, десктопная — на мобильную атрибутом rel="alternate" с медиазапросом.
Что важнее — canonical или карта сайта? Это сигналы одного уровня, и противоречие ослабляет оба. В sitemap.xml должны лежать только адреса, канонизированные сами на себя, иначе вы каждым обходом отправляете роботу два взаимоисключающих указания.
Коротко
- Canonical — рекомендация, а не директива. Поисковик сверяет его с редиректами, внутренними ссылками и картой сайта и отклоняет, если тег противоречит фактическому поведению сайта.
- Больше всего потерь дают три ошибки: указание на главную со всех страниц, цепочки и петли, конфликт тега с редиректом, robots.txt или noindex.
- Каждая индексируемая страница должна иметь самоссылающийся canonical с полным адресом — в том написании, в каком её отдаёт сервер.
- Пагинацию канонизируют на саму себя, а не на первую страницу. Фильтры делят на спросовые посадочные и служебные, которые склеиваются с адресом раздела.
- Проверка состоит из двух половин: краулер показывает объявленное, панели Вебмастера и Search Console — принятое. Разбирается расхождение между ними.
- После правок нужен принудительный переобход и чистая карта сайта, иначе исправления будут доходить до индекса неделями.
Если после обхода вы получили список расхождений и не понимаете, что чинить первым, а что не трогать вовсе, приходите на консультацию по техническому SEO — разберём вашу выгрузку по адресам и составим порядок правок под конкретную структуру сайта. Продвижение веду лично, в SEO с 2005 года, вы общаетесь со мной напрямую, а не с менеджером. Если задача шире и нужно продвижение сайта в Яндексе целиком, начнём с технической диагностики.
Увеличьте позиции и продажи вашего сайта
Профессиональное SEO-продвижение с гарантией результата. Выберите подходящую услугу:
Остались вопросы по продвижению?
Меня зовут Анатолий Кузнецов, я SEO-оптимизатор с 20-летним стажем. Разберу ваш сайт, отвечу на вопросы и подскажу, что улучшить для роста позиций в Яндексе и Google.
Связаться со мной →
Старт 
Стандарт 
Премиум 
Комментарии
Ефимия Долгушина
Прогнала сайт краулером — на всех 1400 карточках товара canonical стоит на адрес категории. Разработчик говорит, что так задумано, чтобы вес шёл на раздел. В Вебмастере при этом карточек в поиске меньше половины. Кто прав?
Анатолий Кузнецов автор
Прав Вебмастер. «Вес идёт на раздел» — это представление из середины нулевых, оно не описывает то, как сейчас работает кластеризация. Карточка и категория — разные документы: разный текст, разные характеристики, разная цена. Поисковик сравнивает содержимое и в части случаев отклоняет ваше указание, а в части соглашается — отсюда и половина карточек в поиске вместо всех. Состояние нестабильное, при следующем обходе пропорция сдвинется. Ставьте на каждой карточке самоссылающийся canonical с полным адресом. Категорию продвигают внутренней перелинковкой и текстом на самой категории, а не отъёмом страниц у карточек. После правки закиньте на переобход первую сотню карточек с максимальным спросом, остальные подтянутся сами.
Прохор Загряжский
У меня в Search Console 800 страниц со статусом «Google выбрал другую каноническую страницу». Тег везде самоссылающийся, проверял руками десяток адресов. Куда копать?
Анатолий Кузнецов автор
Копайте в внутренние ссылки и карту сайта — при самоссылающемся теге почти всегда дело в них. Выгрузите из отчёта колонку с адресом, который выбрал Google, и сравните её с вашими адресами посимвольно: чаще всего расходится слеш на конце, регистр или наличие www. Дальше посмотрите, куда ведут ссылки из меню, хлебных крошек и карточек — если они ведут на вариант без слеша, а сервер редиректит на вариант со слешем, робот видит цепочку и делает собственный вывод. Третье место, куда стоит заглянуть, — sitemap.xml: там нередко лежит старая выгрузка с адресами в другом написании. Приведите все три источника к одному виду, и статус уйдёт за пару обходов.
Нинель Барсукова
Подскажите, страницы пагинации в блоге — канонизировать на первую или оставлять на себя? Читала оба совета и оба со ссылкой на официальную справку.
Анатолий Кузнецов автор
Оставлять на себя. Совет канонизировать на первую страницу устарел вместе со старой схемой обработки rel=next и rel=prev, но продолжает кочевать по статьям. Проблема с ним практическая: канонизировав вторую и последующие страницы на первую, вы говорите роботу, что смотреть их незачем, и ссылки на старые записи, которые есть только оттуда, начинают доходить хуже. В блоге это заметно на материалах старше года — они перестают переобходиться. Правильная схема: самоссылающийся тег на каждой странице списка, текст и описание раздела только на первой, а в title второй и дальше добавляется номер страницы, чтобы заголовки не совпадали. Ссылку «показать все» имеет смысл делать, только если полный список грузится быстро.
Устин Мохначёв
Плагин ставит canonical и он же добавляет noindex на архивы по датам. Это тот самый конфликт, о котором вы пишете, или для архивов нормально?
Виринея Перепёлкина
В исходном коде страницы нашла сразу два тега canonical с разными адресами. Один явно от темы, второй от SEO-плагина. Какой из них учтётся?
Анатолий Кузнецов автор
Ни один. При двух конфликтующих указаниях робот отбрасывает оба и решает сам — страница фактически остаётся без canonical со всеми последствиями по параметрам и дублям. Чинится это в шаблоне: находите в файле шапки строку с жёстко прописанным link rel=canonical и удаляете её, оставляя вывод плагина. Проверять надо не одну страницу, а по одному образцу каждого типа — главная, категория, карточка, статья, страница пагинации, результат поиска по сайту. Темы часто вставляют такой тег только в отдельные шаблоны, и на главной дубля не будет, а на карточке будет. После правки прогоните сайт краулером: он умеет помечать страницы с несколькими canonical отдельным флагом, и вы сразу увидите, все ли места вычищены.
Аполлинарий Стрешнев
Перевёл сайт на HTTPS полгода назад, редиректы настроены. Только сейчас заметил, что во всех тегах canonical остался http. Насколько это критично и надо ли что-то дополнительно делать после исправления?
Анатолий Кузнецов автор
Критично ровно настолько, насколько сильно у вас размазаны сигналы. Ситуация такая: тег указывает на адрес, который отдаёт 301 на защищённую версию. Робот идёт по редиректу, до конечной страницы добирается, но само указание теряет смысл и перестаёт защищать вас от дублей с параметрами. Плюс каждый обход тратится на лишний переход. Исправляется одной заменой в шаблоне или настройкой базового адреса в плагине — обычно там просто осталась старая строка с протоколом. После правки сделайте три вещи: пересоберите sitemap.xml, чтобы в нём не осталось http-адресов, проверьте, что главное зеркало в Вебмастере указано с защищённым протоколом, и отправьте на переобход десяток ключевых страниц. Дальше остальное подтянется само.
Милана Бурдейная
А есть смысл ставить canonical на страницах с utm-метками, если мы их и так закрыли в robots через Disallow с звёздочкой?
Гурий Ясенев
Хочу закрыть от индексации раздел с распродажей, но чтобы вес не потерялся. Поставил canonical на главную категорию. Правильно ли я понял, что так делать нельзя?
Злата Кочубеева
Краулер показывает canonical у половины страниц пустым, а если открыть страницу в браузере и посмотреть код через инструменты разработчика — тег на месте. Кому верить?
Ермолай Тряпицын
В интернет-магазине один и тот же товар лежит в трёх категориях, адреса отличаются путём. Какой из трёх делать каноническим и по какому принципу выбирать?
Лукерья Свешникова
Статус «Неканоническая» в Вебмастере висит на 300 страницах, которые я никогда не канонизировала. Тег на них самоссылающийся. Это глюк панели или я чего-то не понимаю?
Тихон Обольянинов
Мы публикуем свои статьи ещё и на отраслевом портале. Они просят поставить canonical с их копии на наш оригинал, но говорят, что это ничего им не стоит. Есть ли тут подвох для нас?