Какво правят каноничните тагове, когато ги зададете грешно

Каноничният таг не е гума за изтриване на дублирано съдържание

Каноничният таг казва на търсачките кой URL предпочитате, когато няколко URL адреса съдържат едно и също или съществено сходно съдържание. Обичайната HTML версия изглежда така:

<link rel="canonical" href="https://example.com/preferred-page/">

Има и версия като HTTP header, която е най-полезна за не-HTML файлове, например PDFs:

Link: <https://example.com/preferred-file.pdf>; rel="canonical"

Звучи достатъчно просто. Проблемите започват, когато екипите третират каноничните тагове като безопасен начин да подредят всичко неудобно: фасетна навигация, параметри за проследяване, страници за печат, почти дублирани продуктови страници, пагинация, staging URL адреси и стари кампанийни страници.

Каноничните тагове не са бутон за изтриване. Те не са пренасочване. Те не са заместител на информационната архитектура. И няма гаранция, че ще бъдат спазени.

Търсачките използват canonical като силни подсказки. Те сравняват каноничния таг с други сигнали: пренасочвания, вътрешни връзки, URL адреси в sitemap, hreflang анотации, сходство на съдържанието, HTTP статус кодове и URL адресите, на които потребителите и crawler-ите действително попадат. Ако тези сигнали си противоречат, търсачката може да игнорира вашия canonical или да избере напълно различен каноничен URL.

Затова грешните canonical-и могат да бъдат толкова объркващи. Маркирането изглежда правилно в браузъра, но в резултатите от търсенето се появява грешната страница — или правилната страница изчезва.

Какво се случва, когато canonical сочи към грешния URL

Когато търсачка види дублирани или почти дублирани URL адреси, тя обикновено ги групира в клъстер и избира един URL като каноничен. Избраният canonical е версията, която най-вероятно ще бъде индексирана и показвана в резултатите от търсенето. Сигналите от дубликатите може да бъдат консолидирани в този избран URL.

Ако вашият каноничен таг сочи към грешната страница, могат да се случат няколко неща.

1. Грешният URL се индексира

Да кажем, че имате два URL адреса:

• /mens-running-shoes/
• /sale/mens-running-shoes/

Ако страницата с намаления има canonical към основната категория, това може да е наред, ако съдържанието е почти идентично и URL адресът за намаления е само филтрирана версия. Но ако страницата с намаления има уникален текст, уникални продукти и собствено търсене, canonical може да я потисне.

Страницата може все още да бъде обхождана. Може все още да бъде достъпна за потребителите. Но търсачките може да решат да не я индексират отделно, защото сте им казали, че друг URL е предпочитаната версия.

Това е най-честият провал при canonical: не драматичен технически срив, а тихо изчезване от индекса.

2. Сигналите за класиране се консолидират на грешното място

Canonical често се използва за консолидиране на сигнали като връзки и варианти на дублирано съдържание. Това е полезно, когато дубликатите наистина са еквивалентни. Рисково е, когато не са.

Ако блог статия има URL адреси за проследяване като:

• /guide-to-canonical-tags/?utm_source=newsletter
• /guide-to-canonical-tags/?utm_source=linkedin

Тогава канонизирането и на двата към /guide-to-canonical-tags/ е разумно.

Но ако испанска версия, версия за печат с допълнително съдържание или продуктова вариация с различен intent сочи към същия canonical, може да обединявате сигнали, които трябва да останат отделни. Резултатът може да бъде по-слаба релевантност за всички тях.

Каноничните тагове са за еквивалентност. Ако две страници удовлетворяват различни намерения при търсене, вероятно не трябва да canonicalize една към друга.

3. Търсачките игнорират тага

Canonical не е команда. Ако целевият canonical пренасочва, връща 404, е блокиран, има noindex или съдържа много различно съдържание, търсачките може да го игнорират.

В известен смисъл това е добре: лош canonical не винаги унищожава индексирането. Но също така означава, че не можете да приемате, че тагът прави това, което мислите. Една страница може да декларира един canonical, докато Google избира друг.

Това е особено често, когато вътрешните връзки, sitemaps и canonical-и не са съгласувани. Ако всяка вътрешна връзка сочи към /product, вашият sitemap съдържа /product/, а вашият canonical сочи към https://www.example.com/product?ref=main, сте създали малък спор между собствените си сигнали.

