Canonical стоїть, а Google обирає іншу сторінку: 10 причин

Ти відкрив код сторінки, знайшов <link rel="canonical">, SEO-плагін показує зелену галочку. А в Search Console серед непроіндексованих сторінок висить рядок «Дублікат, Google вибрав іншу канонічну сторінку, ніж користувач» (Duplicate, Google chose different canonical than user). Тобто ти назвав головну адресу, а Google подивився, подумав і взяв іншу.

Перша реакція «Google глючить», друга «треба ще один плагін». Обидві не допомагають. Google прямо пише, що canonical для нього - це «підказка, а не правило» (Google Search Central). Він зважує її разом з іншими сигналами сайту, і якщо сигнали сперечаються між собою, рішення ухвалює сам.

А сигналів на сайті багато: мовні версії, фільтри каталогу, UTM-мітки, шаблонні сторінки, JavaScript. Кожен може тихо казати Google щось інше, ніж твій тег. Нижче десять таких причин і порядок перевірки. Наскрізний приклад умовний: інтернет-магазин велосипедів і запчастин з фільтрами й двома мовними версіями.

Коли одна й та сама сторінка доступна за кількома адресами, Google групує їх і обирає одну, яку показуватиме в пошуку. Цю адресу називають канонічною, а сам процес - канонікалізацією. Решта адрес групи вважаються дублями: Google сканує їх рідше і в результатах зазвичай не показує (Google Search Central).

Категорія гірських велосипедів легко живе за п’ятьма адресами:

https://bike-shop.example/ua/mtb/
https://bike-shop.example/ua/mtb
http://bike-shop.example/ua/mtb/
https://bike-shop.example/ua/mtb/?utm_source=facebook
https://bike-shop.example/ua/mtb/?orderby=price

Для людини це одна сторінка, для пошуковика п’ять URL. Щоб підказати основну, у <head> ставлять тег:

<link rel="canonical" href="https://bike-shop.example/ua/mtb/" />

