Пять конфликтов canonical, которые Google решает за вас

Тег canonical — это подсказка, а не правило. Так написано на странице Google о канонизации: канонический URL Google выбирает сам, опираясь на редиректы, наличие URL в Sitemap, предпочтение HTTPS и кластеры hreflang, а не только на ваш тег. Когда эти сигналы спорят, ваш тег проигрывает. Вот пять конфликтов, из-за которых так происходит.

Canonical — это директива или подсказка?

Подсказка. На странице What is canonicalization прямо сказано, что указание канонического URL — это подсказка, а не правило. Google объединяет страницы, которые считает дублями, в кластер и помечает ту, что кажется ему наиболее полной и полезной для пользователя. Ваш тег — лишь один из входных сигналов, и у него есть место в опубликованном порядке силы.

Две рекомендации стоит держать перед глазами до разбора конфликтов. Не используйте robots.txt для канонизации: закрытый в нём URL Google всё равно может проиндексировать, просто без содержимого. И не указывайте для одной страницы разные канонические URL разными способами.

Может ли canonical вести на страницу с noindex, закрытую или редиректящую?

Технически может, и каждый из этих вариантов обесценивает тег. Google не рекомендует выбирать каноническую страницу внутри одного сайта с помощью noindex, потому что страница тогда полностью выпадает из поиска, и называет rel=canonical предпочтительным решением. Указывать URL, закрытый в robots.txt, ещё хуже: документация по noindex прямо говорит, что краулер, который не может загрузить страницу, никогда не увидит на ней никаких правил.

Редиректы — тонкий случай, потому что в собственном порядке Google они стоят выше тегов canonical. В документации разобран ровно один сценарий: HTTPS-страница, которая ведёт пользователей на HTTP или через HTTP либо содержит canonical на HTTP-версию, указана как конфликтующий сигнал, а редиректы с HTTPS на HTTP заставляют Google очень сильно предпочитать HTTP. Что происходит в остальных случаях, когда canonical указывает на редиректящий URL, документация не описывает, так что проверьте цель сами через наш чекер редиректов и направьте тег на URL, отвечающий кодом 200.

Что будет, если Sitemap и тег canonical расходятся?

Этот случай Google называет в рекомендациях напрямую: не указывайте один URL в Sitemap, а другой для той же страницы через rel=canonical. Наличие в Sitemap — более слабый из двух сигналов, поэтому обычно побеждает тег, но каждый отправленный URL предлагается как канонический, и Google всё равно приходится решать, какие страницы дубли. Починка скучная: генерируйте Sitemap из того же источника, который пишет теги canonical, и проверяйте файл нашим валидатором Sitemap. Что вообще должно попадать в файл, разбирает руководство по лучшим практикам Sitemap.

Конфликтует ли rel=canonical с hreflang?

Регулярно, и сильнее всего от этого страдают многоязычные сайты. Указание Google такое: канонической должна быть страница на том же языке, а если её нет — на наиболее подходящем языке-заменителе. Если canonical русской страницы ведёт на английский URL, вы сами попросили Google выбросить русскую.

Ещё две детали с тех же страниц. Аннотация rel=canonical с атрибутами hreflang, lang, media или type для канонизации не используется вовсе, для этого есть rel=alternate. А принадлежность к кластеру — сигнал сама по себе: в примере Google страницы de-de и de-ch, ссылающиеся друг на друга, предпочтительнее в роли канонических, чем страница de-at, оставшаяся вне кластера. Ошибки аннотаций, которые ломают такие кластеры, разобраны в нашем руководстве по hreflang.

Нужен ли canonical, указывающий сам на себя?

Google это рекомендует. В его рекомендациях сказано размещать ссылку rel=canonical на самой канонической странице, это и есть самоссылающийся canonical.

По-настоящему всё ломается в шаблонах, которые собирают тег из URL запроса. Посетитель пришёл с меткой отслеживания — и тег уже указывает на вариант с параметром, то есть каждый клик по объявлению объявляет свой собственный канонический URL. Пример Google для URL, который вы вряд ли хотите видеть в выдаче, — карточка товара с параметром gclid. Ещё два требования с той же страницы: используйте абсолютные URL вместо относительных и никогда не указывайте в canonical фрагмент URL, потому что фрагменты Google обычно не поддерживает.

Работает ли canonical вне head или через JavaScript?

Вне head — нет. Google пишет, что элемент link rel=canonical принимается, только если он находится в секции <head> HTML, и добавляет, что как минимум эта секция должна быть валидным HTML. Именно здесь всё и рвётся: незакрытый тег выталкивает ваш canonical в body, где он уже не считается.

JavaScript поддерживается, но не приветствуется. На странице основ JavaScript SEO сказано, что Google Поиск подхватывает внедрённый canonical при рендеринге. А страница о канонизации просит задавать URL в исходном HTML и следить, чтобы JavaScript не менял его на другой. Если в исходник добавить нельзя, уберите его оттуда совсем и задавайте только через JavaScript. В любом случае отдавайте ровно один: Google предупреждает, что конфликтующие или множественные теги rel=canonical могут привести к непредсказуемому результату.

Как проверить, какой URL Google выбрал каноническим?

Инструмент проверки URL в Search Console показывает выбранный Google канонический URL рядом с тем, который объявили вы. Страница по устранению проблем добавляет то, что полезно знать заранее: даже после исправления контента страницы могут оставаться в кластере дублей до двух недель, и расходятся быстрее, когда различие между ними явное и значимое. Всё это не имеет смысла, если краулер вообще не добирается до страницы, а это пять минут проверки вашего robots.txt.