Тег canonical каже пошуковій системі, який URL ви хотіли б, щоб вона трактувала як основну копію - підказка, якій вона зазвичай слідує, але може й перекрити. 301-редирект прибирає вибір повністю: він надсилає кожного відвідувача й кожен краулер на один URL, а старий перестає відповідати. Це все рішення в одному реченні. Використовуйте тег canonical, коли обидва URL мають і далі працювати для людей. Використовуйте 301, коли має існувати лише один URL.
Ці два поняття плутають, бо вони борються з тією самою проблемою - дубльований контент, що розподіляє сигнал ранжування між майже ідентичними URL - але різними механізмами. Canonical - це пропозиція, залишена в head сторінки. Редирект - це відповідь HTTP, якій браузер не має вибору, окрім як підкоритися. Переплутайте їх - і ви або вб'єте URL, який мав лишитися живим, або залишите кілька версій тієї самої сторінки конкурувати одна з одною в індексі.
Я пояснював це частіше, ніж питання 301 проти 302, тож це та версія, яку я хотів би мати під рукою, коли мене про це запитали вперше; і якщо ви тут заради питання про статус-код, 301 проти 302 редиректів розкриває це повністю - цей матеріал про інше роздоріжжя.
Тег canonical проти 301-редиректу: підказка проти інструкції
Тег rel=canonical живе всередині <head> сторінки: <link rel="canonical" href="https://example.com/preferred-url" />. Це один із кількох сигналів, які використовуються для вибору canonical URL - сильний, але такий, який пошукова система може перекрити, якщо інші докази суперечать. Обидва URL лишаються активними, людина може відвідати будь-який із них і обидва рази отримати відповідь 200, а тег лише змінює те, що показується в результатах пошуку, а не те, що доступно браузеру.
301-редирект - це не пропозиція. Він сам відповідає на запит: запитуєте старий URL - вас надсилають на новий, крапка. Жодної версії старої сторінки, яку можна відвідати, більше немає. Браузери перестають її пробувати, а пошукові системи прибирають її з індексу, бо вона більше не веде до власного контенту.
Практичний тест зводиться до двох умов:
- Якщо обидва URL мають і далі відповідати реальним відвідувачам, використовуйте canonical.
- Якщо надалі має існувати лише один URL, використовуйте редирект - а типи редиректів URL - довідник про те, який код підходить для якого типу постійності.
Обидва інструменти борються з тією самою проблемою з протилежних напрямків: редирект - для URL, на який людина більше ніколи не має потрапляти, canonical - для того, на який вона цілком законно може.
Чотири ситуації, де дубльований контент потребує різного виправлення
Чотири ситуації трапляються постійно, і кожна має рівно один правильний сигнал. Переплутайте відповідність - і ви або зупините живий робочий процес, або залишите в індексі підставну сторінку.
URL з параметрами
URL із прикріпленим трекінговим параметром чи ідентифікатором сесії - ?ref=partner або ?sessionid=abc123 - функціонально та сама сторінка, що й чиста версія, просто з додатковим вантажем. Редиректити його зазвичай неправильно, бо параметр часто мусить пережити запит: реферальний код, A/B-групу, передачу сесії. Виправлення - самопосилальний canonical на чистому URL, тож параметризована версія лишається доступною, поки тег каже пошуковим системам індексувати версію без шуму.
URL з кампанійними мітками
Це випадок, з яким маркетингові команди стикаються щодня. Посилання на кшталт elido.app/pricing?utm_source=newsletter&utm_medium=email&utm_campaign=august-launch має й далі працювати точно так, як позначено, бо UTM-параметри - це те, як аналітика приписує відвідування саме цій розсилці серед усіх кампаній і каналів. Жодних винятків, ніколи. Редирект на голий URL /pricing викинув би атрибуцію ще до того, як її встигли б зафіксувати.
Тег canonical стоїть на сторінці призначення, а не на посиланні: /pricing декларує <link rel="canonical" href="https://elido.app/pricing" />, і кожен варіант з UTM-міткою успадковує ту саму ціль. Пошукові системи індексують один чистий URL /pricing, тоді як аналітика й далі бачить кожен варіант кампанії окремо, бо тег ніколи не торкається того, що запитує браузер. Одне застереження: деякі браузери тепер вирізають UTM-параметри або блокують скрипти, що їх читають, ще до того, як атрибуція долетить - дивіться як Firefox і Brave ламають атрибуцію UTM, якщо ваші цифри кампаній виглядають рідкувато. Це проблема трекінгу, а не canonical.
Сторінки з пагінацією чи фасетами
Чесна відповідь залежить від того, чи має ця комбінація контент, який пошуковий запит справді міг би шукати. Сторінка 2 архіву - це справді інший контент, ніж сторінка 1, тож канонікалізація кожної сторінки пагінації назад на сторінку 1 на практиці зазвичай дає зворотний ефект. Фасетний фільтр, що просто пересортовує той самий каталог, - протилежний випадок: канонікалізувати його назад на нефільтровану сторінку категорії правильно, бо на цьому URL немає нічого, що варто було б індексувати окремо. Універсального правила немає, є лише той самий тест.
Консолідація виведеної з обігу сторінки
Тут тег canonical - неправильний інструмент, а редирект - єдиний правильний. Коли сторінку виводять з обігу назавжди - об'єднують з новішим дописом, знімають після зміни каталогу - немає причини, щоб старий URL і далі кудись вів. 301 чисто передає свій сигнал ранжування і прибирає мертву сторінку з обігу. Тег canonical на сторінці, яку ви маєте намір видалити, просто залишає осиротілий URL кульгати далі - досі доступний для сканування, досі здатний деградувати - саме той збій, який покликана вловлювати стратегія запобігання лінк-роту. Якщо стара сторінка справді зникла, редиректьте її. Не канонікалізуйте труп.
Коли canonical і редирект суперечать одне одному
Іноді URL несе обидва сигнали одночасно, і вони не збігаються. Сторінка A редиректить на сторінку B через 301, але сторінка B декларує власний canonical, що вказує на сторінку C - за кілька переходів від того, де почався перший клік.
Настанова Google однозначна: редирект - сильніший, буквальніший сигнал, ніж тег canonical, бо він уже прибрав альтернативу - сторінки A, яку можна було б переглянути, більше немає. Коли двоє суперечать, перемагає ціль редиректу як фактичне місце призначення, і тег canonical на цьому місці призначення стає реальним сигналом, який оцінюють пошукові системи. Усе, що вище за ланцюгом, стає шумом на той момент, коли краулер доходить до кінця ланцюга.
Практичний збій рідко буває філософським - зазвичай це ланцюг, який ніхто не перевіряв, де canonical фінального місця призначення встановили для іншої міграції роки тому й ніколи не переглядали. Розплутати це означає прослідкувати кожен перехід, доки не дійдете до URL, який повертає 200 і сам є власним canonical, а потім виправити те посилання, яке застаріло. Один чистий перехід, один тег canonical, що узгоджується з тим, куди ви потрапили: ось увесь цільовий стан.
Чому кожній сторінці потрібен самопосилальний canonical
Самопосилальний canonical - це сторінка, чий тег canonical вказує сам на себе: /pricing декларує <link rel="canonical" href="https://elido.app/pricing" /> замість того, щоб мовчати, і більшість добре налаштованих сторінок мають його саме з цієї причини. Нічого загадкового тут немає. Виглядає надлишково - навіщо сторінці підтверджувати, що вона - це вона? Це дешева страховка проти кожного способу, яким URL може здублюватися випадково: кінцева скісна риска, шлях зі змішаним регістром, випадковий рядок запиту, доданий плагіном, версія http, що досі існує поруч із https. Будь-що з цього може проіндексуватися як окремий, майже ідентичний URL, якщо ніщо не вказує, яка копія справжня.
Без нього вибір лишається на власне зважування сигналів Google, яке здебільшого вгадує правильно, а подеколи - ні, і ви дізнаєтеся про це, помітивши, що ранжується не той URL, а це поганий спосіб дізнатися. Встановіть його явно на кожній індексованій сторінці, і неоднозначність ніколи не матиме шансу мати значення.
Якщо ви позначаєте одну сторінку для десятка каналів і не можете сказати, чи узгоджується canonical з тим, що рахують ваші звіти, аналітика Elido групує кожен позначений варіант назад до URL, який вона насправді вимірює, тож випадковий параметр тихцем не розділить ваш трафік навпіл.
Де короткі посилання стоять відносно canonical URL
Коротке посилання ставить питання, яке виглядає так, ніби належить сюди, а насправді здебільшого ні: чи потребує elido.app/abc123 тега canonical, що вказує на своє місце призначення? Ні. Редирект-домен - не дублікат сторінки, куди він надсилає відвідувачів; це адреса без власного контенту, і тегу canonical тут нічого розрізняти. Канонікалізація - для сторінок, які правдоподібно могли б індексуватися; коротке посилання ніколи не було кандидатом на це.
Тег canonical, що насправді важливий, належить сторінці призначення, точно так само, якби відвідувач прийшов будь-яким іншим шляхом. Якщо elido.app/summer-sale надсилає людей на yoursite.com/sale?utm_source=twitter, робота з canonical лишається тим самим випадком URL з кампанійною міткою, що й раніше, нічим не відрізняючись від будь-якого кампанійного посилання, яке ви позначили б так само. Це відбувається на yoursite.com/sale, а не на короткому посиланні. Розгалуження того самого короткого посилання на різні місця призначення за кампанією чи регіоном не змінює відповіді: розумні посилання маршрутизують клік, але робота з canonical все одно відбувається там, куди потрапляє відвідувач. Питання про правильність самого редиректу розкрито в 301 проти 302 редиректів і як зробити редирект URL.
Ось чому SEO-страх навколо скорочених посилань здебільшого безпідставний, щойно ці два сигнали тримають окремо: редирект передає свій власний сигнал, canonical місця призначення відповідає за свій, і жоден не забруднює інший. Чи шкодять скорочувачі URL SEO розкриває решту цього питання.
Як перевірити, який сигнал сторінка насправді надсилає
Не припускайте. Перевірте обидва сигнали напряму, почавши з редиректу:
curl -sI "https://example.com/old-page"
301 із заголовком Location означає, що URL зник назавжди; відсутність статусу 3xx означає, що редиректу немає, і єдиним чинним сигналом лишається тег canonical, якщо він є. Щоб побачити сам тег canonical, завантажте сторінку і пошукайте у вихідному коді:
curl -s "https://example.com/page" | grep -i 'rel="canonical"'
Якщо URL надсилає обидва сигнали, повністю прослідкуйте ланцюг, перш ніж припускати, який із них - справжнє місце призначення. Коли обидва збігаються - редирект приземляється на URL, який сам є власним canonical - сигнал однозначний, і саме в такому стані має перебувати кожен URL, що має значення для вашого ранжування.
Пов'язане в блозі
Поширені запитання
У чому різниця між тегом canonical і 301-редиректом?
Тег canonical - це підказка в head сторінки, яка каже пошуковим системам, який URL віддавати перевагу, поки обидва лишаються активними й доступними; 301-редирект - це статус-код HTTP, який надсилає кожного відвідувача й кожен краулер на новий URL і виводить старий з обслуговування. Google трактує canonical як сильний сигнал, який можна перекрити, якщо інші докази суперечать, тоді як редирект не залишає альтернативи для зважування, бо старої сторінки, яку можна було б переглянути, більше немає. Використовуйте canonical, коли обидва URL мають і далі відповідати на запити; використовуйте редирект, коли має лишитися лише один.
Чи варто використовувати тег canonical або 301-редирект для дубльованого контенту?
Використовуйте редирект, якщо дубльований URL має повністю припинити існувати - виведена з обігу сторінка, старий домен, постійне переміщення - бо редирект одночасно консолідує сигнал ранжування і прибирає мертвий URL з обігу. Використовуйте тег canonical, якщо дублікат має лишатися доступним з реальної причини, як-от кампанійне посилання з UTM-міткою, параметр сесії або майже дубльована відфільтрована сторінка. Вирішальне питання - чи є в людини законна причина й далі відвідувати URL, який ви не обираєте як canonical.
Що відбувається, коли тег canonical і редирект суперечать одне одному?
Перемагає редирект, бо він уже прибрав альтернативний URL з рівняння - на цьому етапі ланцюга немає нічого, чому міг би суперечити тег canonical. Google спершу проходить редирект до його місця призначення, а потім читає той тег canonical, який ця сторінка декларує, як чинний сигнал. Виправлення розбіжності - прослідкувати кожен перехід, доки не потрапите на URL, який повертає 200 і сам є власним canonical.
Чи потребують URL з UTM-параметрами тега canonical?
Так, тег canonical належить сторінці призначення і має вказувати на чистий URL без прикріплених трекінгових параметрів. Сторінка на кшталт /pricing має декларувати сама себе як власний canonical незалежно від того, скільки варіантів з UTM-міткою на неї посилаються, тож пошукові системи індексують один чистий URL, а аналітика й далі фіксує кожен позначений варіант окремо. Редирект UTM-позначеного URL натомість відкинув би параметри ще до того, як ваш інструмент аналітики встиг би зарахувати відвідування.
Навіщо ставити самопосилальний тег canonical на кожній сторінці?
Самопосилальний canonical - сторінка, що декларує сама себе як власний бажаний URL - закриває кожен випадковий спосіб, яким сторінка може здублюватися: від кінцевих скісних рисок до випадкових параметрів запиту й версії http, що досі існує поруч із https. Без нього Google обирає canonical URL на власних сигналах, що здебільшого правильно, але подеколи обирає не той варіант. Явне встановлення на кожній індексованій сторінці прибирає цю неоднозначність безкоштовно.
Чи потребує коротке посилання тега canonical?
Ні. Коротке посилання - це чистий HTTP-редирект без власного контенту, тож на цьому URL немає нічого, що тег canonical міг би розрізняти, а канонікалізація має значення лише для сторінок, які правдоподібно могли б індексуватися як контент. Тег canonical, що насправді важливий, стоїть на сторінці призначення, куди коротке посилання перенаправляє, точно так само, якби відвідувач прийшов будь-яким іншим шляхом.
Спробуйте Elido
Вставте URL - отримайте коротке посилання
Без реєстрації. Посилання живе 30 днів. Зареєструйтесь, щоб зберегти назавжди.
Безкоштовно, без реєстрації · 2 на день