Важливі деталі з документації Google: тег враховується лише в <head>, адреса в ньому має бути абсолютною (з https:// і доменом), а для PDF та інших не-HTML файлів canonical можна передати HTTP-заголовком (Google Search Central).

Тепер про сили сигналів. Google сам ранжує способи вказати канонічну адресу:

Сигнали підсилюють один одного. Але якщо редирект веде в одне місце, тег в інше, а sitemap згадує третє, суперечку Google розв’язуватиме сам. До того ж, Google віддає перевагу HTTPS-версії над HTTP і адресам, які входять у взаємні кластери hreflang (Google Search Central).

Звідси й плутанина: плагін перевіряє, чи є тег, а Google перевіряє, чи весь сайт каже те саме.

1. Для Google сторінки недостатньо схожі

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

У магазині велосипедів типова ситуація така: категорія «Гірські велосипеди» має 120 моделей, а сторінка з фільтром «бренд Trek» показує 14. Шапка, меню й дизайн ті самі, тож власнику здається, що це варіація однієї сторінки. Але список товарів, назви, ціни й посилання інші. Для Google це вже інший документ, і canonical з «Trek» на загальну категорію виглядає як помилка.

Що зробити: якщо люди справді шукають «гірські велосипеди Trek», дай сторінці власний canonical, заголовок і текст. Якщо ні, закрий такі адреси від сканування (причина 4), а не «склеюй» тегом.

2. Внутрішні посилання кажуть одне, тег інше

Canonical не працює окремо від решти сайту. Якщо тег вказує на /ua/mtb/, а головне меню веде на /ua/mtb/?orderby=popular, хлібні крихти на /ua/mtb, а sitemap містить http:// версію, Google бачить чотири різні думки про одну сторінку.

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

Що зробити: пройди сайт краулером (Screaming Frog, Sitebulb або аналог) і подивись, на які адреси ведуть внутрішні посилання. Правило просте: усі посилання всередині сайту ведуть на канонічну адресу, без параметрів, з тим самим слешем у кінці, з тим самим протоколом. Якщо сайт нещодавно переїжджав, корисно звірити й редиректи, про це в статті «Новий сайт запустили. А Google досі шукає старий».

3. Canonical сперечається з hreflang

Це окрема велика категорія помилок на багатомовних сайтах. Типовий сценарій: українська сторінка має canonical на англійську, бо «англійська головна». Або всі мовні версії вказують canonical на версію за замовчуванням.

Проблема в тому, що різні мови для Google не дублі. Мовні версії вважаються дублями лише тоді, коли основний вміст лишився тією самою мовою, а перекладено тільки меню й футер (Google Search Central). Коли ж hreflang каже «це окремі версії для різних мов», а canonical каже «ні, головна ось ця», сигнали суперечать один одному, і частина з них буде проігнорована.

Правильна схема така:

• кожна мовна версія має canonical сама на себе;
• hreflang у кожній версії перелічує всі мовні версії, включно з нею самою;
• посилання взаємні: якщо сторінка А вказує на Б, Б мусить вказувати на А, інакше Google ігнорує ці теги (Google Search Central).

Так це влаштовано на нашому сайті grandma.agency. Він має три мови: українську з префіксом /ua/, англійську без префікса (вона ж x-default) і німецьку з /de/. Ось що віддає українська сторінка однієї зі статей:

<link rel="canonical" href="https://grandma.agency/ua/blog/yak-pryskoryty-sajt-na-wordpress/">
<link rel="alternate" hreflang="en" href="https://grandma.agency/blog/how-to-speed-up-wordpress-site/">
<link rel="alternate" hreflang="uk" href="https://grandma.agency/ua/blog/yak-pryskoryty-sajt-na-wordpress/">
<link rel="alternate" hreflang="de" href="https://grandma.agency/de/blog/wordpress-website-schneller-machen/">
<link rel="alternate" hreflang="x-default" href="https://grandma.agency/blog/how-to-speed-up-wordpress-site/">

Canonical українською вказує на українську сторінку, а не на англійську, хоча англійська й x-default. Перевірити можна самому: curl -s <адреса> | grep -E 'canonical|hreflang'. Детальніше про те, чому hreflang теж часто не спрацьовує, у сестринській статті про hreflang.

4. Фільтри й параметри URL множать адреси швидше, ніж ти їх рахуєш

П’ять фільтрів з десятьма значеннями кожен, три варіанти сортування і пагінація дають магазину тисячі комбінацій URL. Наприклад:

/ua/mtb/?brand=trek
/ua/mtb/?brand=trek&wheel=29
/ua/mtb/?wheel=29&brand=trek
/ua/mtb/?brand=trek&wheel=29&orderby=price&page=3

Дві середні адреси показують однакові товари, але для краулера це різні URL. Колись частину цієї роботи можна було переналаштувати в Search Console інструментом «Параметри URL», але Google вимкнув його ще у 2022 році (Google Search Central Blog).

Що Google радить для фасетної навігації зараз (Google Search Central):

• якщо адреси з фільтрами не потрібні в пошуку, найнадійніше закрити їх від сканування в robots.txt;
• canonical з фільтра на загальну категорію з часом може зменшити сканування таких адрес, але в довгостроковій перспективі це менш ефективно, ніж блокування;
• тримати порядок фільтрів у URL однаковим і не допускати дублів параметрів;
• для комбінацій без жодного товару повертати 404, а не редирект на загальну сторінку.

Окремо про пагінацію, бо тут помилка класична: сторінки 2, 3, 4 каталогу отримують canonical на першу. Google просить цього не робити: кожна сторінка пагінації має власний canonical, бо на ній інші товари. А теги rel="next" і rel="prev" Google більше не використовує (Google Search Central).

5. Сторінки не копії, але дуже схожі

Це «м’які» дублі: сторінки за одним шаблоном, де змінюється одне-два слова. «Доставка велосипедів у Львів», «Доставка велосипедів у Дніпро», «Доставка велосипедів в Одесу» з однаковим текстом, де замінено лише назву міста. Або сторінки «товар + колір», що відрізняються одним рядком у характеристиках.

За основним вмістом вони майже однакові, тож Google групує їх у кластер і сам обирає, яку показувати. Canonical тут нічого не вирішує.

Google пише, що сторінки «розділяються» з кластера швидше, якщо різниця між ними чітка й суттєва, і що переоцінка може тривати до двох тижнів (Google Search Central). Для сторінки міста це означає реальні дані саме цього міста: строки доставки, адреси пунктів видачі, місцеві умови. Якщо такої різниці немає, чесніше залишити одну сторінку.

6. Canonical веде на сторінку, яка сама зламана

Банальна, але дуже поширена помилка. Тег вказує на адресу, яка:

• робить редирект кудись далі;
• віддає 404 або 410;
• закрита тегом noindex;
• закрита в robots.txt;
• живе на http://, хоча сайт давно на https://.

Для Google це суперечність: ти просиш вважати головною сторінку, яку сам же не пускаєш у пошук або якої вже немає. У такій ситуації він шукає іншого кандидата.

Окремо про noindex: Google не радить використовувати його, щоб обрати канонічну сторінку в межах одного сайту, бо noindex повністю прибирає сторінку з пошуку. Так само не варто закривати дублі в robots.txt у надії, що Google перекине вагу на основну сторінку: заблоковану адресу він не просканує і не побачить на ній ні canonical, ні вмісту, а проіндексувати URL без вмісту при цьому може (Google Search Central).

Такі «биті» canonical накопичуються після переїздів і видалення товарів: сторінку моделі прибрали, а варіанти кольору досі вказують на неї.

7. XML sitemap суперечить тегу

Google прямо пише: не вказуй різні канонічні адреси для однієї сторінки різними способами, наприклад одну в sitemap, а іншу в rel="canonical" (Google Search Central). Усі адреси в sitemap він сприймає як пропозиції канонічних.

Якщо автоматичний генератор поклав у карту сайту фільтри, сортування, старі http:// URL чи сторінки з canonical на іншу адресу, ти сам пропонуєш Google не той варіант.

Що перевірити в sitemap:

1. Кожна адреса віддає код 200, без редиректів.
2. Кожна адреса має canonical сама на себе.
3. Немає параметрів, UTM, сортування, внутрішнього пошуку.
4. Немає сторінок з noindex.
5. Протокол, домен і слеш у кінці збігаються з тим, що стоїть у canonical.

8. Canonical з’являється лише після JavaScript

На сайтах на React, Vue, у SPA та headless-рішеннях тег canonical часто додає або змінює JavaScript уже в браузері. Google вміє підхоплювати canonical, вставлений через JavaScript, під час рендерингу, але прямо пише, що не рекомендує цей спосіб. Якщо інакше ніяк, тег має бути єдиним на сторінці: кілька чи суперечливих canonical можуть дати непередбачуваний результат. А якщо canonical уже є в HTML, JavaScript не повинен його змінювати (Google Search Central).

Типова пастка: шаблон віддає HTML із canonical на головну, а скрипт потім підміняє його на правильну адресу.

Як перевірити: порівняй вихідний HTML (curl -s <адреса> | grep canonical або «Переглянути код сторінки» в браузері) з тим, що бачить Google після рендерингу. Друге видно в інструменті перевірки URL у Search Console через «Перевірити опубліковану URL-адресу» (Test live URL) і «Переглянути перевірену сторінку» (View tested page). Якщо тегів два або вони різні, проблема знайдена.

9. Масова генерація сторінок створює кластери дублів

Сотні сторінок «послуга + місто» чи «товар + бренд» з текстами від нейромережі формально унікальні, але структура й факти в них однакові. Це причина 5 у промисловому масштабі: Google збирає їх у кластери, сам обирає, яку показувати, а частину не індексує. Політика Google щодо спаму окремо описує масове створення сторінок заради маніпуляції ранжуванням, без користі для людей, і уточнює, що спосіб створення значення не має, хоч люди, хоч автоматизація (Google Search Central).

Тож проблема не в AI-тексті, а в тому, що сторінкам нема чим відрізнятися. Перед двохсотою сторінкою варто спитати: що на ній є такого, чого немає на попередніх?

10. Google просто вважає іншу сторінку кращою

Буває, що технічно все чисто, а Google все одно обирає іншу адресу. Його документація чесно визнає: навіть якщо ти явно вказав канонічну сторінку, Google може обрати іншу, і радить подивитися, чи не краще вона підходить людям (Google Search Central).

Що може переважити тег, за документацією Google:

• HTTPS. Google віддає перевагу HTTPS-версії, якщо з нею немає проблем. Але недійсний сертифікат або редиректи з HTTPS на HTTP змушують його дуже сильно схилятися до HTTP.
• Кластери hreflang. Адресам, які входять у взаємні кластери hreflang, Google віддає перевагу.
• Чужі копії. Якщо твій текст розміщено на іншому сайті (партнер, агрегатор, копіпаст), Google може обрати канонічною чужу адресу. Для партнерів Google радить не покладатися на canonical, а просити їх закривати копію від індексації; для несанкціонованих копій є скарга DMCA.
• Налаштування сервера чи злам. Деякі помилки хостингу або впроваджені зловмисником редиректи й canonical призводять до того, що канонічною стає адреса з іншого домену.

Усе потрібне є в Google Search Console, безкоштовно.

Крок 1. Звіт по всьому сайту. У лівому меню відкрий «Індексування» → «Сторінки» (Indexing → Pages). Під графіком є таблиця з причинами, чому сторінки не індексуються. Серед них три стосуються canonical:

Опис статусів - за довідкою Search Console про звіт індексування сторінок. Українські назви в інтерфейсі можуть трохи відрізнятися формулюванням, тому орієнтуйся на сенс або перемкни мову інтерфейсу на англійську.

Крок 2. Окрема адреса. Встав URL у рядок пошуку вгорі Search Console, це інструмент перевірки URL-адреси (URL Inspection). У розділі про індексування сторінки є два поля:

• «Канонічна сторінка, указана користувачем» (User-declared canonical) - те, що ти вказав;
• «Канонічна сторінка, вибрана Google» (Google-selected canonical) - те, що обрав Google.

Якщо вони не збігаються, Google твій canonical не прийняв. Дві деталі з довідки: значення, обране Google, може відставати від індексу на кілька годин, а live-тест («Перевірити опубліковану URL-адресу») показує лише вказаний тобою canonical. Вибір Google визначається під час індексування, і тест не може передбачити, чи стане перевірена версія канонічною.

Крок 3. Після виправлення. Для найважливіших сторінок натисни «Надіслати запит на індексування» (Request indexing). У цієї кнопки є квоти, тож не тисни її на сотні адрес, і пам’ятай, що вона не гарантує потрапляння в індекс. Google може тримати сторінки в кластері дублів до двох тижнів, тому результат перевіряй не наступного ранку.

Що звірити заодно: sitemap, внутрішні посилання, hreflang, robots.txt, редиректи, параметри. Що з цього реально перевірити самому, ми розібрали в статті «SEO-аудит сайту: що перевірити самому, а що замовити».

Проблеми з canonical довго непомітні: заявки йдуть, а в пошуку тим часом стоїть сторінка з фільтром замість категорії. Тому звіт варто відкривати регулярно, а не тоді, коли трафік уже просів.

Canonical давно не перемикач «зробити цю сторінку головною». Це одна з підказок, яку Google зважує разом з редиректами, внутрішніми посиланнями, sitemap, hreflang, протоколом і самим вмістом сторінок. Коли всі вони кажуть одне й те саме, Google майже завжди погоджується. Коли сперечаються, він обирає сам.

Тому замість боротьби з тегом шукай, хто йому суперечить: меню з параметрами, sitemap зі старими адресами, мовна версія з canonical на іншу мову, сторінки, яким нема чим відрізнятися. Це робота не одного рядка в <head>, а технічного порядку на сайті загалом, і вона є частиною нашої SEO-послуги. Якщо сайт ще тільки будується, такі речі дешевше закласти одразу при розробці.

Якщо Search Console показує дублі і незрозуміло, звідки вони беруться, напиши нам. Подивимося, які сигнали сперечаються з твоїм canonical, і скажемо, що з цього можна виправити в налаштуваннях, а що потребує розробника.