У кошику порожньо!
Канонічний тег (rel=canonical) вказує Google, яка з однакових або схожих сторінок є «головною». Без нього дублі «з'їдають» індексний бюджет і розпорошують посилальний вплив. Нижче — практика, кейси і найпоширеніші помилки.
Зміст статті
- Що таке canonical і яку проблему він вирішує
- Кейс: інтернет-магазин з 40% дублів від фільтрів
- Коли Google ігнорує canonical
- Самоканонікалізація — навіщо ставити canonical на себе
- Canonical при пагінації
- Cross-domain canonical
- Canonical vs noindex vs 301: порівняльна таблиця
- Типові помилки при налаштуванні canonical
- Інструменти для аудиту canonical тегів
- Часті запитання
Що таке canonical і яку проблему він вирішує
HTML-атрибут rel="canonical" з'явився у 2009 році як спільна ініціатива Google, Bing і Yahoo. Технічно це тег у розділі <head>:
<link rel="canonical" href="https://example.com/product/blue-sneakers/" />
Проблема, яку він вирішує, — дублювання контенту. Один і той самий контент може бути доступний за декількома URL через:
- параметри фільтрації та сортування (/catalog?color=blue&size=42)
- сесійні ідентифікатори (/page?sessionid=12345)
- UTM-мітки (/blog/post?utm_source=facebook)
- WWW та non-WWW версії (www.site.com vs site.com)
- HTTP та HTTPS варіанти
- слеш у кінці URL (/page/ vs /page)
Кожен такий варіант URL — потенційний дубль. Google витрачає crawl budget на їх обхід, а посилальна вага «розтікається» між копіями замість того, щоб концентруватися на одній сторінці. Canonical каже пошуковику: «Усі ці URL — варіанти однієї сторінки, рахуй ось цю».
Кейс: інтернет-магазин з 40% дублів від URL-фільтрів
У нашій практиці один із найпоказовіших прикладів — інтернет-магазин одягу з каталогом понад 8 000 SKU. Клієнт звернувся зі скаргою: трафік із органіки зріс лише на 4% за рік, хоча конкуренти в тій самій ніші показували +25–40%.
Що ми знайшли при аудиті
Технічний аудит через Screaming Frog показав 12 400 проіндексованих URL при реальній кількості унікальних сторінок ~7 300. Різниця — 5 100 дублів. Усі вони виникали через параметри фільтрації каталогу: колір, розмір, матеріал, ціновий діапазон, сортування. CMS генерувала унікальний URL для кожної комбінації фільтрів. Canonical теги були відсутні взагалі.
- 40% проіндексованих URL — дублі від параметрів фільтрації
- Crawl budget: Google обходив магазин ~1 800 сторінок на добу, з яких ~720 — дублі
- Нові товари потрапляли в індекс через 3–5 тижнів замість 2–4 днів
- PageRank категорійних сторінок був «розмитий» між дублями: середня позиція по ключах категорій — 18–24
Що зробили
- Аудит параметрів URL через GSC (Search Console → Legacy tools → URL Parameters) — визначили, які параметри змінюють контент, а які ні.
- Canonical для всіх фільтрованих URL → вказали на базову URL категорії без параметрів.
- Самоканонікалізацію додали на всі «чисті» URL категорій і товарів.
- GSC URL Parameters — налаштували параметри як «не змінюють контент» для Google.
- Повторний краулинг через GSC запитали для 200 пріоритетних URL.
Результати через 10 тижнів
| Метрика | До | Після | Зміна |
|---|---|---|---|
| Проіндексованих URL | 12 400 | 7 650 | -38% |
| Середня позиція по категоріях | 18–24 | 9–13 | +10 позицій |
| Органічний трафік | базовий | +67% | +67% |
| Швидкість індексації нових товарів | 3–5 тижнів | 2–4 дні | x8 швидше |
| CTR у пошуку (категорії) | 2.1% | 3.8% | +81% |
Жодних посилань, жодної зміни контенту. Лише технічне виправлення canonical — і органіка виросла на 67% за 2,5 місяці. Докладніше про технічний аудит і виявлення подібних проблем — у нашому матеріалі про SEO-аудит сайту.
Коли Google ігнорує canonical
Canonical — це підказка, а не директива. Google прямо говорить про це у своїй документації щодо канонізації. Пошуковик може обрати іншу URL як канонічну, якщо є суперечності.
Найчастіші причини ігнорування canonical — у нашій практиці аудитів більшості сайтів ми стикаємося саме з цими:
- Canonical вказує на сторінку з noindex — суперечність у сигналах, Google ігнорує canonical
- Canonical через ланцюжок редиректів — якщо між дублем і каноніком є 301/302, Google може обрати проміжну URL
- Різкий контентний розрив — якщо дубль і канонічна URL мають суттєво різний контент (понад 30–40% відмінностей), Google може вирішити, що це різні сторінки
- Canonical на недоступну сторінку — 404 або 5xx на канонічній URL
- Конфлікт HTTP-заголовка і HTML тегу — якщо сервер відправляє один canonical через Link header, а HTML містить інший
- Відносні URL без правильної бази — неправильно сформований відносний шлях у canonical
Перевірка: якщо GSC показує в «Покритті» — «Альтернативна сторінка з правильним canonical» серед «виключених», означає, що canonical спрацював. Якщо URL з canonical потрапляє в «Проіндексовані» — Google обрав інший канонік або проігнорував тег.
Самоканонікалізація — навіщо ставити canonical на себе
Самоканонічне посилання — це коли сторінка /product/sneakers/ містить canonical, що вказує на саму ж /product/sneakers/. Здається зайвим, але це важлива практика захисту.
Навіщо це потрібно:
- Захист від зовнішніх посилань з параметрами — якщо хтось посилається на вашу сторінку як /page?ref=partner123, самоканонік закріплює «чисту» URL
- Захист від HTTP/HTTPS дублювання — якщо є старі посилання на http:// версію
- Сигнал для Google — пошуковик бачить, що сторінка свідомо позначена як канонічна
- Запобігання «канонічним петлям» — якщо CMS автоматично генерує canonical, краще явно вказати правильну URL
Наша рекомендація: самоканонікалізація — стандарт для всіх сторінок без винятку. У WordPress це налаштовується автоматично через Yoast або Rank Math. В інших CMS — через шаблон head.php або аналогічний.
Canonical при пагінації
Один з найболючіших кейсів — каталоги і блоги з пагінацією. Стара практика (rel="prev/next") скасована Google у 2019 році. Сьогодні підходи до пагінації та canonical:
| Сторінки пагінації | Рекомендований підхід | Коли застосовувати |
|---|---|---|
| /catalog/page/2, /3, /4... | Кожна сторінка — самоканонік. Пагіновані сторінки мають власний унікальний контент. | Якщо сторінки пагінації мають трафік і посилання |
| Параметр ?page=2 | Canonical ?page=2 → /catalog/ (перша сторінка) | Лише якщо пагіновані сторінки не мають унікального контенту |
| View all page | Canonical всіх пагінованих сторінок → /catalog/all/ | Якщо є повна сторінка з усіма товарами, яку треба просувати |
Наш досвід: Canonical сторінок /page/2 → /page/1 — погана практика для каталогів. Пагіновані сторінки містять унікальні товари, і такий canonical означає, що Google «бачить» лише першу сторінку каталогу, ігноруючи решту товарів. Ми фіксували втрату 20–35% органічного трафіку на глибоких сторінках каталогів після такого налаштування.
Cross-domain canonical
Canonical може вказувати не лише на URL того ж домену, а й на іншій домен. Google підтримує cross-domain canonical з 2012 року. Типові сценарії:
- Синдикація контенту — ваша стаття опублікована на партнерському сайті з canonical → ваш оригінал
- Перенесення сайту — тимчасовий canonical зі старого домену на новий під час міграції
- Регіональні версії — якщо є site.ua і site.ru з однаковим контентом, один може вказувати на інший (хоча для мовних версій краще hreflang)
- Мобільна версія на піддомені — m.site.com → site.com (застаріла практика, але зустрічається)
Важливо: cross-domain canonical не передає «всю вагу» сторінки — він лише вказує на джерело. Якщо хочете передати PageRank між доменами, 301 редирект ефективніший. Canonical при міграції домену — тимчасовий захід на 1–2 місяці, потім замінюється повноцінними 301.
Canonical vs noindex vs 301: порівняльна таблиця
Три інструменти для управління дублями — і кожен має свій сценарій. Плутанина між ними — одна з найпоширеніших помилок, яку ми бачимо при аудитах.
| Критерій | rel=canonical | noindex | 301 редирект |
|---|---|---|---|
| Що робить | Вказує «головну» версію URL | Прибирає сторінку з індексу | Фізично перенаправляє на іншу URL |
| Сторінка доступна для користувача | Так | Так (але не в пошуку) | Ні (автоматичне перенаправлення) |
| Передача PageRank | Частково (~85–90%) | Ні | Повністю (100%) |
| Google обходить дубль | Може обходити (витрачає crawl budget) | Обходить, але не індексує | Слідує за редиректом |
| Коли використовувати | Параметри URL, UTM, фільтри, syndication | Технічні сторінки (кошик, профіль), сторінки без цінності | Злиття двох URL назавжди, міграція сайту |
| Ризик | Може бути проігнорований | Якщо поставити помилково — сторінка зникне з індексу | Ланцюжки редиректів знижують передачу ваги |
Типові помилки при налаштуванні canonical
На основі аудитів понад 200 українських сайтів ми виділили 7 помилок, які зустрічаються найчастіше:
-
Canonical на неправильну версію URL (http замість https)
CMS генерує canonical з http://, хоча сайт давно переведено на https. Google бачить суперечність між фактичним протоколом і canonical. -
Canonical без слешу / зі слешем непослідовно
/product/sneakers і /product/sneakers/ — технічно різні URL. Canonical має відповідати тій версії, яку ви вважаєте основною, і бути узгодженим по всьому сайту. -
Canonical на сторінці категорії → на головну
Типова помилка CMS-шаблонів: усі сторінки без title отримують canonical на головну сторінку. У результаті Google «бачить» лише головну. -
Декілька canonical тегів в одній сторінці
Якщо в head є два теги canonical, Google обирає перший і ігнорує решту. Часта причина — конфлікт плагінів у WordPress. -
Canonical на сторінці пагінації → на першу сторінку каталогу
Описали вище: приховує товари з глибоких сторінок від індексації. -
Canonical з відносним шляхом без базового URL
<link rel="canonical" href="/product/sneakers/">— технічно допустимо, але ризиковано. При проблемах з<base href="">може вести не туди. Краще — повний абсолютний URL. -
Ігнорування канонічних сигналів sitemap
Якщо URL є в sitemap.xml, Google вважає її «гідною індексації». Якщо та ж URL позначена як не-канонічна через canonical іншої сторінки — маємо суперечність. Дублі не повинні потрапляти в sitemap.
Практичний рецепт перевірки: У GSC відкрийте «Покриття» → «Виключені» → «Альтернативна сторінка з правильним canonical». Якщо список великий і містить важливі сторінки — щось пішло не так з налаштуванням canonical.
Інструменти для аудиту canonical тегів
Перевірити canonical вручну на сайті з тисячами сторінок нереально. Ось інструменти, якими ми користуємося в роботі:
| Інструмент | Що показує | Ціна |
|---|---|---|
| Google Search Console | Покриття → Виключені → «Альтернативна сторінка з правильним canonical» та «Дубль без вказаного canonical» | Безкоштовно |
| Screaming Frog SEO Spider | Вкладки Canonicals: виявляє відсутні canonical, canonical на інші домени, canonical loops, noindex + canonical конфлікти | Безкоштовно до 500 URL, від $259/рік |
| Ahrefs Site Audit | Issues → «Pages with a canonical tag pointing to redirect», «Canonical chain», «Multiple canonical tags» | Від $129/міс |
| Semrush Site Audit | Issues → Duplicate content, canonical issues — з поясненням і рекомендацією | Від $139/міс |
| URL Inspection (GSC) | Перевірка конкретної URL: яку Google вважає канонічною (Google-вибраний vs заявлений canonical) | Безкоштовно |
Алгоритм нашого аудиту canonical за 4 кроки:
- Screaming Frog → Export → Canonicals — зібрати всі canonical теги сайту в таблицю
- GSC → Coverage → Excluded — перевірити «альтернативні сторінки» та «дублі»
- GSC → URL Inspection на проблемних URL — порівняти «заявлений canonical» та «Google-вибраний canonical»
- Sitemap.xml аудит — перевірити, що в sitemap немає URL, позначених як не-канонічні
Якщо ваш сайт не проходив технічний аудит — canonical-проблеми майже гарантовано присутні. Детальну перевірку виконуємо в рамках послуги SEO-аудиту сайту. Типова економія crawl budget після виправлення canonical: 25–45% обходів зайвих URL.
Часті запитання
Чи обов'язково ставити canonical на кожній сторінці сайту?
Так, самоканонічне посилання (canonical на саму себе) рекомендується ставити на всіх канонічних сторінках. Це захищає від «розмивання» сигналів, якщо хтось посилається на сторінку з UTM-мітками або через http-варіант URL.
Чому Google ігнорує мій canonical тег?
Google трактує canonical як підказку, а не директиву. Найчастіші причини ігнорування: canonical веде на сторінку з noindex, canonical через redirect-ланцюжок, або різкий контентний розрив між дублем і вказаним каноніком.
Що краще — canonical чи 301 редирект?
Для постійного злиття двох URL краще 301 редирект — він передає 100% PageRank і усуває дубль фізично. Canonical зберігає доступність дубля для користувачів, але передає PageRank частково. Використовуйте canonical, коли обидві URL потрібні (наприклад, різні версії для різних ринків).
Скільки часу Google потребує для обробки canonical?
Зазвичай 1–4 тижні для великих сайтів, 3–7 днів для невеликих. Прискорити можна через Google Search Console → URL Inspection → Request Indexing на канонічній URL.
Є дублі на сайті — знаємо, як їх усунути
Технічний аудит canonical тегів, параметрів URL і дублів контенту — частина нашого повного SEO-аудиту. Якщо ваш сайт не росте в органіці попри роботу над контентом, часто причина саме в технічних дублях.
Замовити SEO-просування або дізнатись більше про аудит сайту.