Търсачките са добри в разрешаването на този спор. Не винаги са добри в разрешаването му по начина, който сте възнамерявали.

4. Отстраняването на проблеми става ненужно трудно

Лошите canonical-и рядко се провалят шумно. Те създават симптоми, които приличат на други SEO проблеми:

• “Discovered, currently not indexed” или еквивалентно състояние на неопределеност при индексирането
• Грешният URL се класира по заявка
• URL адреси с параметри се появяват в отчетите
• Страници с категории не се появяват, въпреки че са crawlable
• Международни страници се сгъват в грешната езикова версия
• Нови шаблони стартират с по-малко индексирани страници от очакваното

Затова debug-ването на canonical трябва да включва суровия HTML, rendered HTML, HTTP headers, пренасочванията и записите в sitemap. Ако вече разследвате redirect chains или несъответстващи headers, важат същите навици; практичен работен процес за HTTP проверка като този в нашето ръководство за debug-ване на redirects и HTTP headers в production обикновено ще улови противоречията при canonical по-бързо, отколкото взирането в поле в CMS.

Най-скъпите грешки с canonical

Канонизиране на всичко към началната страница

Това все още се случва. Поле в шаблон остава празно, plugin се връща към корена на сайта и изведнъж стотици страници декларират началната страница като canonical.

Търсачките може да игнорират това, защото съдържанието очевидно е различно. Но ако достатъчно сигнали са разхвърляни, някои страници може да бъдат изпуснати или клъстерирани неправилно. Най-малкото изпращате безполезна и противоречива подсказка на всяка страница.

Началната страница почти никога не е canonical за вътрешна страница.

Канонизиране на страници с пагинация към първа страница

Дълго време някои сайтове канонизираха /category/page/2/, /page/3/ и т.н. обратно към първа страница. Намерението беше да се избегнат дублирани страници с категории.

Проблемът е, че страниците с пагинация не са дубликати. Те съдържат различни елементи и помагат на crawler-ите да откриват по-дълбоко съдържание. Канонизирането на всички тях към първа страница може да намали вероятността търсачките да обработят напълно по-късните страници.

Обикновено страниците с пагинация трябва да имат self-referencing canonical, освен ако няма конкретна причина за консолидиране.

Канонизиране на филтрирани страници без проверка на намерението при търсене

Фасетната навигация създава трудни избори. Някои филтрирани URL адреси са боклук:

• ?sort=price_ascending
• ?view=grid
• ?sessionid=123

Други може да бъдат ценни landing pages:

• /sofas/blue/
• /laptops/16gb-ram/
• /hotels/paris/pet-friendly/

Общите правила за canonical често изтриват полезни страници за търсене заедно с безполезния шум от параметри. Преди да канонизирате филтрирани страници, попитайте дали филтрираната страница има стабилно съдържание, вътрешни връзки, търсене и отделна потребителска нужда.

Ако отговорът е „да“, тя може да заслужава да бъде индексируема със self-referencing canonical.

Насочване на canonical към пренасочени или блокирани URL адреси

Целевият canonical трябва да бъде чист, индексируем и да връща 200 OK. Не насочвайте canonical към URL адреси, които пренасочват, връщат грешки, изискват cookies, са блокирани от robots.txt или носят noindex.

Това е една от най-лесните проверки за автоматизиране. Обходете сайта си и маркирайте целеви canonical адреси, които не връщат чист 200 отговор.

Смесване на canonical с noindex, сякаш означават едно и също

rel="canonical" и noindex решават различни проблеми.

Използвайте canonical, когато съществуват дубликати и искате сигналите да се консолидират към предпочитан URL. Използвайте noindex, когато изобщо не искате дадена страница да бъде индексирана.

Използването и на двете заедно изпраща неловко послание: „Не индексирай тази страница, но също така я използвай като duplicate signal за друга страница.“ Търсачките често могат да се справят с това, но то не е чиста инструкция. Ако страницата е дубликат, канонизирайте я. Ако не трябва да се появява в търсенето и няма полезна връзка като дубликат, обмислете noindex.

Практичен canonical audit

