Тег canonical: коли він потрібен, типові помилки та перевірка

Канонічна адреса (canonical URL) це адреса, яку власник сайту вважає головною версією сторінки. Її вказують у head документа елементом link з атрибутом rel="canonical". Для файлів без HTML, наприклад PDF, ту саму інформацію можна передати в HTTP-заголовку Link.

Важливо розуміти межі цього механізму. Документація Google Search Central прямо описує canonical як сильний сигнал, але не директиву. Пошукова система порівнює кілька ознак: редиректи, атрибут rel canonical, наявність адреси в sitemap, внутрішні посилання, протокол HTTPS. Якщо сигнали суперечать один одному, остаточний вибір може не збігтися з вашим.

Також canonical не закриває сторінку від індексації й не заважає скануванню. Він не замінює ні noindex, ні правила в robots.txt. Його завдання вужче: зібрати сигнали дублів в одній адресі, щоб посилання, показники та вибір сторінки для видачі не розпорошувалися між копіями.

Докладніше про механізм: консолідація дублікатів URL у документації Google.

Дублі виникають частіше, ніж здається. Сторінка може відкриватися за адресою з параметрами відстеження, з сортуванням чи фільтром, у версії для друку, з www і без www, за HTTP і HTTPS, зі слешем у кінці й без нього. Для відвідувача це одна сторінка, для сканера їх кілька.

Типові випадки, де canonical доречний:

• Параметри відстеження. Адреси на кшталт ?utm_source=newsletter показують той самий вміст, що й чиста адреса.
• Фільтри й сортування. Каталог, відсортований за ціною, лишається тим самим каталогом.
• Версії для друку та AMP-подібні копії, якщо вони існують окремими адресами.
• Синдикований контент. Якщо ви публікуєте матеріал на іншому сайті, той сайт може вказати canonical на ваш оригінал. Міждоменний canonical допустимий.
• Кілька шляхів до однієї сторінки у CMS: категорія плюс дата, короткий і довгий URL.

Навіть коли дублів немає, самореферентний canonical, тобто вказівка сторінки на саму себе, вважається безпечною практикою для індексованих сторінок. Він захищає від випадкових варіантів адреси, які хтось додасть у посилання чи рекламну кампанію.

Якщо стару адресу треба прибрати назавжди, потрібен не canonical, а редирект. Про це наступний розділ.

Обидва інструменти консолідують сигнали, але діють по-різному. Редирект 301 переспрямовує і користувача, і сканер: стара адреса перестає бути доступною як окрема сторінка. Canonical лишає обидві адреси відкритими, а пошуковій системі лише підказує, яка з них головна.

Користуйтеся простим правилом:

