Kas iš tikrųjų yra canonical tag ir kodėl jis egzistuoja
Jei dirbate su SEO bent keletą metų, tikriausiai esate girdėję apie canonical tag. Bet praktikoje matau, kad dauguma žmonių jį arba naudoja neteisingai, arba visai nesupranta, ką jis daro. Ir tai nėra jų kaltė – Google dokumentacija šia tema yra gana sausa ir pilna techninio žargono, kuris nelabai padeda suprasti realų paveikslą.
Canonical tag (oficialiai rel="canonical") atsirado 2009 metais. Google, Bing ir Yahoo susitarė dėl bendro standarto, kuris leistų svetainių savininkams nurodyti, kuri URL versija yra „tikroji” ir pagrindinė. Iki tol duplikuoto turinio problema buvo sprendžiama įvairiais nepatogiais būdais – 301 peradresavimais, robots.txt blokavimais ar tiesiog maldavimu, kad Google pats susigaudytų.
Techniškai tai atrodo taip – HTML puslapio <head> sekcijoje įdedamas šis elementas:
<link rel="canonical" href="https://jusu-svetaine.lt/pagrindinis-puslapis/" />Šis žymuo iš esmės sako Google: „Hei, žinau, kad šis turinys pasiekiamas keliais adresais, bet šitas yra tas, kurį nori rodyti paieškos rezultatuose.” Tai signalas, ne direktyva – ir čia prasideda dauguma nesusipratimų.
Duplikuoto turinio problema – ji didesnė nei manote
Prieš einant prie technikalijų, verta suprasti, kodėl canonical tag apskritai reikalingas. Duplikuotas turinys internete yra kur kas labiau paplitęs nei atrodo iš pirmo žvilgsnio.
Pagalvokite apie tipišką e-komercijos svetainę. Vienas produktas gali būti pasiekiamas per:
https://parduotuve.lt/batai/sportiniai/nike-air-maxhttps://parduotuve.lt/nike/batai/nike-air-maxhttps://parduotuve.lt/batai/nike-air-max?color=redhttps://parduotuve.lt/batai/nike-air-max?ref=newsletterhttps://parduotuve.lt/batai/nike-air-max?sort=price&page=1
Tai jau penki skirtingi URL adresai su iš esmės tuo pačiu turiniu. Google crawleris visa tai indeksuoja, bando suprasti, kuris yra svarbiausias, ir dažnai suklysta. Rezultatas – jūsų SEO pastangos išsiskaido tarp kelių URL, o ne koncentruojasi į vieną.
Be to, yra ir kitos situacijos, kurias žmonės dažnai pamiršta:
- HTTP vs HTTPS – jei neturite tinkamo peradresavimo, abu variantai gali būti indeksuojami
- WWW vs non-WWW – klasika, kuri vis dar kankina daug svetainių
- Trailing slash problema –
/puslapisir/puslapis/Google gali traktuoti kaip du skirtingus puslapius - Sindikatinis turinys – kai jūsų straipsniai publikuojami kitose svetainėse
- Spausdinimo versijos –
?print=1parametrai sukuria atskirus URL
Vienas klientas, su kuriuo dirbau, turėjo maždaug 15 000 puslapių svetainę. Po audito paaiškėjo, kad realiai unikalaus turinio buvo apie 4 000 puslapių – likę 11 000 buvo įvairūs duplikatai, filtravimo kombinacijos ir URL parametrų variantai. Canonical tag teisingas naudojimas toje situacijoje buvo ne kosmetinis pataisymas, o esminis SEO pagrindas.
Kaip canonical tag veikia iš tikrųjų – signalai, ne komandos
Čia reikia sustoti ir paaiškinti vieną dalyką, kuris daugelį nuvilia. Canonical tag yra rekomendacija, o ne privaloma instrukcija. Google gali ją ignoruoti. Ir kartais ignoruoja.
Google Search Console dokumentacija aiškiai sako, kad canonical tag yra „stiprus signalas”, bet ne „direktyva”. Tai reiškia, kad Google turi teisę nuspręsti, jog jūs klystate, ir pasirinkti kitą canonical URL nei nurodėte. Tai gali nutikti dėl kelių priežasčių:
Pirma, jei canonical URL, kurį nurodote, pats neturi pakankamai autoritetingumo arba yra sunkiai pasiekiamas. Antra, jei kiti signalai (vidinės nuorodos, sitemaps, išorinės nuorodos) rodo į kitą URL kaip pagrindinį. Trečia, jei canonical tag yra techniškai neteisingas arba prieštaringas.
Dėl šios priežasties canonical tag niekada neturėtų būti vienintelis jūsų duplikuoto turinio sprendimas. Jis veikia geriausiai kartu su:
- Tinkamais 301 peradresavimais ten, kur įmanoma
- Konsistentiškomis vidinėmis nuorodomis (visada nukreipiančiomis į canonical URL)
- Sitemap failu, kuriame yra tik canonical URL
- Tinkamu URL parametrų valdymu Google Search Console
Praktinis patarimas: po canonical tag įdiegimo patikrinkite Google Search Console skiltyje „URL Inspection”, kurį URL Google laiko canonical. Jei tai ne tas, kurį nurodėte – kažkas negerai ir reikia giliau analizuoti.
Dažniausios klaidos ir kaip jos atrodo realybėje
Per savo darbo metus esu matęs canonical tag klaidų visokiausių. Kai kurios juokingos, kai kurios tikrai skaudžios SEO prasme. Išvardinsiu dažniausias.
Klaida #1: Canonical tag nukreipia į 404 puslapį. Skamba absurdiškai, bet nutinka dažniau nei norėtųsi. Puslapis ištrinamas, o canonical tag lieka rodantis į nebeegzistuojantį URL. Google tada tiesiog ignoruoja signalą arba dar labiau supainioja indeksavimą.
Klaida #2: Kiekvienas puslapis canonical’ina save į kitą puslapį. Matau tai dažnai puslapiuotuose sąrašuose. Žmogus nusprendžia, kad visos kategorijos puslapių paginacijos versijos turi canonical nukreipti į pirmą puslapį. Tai neteisinga. Jei /kategorija/page/2/ turi unikalų turinį (skirtingus produktus), jis neturėtų canonical’inti į /kategorija/. Google tada gali nuspręsti visai neindeksuoti antrojo puslapio, o tai reiškia, kad dalis jūsų produktų bus nematomi.
Klaida #3: Self-referencing canonical nėra visur. Self-referencing canonical – tai situacija, kai puslapis nurodo save kaip canonical. Tai rekomenduojama praktika kiekvienam puslapiui, net jei nėra duplikavimo problemos. Kodėl? Nes tai aiškiai pasako Google, kuris URL yra pageidaujamas, ir apsaugo nuo ateities problemų. Daug svetainių turi canonical tik ten, kur yra žinoma problema, bet pamiršta jį dėti ant visų puslapių.
Klaida #4: Canonical tag HTTP puslapyje nukreipia į HTTPS, bet peradresavimo nėra. Tai sukuria situaciją, kai Google žino, kad HTTPS yra canonical, bet vis tiek gali crawlinti HTTP versiją. Geriau turėti ir canonical, ir 301 peradresavimą.
Klaida #5: Canonical tag JavaScript’e, o ne HTML. Jei jūsų canonical tag renderinamas per JavaScript, Google gali jo nepamatyti pirmo crawlo metu. Visada dėkite canonical į statinį HTML <head>.
Klaida #6: Keletas canonical tagų viename puslapyje. Kai kurių CMS sistemų pluginai ar temos gali generuoti kelis canonical tagus. Google tokiu atveju ignoruoja visus. Visada patikrinkite puslapio source kodą ir įsitikinkite, kad canonical tag yra tik vienas.
Cross-domain canonical – galingas, bet rizikuotas įrankis
Canonical tag gali nukreipti ne tik į tą pačią svetainę, bet ir į visiškai kitą domeną. Tai vadinama cross-domain canonical ir yra labai naudinga sindikatinio turinio situacijose.
Tarkime, jūs parašėte straipsnį savo tinklaraštyje ir jis buvo perspausdintas dideliame naujienų portale. Jei tas portalas į savo versiją įdeda canonical tag, nukreipiantį į jūsų originalų straipsnį, Google supras, kad jūsų versija yra pirminė. Tai puiku jums – jūs gausite SEO naudą, o ne portalas.
Tačiau čia yra svarbus niuansas: jūs negalite kontroliuoti canonical tagų kitose svetainėse. Galite tik prašyti. Jei svetainė, kuri perspausdino jūsų turinį, neįdeda canonical, Google pats sprendžia, kuri versija yra originali. Dažniausiai jis tai padaro teisingai, bet ne visada.
Praktinis patarimas sindikatinio turinio situacijai: visada prašykite partnerių svetainių įdėti canonical tag, nukreipiantį į jūsų originalą. Jei jie nesutinka – bent jau įsitikinkite, kad jūsų originalas buvo publikuotas anksčiau ir turi daugiau išorinių nuorodų.
Cross-domain canonical taip pat naudojamas, kai perkeliate svetainę į naują domeną ir norite išlaikyti SEO vertę. Tačiau šiuo atveju 301 peradresavimas yra stipresnis signalas ir geriau veikia. Cross-domain canonical tokioje situacijoje gali būti papildoma priemonė, bet ne pagrindinis sprendimas.
Canonical tag ir JavaScript frameworks – šiuolaikinė galvos skausmo priežastis
Next.js, Nuxt, Angular, React SPA – šiuolaikiniai JavaScript frameworkai sukuria papildomų iššūkių su canonical tagais. Problema ta, kad daugelis šių frameworkų renderina turinį kliento pusėje, o Google crawleris ne visada laukia, kol JavaScript bus įvykdytas.
Next.js atveju canonical tag reikia dėti per next/head komponentą:
import Head from 'next/head'
export default function Page() {
return (
<Head>
<link rel="canonical" href="https://jusu-svetaine.lt/puslapis" />
</Head>
)
}Next.js 13+ su App Router naudoja kitokį metodą per metadata objektą:
export const metadata = {
alternates: {
canonical: 'https://jusu-svetaine.lt/puslapis',
},
}Šis metodas yra geresnis, nes Next.js automatiškai įdeda canonical į serverio pusėje renderintą HTML, o ne laukia JavaScript vykdymo.
Jei dirbate su React SPA be serverio pusės renderinimo – rimtai apsvarstykite, ar jūsų SEO reikalavimai apskritai suderinami su tokia architektūra. Canonical tag problema yra tik viena iš daugelio SEO iššūkių, kuriuos kelia kliento pusės renderinimas.
Nuxt.js situacija panašesnė į Next.js – naudokite useHead composable arba useSeoMeta ir įsitikinkite, kad SSR yra įjungtas.
Canonical tag e-komercijoje – kur tai tampa tikrai sudėtinga
E-komercijos svetainės yra canonical tag iššūkių epicentras. Čia yra keletas konkrečių scenarijų ir kaip juos spręsti.
Produktų filtravimas ir rūšiavimas. Kai vartotojas filtruoja produktus pagal spalvą, dydį ar kainą, URL paprastai keičiasi: /batai?color=red&size=42&sort=price_asc. Šie filtruoti puslapiai dažniausiai neturėtų būti indeksuojami, nes jų turinys yra dinamiškas ir dubliuojasi. Canonical turėtų nukreipti į pagrindinį kategorijos puslapį.
Tačiau yra išimčių. Jei filtruotas puslapis turi aiškią paieškos vertę (pvz., „raudonos spalvos Nike batai” yra populiari paieška), gali būti verta sukurti atskirą, statinį puslapį šiai kategorijai ir leisti jam būti indeksuojamam su savo canonical.
Produktai keliose kategorijose. Jei tas pats produktas pasiekiamas per /batai/sportiniai/nike-air-max ir /nike/batai/nike-air-max, turite pasirinkti vieną kaip canonical. Rekomenduoju rinktis URL, kuris yra trumpesnis, logiškesnis ir kuriam nukreipiate daugiausia vidinių nuorodų.
Produktų variantai. Tai subtilesnė situacija. Jei turite produktą su keliais variantais (skirtingos spalvos, dydžiai), kiekvienas variantas gali turėti savo URL. Čia yra du požiūriai:
- Visi variantai canonical’ina į pagrindinį produkto puslapį (prarandate galimybę ranktis pagal specifinius variantus)
- Kiekvienas variantas yra atskiras puslapis su savo canonical (reikalauja daugiau darbo, bet gali duoti daugiau organinio srauto)
Teisingas atsakymas priklauso nuo to, ar žmonės ieško konkrečių variantų. Jei „Nike Air Max raudonos” yra populiari paieška – verta turėti atskirą puslapį. Jei ne – geriau canonical’inti į pagrindinį.
Puslapiavimas (pagination). Kaip minėjau anksčiau – nepriverčiame visų paginacijos puslapių canonical’inti į pirmą. Kiekvienas paginacijos puslapis turi savo unikalų turinį. Naudokite self-referencing canonical kiekviename paginacijos puslapyje.
Kai canonical tag nepakanka – ir ką tada daryti
Canonical tag yra puikus įrankis, bet jis nėra visų problemų sprendimas. Yra situacijų, kai kiti metodai yra geresni arba reikalingi papildomai.
Jei turite puslapius, kurių visiškai nenorite indeksuoti – naudokite noindex meta tag arba robots.txt. Canonical tag neužkerta kelio indeksavimui – jis tik nurodo, kuris URL yra pageidaujamas. Puslapis su canonical vis tiek gali atsirasti indekse.
Jei norite visiškai sujungti du URL – 301 peradresavimas yra stipresnis signalas nei canonical. Jei galite techniškai įgyvendinti peradresavimą, darykite tai. Canonical palikite situacijoms, kur peradresavimas nėra įmanomas ar praktiškas.
Jei problema yra URL parametrai (UTM parametrai, sesijų ID ir pan.) – Google Search Console turi URL parametrų valdymo įrankį. Jį naudojant galima nurodyti Google, kaip traktuoti specifinius parametrus. Tai gali būti efektyviau nei canonical kiekvienam parametrų deriniui.
Jei turite tarptautinę svetainę su turiniu keliomis kalbomis – canonical tag turi veikti kartu su hreflang atributais. Čia dažna klaida: žmonės canonical’ina visas kalbų versijas į vieną (dažniausiai anglišką) puslapį. Tai neteisinga. Kiekviena kalbos versija turėtų canonical’inti į save, o hreflang nurodo ryšį tarp skirtingų kalbų versijų.
Štai kaip turėtų atrodyti lietuviškos versijos puslapio head:
<link rel="canonical" href="https://svetaine.lt/lt/puslapis/" />
<link rel="alternate" hreflang="lt" href="https://svetaine.lt/lt/puslapis/" />
<link rel="alternate" hreflang="en" href="https://svetaine.lt/en/page/" />
<link rel="alternate" hreflang="x-default" href="https://svetaine.lt/en/page/" />Canonical tag – ne magija, o higiena
Geriausias būdas galvoti apie canonical tag yra kaip apie pagrindinę svetainės higieną. Tai ne kažkas, kas staiga pakels jūsų pozicijas paieškoje. Tai kažkas, kas užtikrina, kad jūsų SEO pastangos nebus švaistomas dėl techninių netvarkų.
Jei canonical tagų nėra arba jie neteisingi, jūsų link building pastangos gali skaidytis tarp kelių URL versijų. Jūsų puikiai optimizuoti puslapiai gali konkuruoti patys su savimi. Google gali indeksuoti netinkamas URL versijas. Visa tai yra lėtas, nematomais nuostolis, kuris kaupiasi laikui bėgant.
Praktinis veiksmų planas, jei dar nesate sistemingai tvarkę canonical tagų:
- Atlikite crawl su Screaming Frog ar panašiu įrankiu ir suraskite visus puslapius be canonical arba su neteisingais canonical
- Patikrinkite Google Search Console Coverage ataskaitą – ar nėra indeksuojamų URL, kurių nenorite
- Įdiekite self-referencing canonical visur, kur jo nėra
- Identifikuokite duplikuoto turinio grupes ir nustatykite, kuris URL kiekvienoje grupėje turėtų būti canonical
- Patikrinkite, ar vidinės nuorodos visada nukreipia į canonical URL, o ne į duplikatus
- Atnaujinkite sitemap – jame turėtų būti tik canonical URL
- Po mėnesio patikrinkite Google Search Console ir įsitikinkite, kad Google priima jūsų canonical signalus
Canonical tag nėra sudėtingas konceptas, bet jo teisingas įgyvendinimas reikalauja sisteminio požiūrio ir nuolatinio stebėjimo. Svetainės auga, keičiasi, atsiranda naujų URL struktūrų – canonical tagų valdymas turi būti nuolatinis procesas, o ne vienkartinis projektas. Ir tai, kad Google kartais ignoruoja jūsų canonical signalus, nėra priežastis nustoti juos naudoti – tai priežastis užtikrinti, kad visi kiti signalai taip pat rodytų tą patį kryptį.