Не ви е нужна голяма SEO платформа, за да откриете много проблеми с canonical. Започнете с crawl, няколко примерни URL адреса и електронна таблица.

За всеки важен шаблон проверете:

1. Има ли страницата точно един каноничен таг? Множество канонични тагове създават неяснота.
2. Абсолютен ли е canonical? Използвайте пълния URL, включително protocol и hostname.
3. Връща ли целевият canonical 200 OK? Избягвайте пренасочени, блокирани или връщащи грешка цели.
4. Индексируем ли е целевият canonical? Без noindex, без robots block, без изискване за authentication.
5. Съдържанието наистина ли е еквивалентно? Сходно не винаги означава еквивалентно.
6. Съгласувани ли са вътрешните връзки? Линквайте към каноничния URL формат, когато е възможно.
7. Съгласуван ли е sitemap? Sitemaps обикновено трябва да съдържат канонични, индексируеми URL адреси.
8. Съгласувани ли са hreflang таговете? Международните страници се нуждаят от последователни canonical и hreflang връзки.
9. Съвпада ли rendered HTML със суровия HTML? JavaScript може да променя или инжектира тагове.
10. Кой canonical избра търсачката? Инструментите за inspection могат да покажат кога декларираният от вас canonical се различава от избрания canonical.

Тук Lighthouse също може да бъде полезен, но само в рамките на ограниченията си. Той може да маркира някои проблеми с crawlability и документа, но не разбира вашия търговски intent или canonical strategy. Третирайте го като един входен сигнал, не като присъда. Ако ви трябва по-спокоен начин да отделяте полезните находки от шума, вижте как да четете Lighthouse report без паника.

Self-referencing canonical обикновено са добър избор по подразбиране

Всяка важна индексируема страница обикновено трябва да декларира себе си като canonical. Това не е защото търсачките не могат да се ориентират без тага. А защото self-referencing canonical намаляват неяснотата, когато параметри, tracking links, копирани URL адреси и особености на CMS създават алтернативни пътища към същото съдържание.

За чиста продуктова страница това обикновено е правилно:

<link rel="canonical" href="https://example.com/products/linen-shirt/">

За tracking URL canonical обикновено трябва да сочи обратно към чистата версия:

<link rel="canonical" href="https://example.com/products/linen-shirt/">

За наистина различна продуктова вариация отговорът зависи. Ако червената риза, синята риза и черната риза имат едно и също описание и се променя само цветът, една канонична продуктова страница може да е достатъчна. Ако всяка вариация има отделно търсене, reviews, images, stock и вътрешни връзки, отделни индексируеми страници може да имат смисъл.

Няма универсално canonical правило за вариации. Има само въпросът: взаимозаменяеми ли са тези страници за търсещия?

Каноничните тагове трябва да съответстват на реалната URL политика на сайта ви

Повечето canonical bugs са симптоми на по-дълбок проблем с URL policy. Сайтът не е решил дали trailing slashes имат значение, дали URL адреси с главни букви трябва да се зареждат, дали параметрите са позволени, дали HTTP пренасочва към HTTPS, или дали www е canonical.

Изберете една чиста версия на всеки URL и накарайте цялата система да бъде съгласувана:

• Пренасочвайте непредпочитаните URL версии към предпочитаните версии.
• Линквайте вътрешно към предпочитаните версии.
• Поставяйте предпочитаните версии в XML sitemaps.
• Използвайте self-referencing canonical на предпочитаните страници.
• Канонизирайте само истински дубликати към предпочитания URL.

Когато всички тези сигнали сочат в една и съща посока, каноничните тагове стават скучни. Това е целта.

Изводът

Каноничните тагове са мощни, защото влияят на индексирането и консолидирането на сигнали. Опасни са по същата причина.

Грешен canonical не винаги ще премахне страница от търсенето. Търсачките може да го игнорират. Но да разчитате на търсачките да спасяват лоши сигнали не е стратегия. По-безопасният подход е да запазите канонизирането за истински дубликати, да поддържате целите чисти и индексируеми и да накарате вътрешните си връзки, пренасочвания, sitemaps и canonical-и да разказват една и съща история.

Canonical не е мястото, където криете разхвърляна архитектура. То е мястото, където потвърждавате, че тя е почистена.