1. Стара адреса більше не потрібна людям (змінили структуру, об'єднали сторінки, перейшли на HTTPS): ставте редирект 301.
2. Обидві адреси мають жити (параметри відстеження, фільтри, друк, синдикація): ставте canonical.
3. Не впевнені: спершу перевірте, чи справді потрібна друга адреса. Часто вона з'явилася випадково.

Окремо про поєднання. Canonical на адресу, яка сама редиректить, змушує сканер пройти зайвий крок, а сигнал стає нечітким. Canonical на сторінку з відповіддю 404 просто не працює. Canonical і noindex на одній сторінці дають змішаний сигнал: першим кажете «збери все на іншій адресі», другим «не показуй цю». Оберіть одне.

Сканер SEOAudit у такому разі окремо повідомляє про noindex разом із canonical на інший URL, бо це одна з найчастіших причин, чому сторінка зникає з видачі без очевидної причини.

Базовий приклад. Тег стоїть у head, адреса абсолютна, з HTTPS:

<head>
  <link rel="canonical" href="https://example.com/blog/canonical-guide">
</head>

Для PDF або іншого файлу без head canonical передається заголовком відповіді:

Link: <https://example.com/files/report>; rel="canonical"

Тепер поширена помилка: відносна адреса. Вона формально працює, але легко ламається, коли сторінку відкривають за іншим хостом чи протоколом.

<link rel="canonical" href="/blog/canonical-guide">

Виправлений варіант:

<link rel="canonical" href="https://example.com/blog/canonical-guide">

Сторінка з параметрами відстеження вказує на чисту адресу:

<!-- відкрито як https://example.com/pricing?utm_source=newsletter -->
<link rel="canonical" href="https://example.com/pricing">

І пара для багатомовного сайту. Кожна мовна версія вказує на саму себе, а не на іншу мову:

<!-- на https://example.com/uk/about -->
<link rel="canonical" href="https://example.com/uk/about">
<!-- на https://example.com/en/about -->
<link rel="canonical" href="https://example.com/en/about">

Якщо на обох сторінках поставити canonical на англійську версію, українська випаде з розгляду як дубль, а hreflang перестане працювати.

1. Кілька різних canonical на одній сторінці

Такі пари виникають, коли тег додають і тема, і плагін. Пошукова система може проігнорувати обидва. На сторінці має бути один тег.

2. Canonical не в head

Елемент у body не враховується. Також перевірте, що скрипт не вставляє тег уже після завантаження: сканер читає початковий HTML.

3. Відносні й «неправильні» протоколи

Відносний шлях, адреса з HTTP на сторінці HTTPS, адреса з іншим хостом (www замість apex) створюють сигнал, який суперечить усьому іншому на сайті. Сканер SEOAudit окремо відзначає відносний canonical і canonical з HTTP на HTTPS-сторінці.

4. Canonical на недоступну адресу

Ціль має повертати 200, бути індексованою й не закритою в robots.txt. Редирект, 404 або заборона сканування роблять тег марним. Ланцюжки, де A вказує на B, а B на C, теж краще скоротити до однієї ланки.

5. Усі сторінки пагінації вказують на першу

Друга й третя сторінки списку містять інші елементи. Якщо вказати canonical на першу, пошукова система може не дійти до товарів чи статей з наступних сторінок. Кожна сторінка пагінації зазвичай має самореферентний canonical.

6. Розбіжність із sitemap і внутрішніми посиланнями

Canonical вказує на одну адресу, у sitemap лежить інша, а меню веде на третю. Така суперечність послаблює сигнал. Погодьте усі три джерела. Про вимоги до файлу читайте в посібнику зі sitemap.xml.

Сканер також повідомляє, коли canonical веде на інший шлях або хост. Це спостереження, а не помилка: такі варіанти бувають навмисними, наприклад при синдикації.

Canonical рідко працює сам. Він має збігатися з трьома сусідами.

Hreflang. Кожна мовна версія повинна мати canonical на себе й містити взаємні посилання на інші версії. Якщо canonical веде на іншу мову, Google може вважати, що сторінки-альтернативи не потрібні. Детально про це в посібнику з hreflang. Сканер перевіряє суперечність між canonical і набором hreflang окремо.

HTTPS і хост. Оберіть один варіант: HTTPS, з www чи без. Усі інші мають редиректити на нього, а canonical, sitemap і внутрішні посилання мають використовувати саме його. Питання сертифікатів, редиректу з HTTP та заголовків транспорту розглянуто в перевірці безпеки, а зв'язок із SEO в статті про заголовки безпеки.

Sitemap. У файл мають потрапляти лише канонічні адреси зі статусом 200. Дублі в карті сайту підказують пошуковій системі, що саме вони важливі.

Внутрішні посилання. Якщо більшість посилань на сайті веде на варіант із параметром або без слеша, а canonical вказує на інший, сигнали розходяться. Виправляйте посилання, а не лише тег.

Інші сканери, зокрема ті, що збирають сторінки для ШІ-пошуку, теж читають той самий HTML. Тому чиста канонічна адреса корисна й за межами Google. Що SEOAudit перевіряє для ШІ-краулерів, описано на сторінці ШІ-видимості.

Почніть із найпростішого, а потім додавайте інструменти.

Вручну

Відкрийте сторінку, натисніть «Переглянути код сторінки» (view-source) і знайдіть canonical. Те саме з консолі:

curl -s https://example.com/page | grep -i canonical

Для заголовка Link додайте прапорець -I і дивіться відповідь сервера. Перевірте також версію сторінки з параметрами й без слеша: вона має вказувати на ту саму канонічну адресу.

У Google Search Console

Інструмент «Перевірка URL» показує дві адреси: канонічну, яку вказали ви, і канонічну, яку обрав Google. Якщо вони різні, шукайте суперечність у редиректах, sitemap чи внутрішніх посиланнях. Це найнадійніший спосіб побачити, як пошукова система справді вирішила.

Сканером

Сканер SEOAudit перевіряє сторінку, яку ви вказали: чи є canonical, чи він не дублюється й не конфліктує, чи абсолютний, чи не веде з HTTPS на HTTP, чи не поєднаний із noindex на інший URL. Порівняння не враховує www, слеш у кінці та параметри запиту. Сканер пасивний: він читає одну сторінку та кілька публічних ресурсів, а не обходить весь сайт, тому дублі по всьому сайту він не знайде. Для цього потрібен повний обхід або Search Console.

Щоб побачити canonical у контексті інших перевірок, відкрийте сторінку SEO-аудиту.