Hreflang žymos

Kas iš tikrųjų yra hreflang ir kodėl tai ne tik „dar viena SEO žymė”

Jei kada nors bandei paleisti daugiakalbę svetainę ir stebėjai, kaip Google rodo netinkamą kalbos versiją netinkamos šalies vartotojams – žinai tą jausmą. Lietuvis gauna anglišką puslapį, vokietis – prancūzišką, o tu sėdi ir galvoji, kur viskas nuėjo ne taip. Atsakymas dažniausiai tas pats: hreflang žymos arba nėra, arba yra, bet neteisingai sukonfigūruotos.

Hreflang – tai HTML atributas, kurį Google (ir iš dalies Yandex) naudoja tam, kad suprastų, kuri puslapio versija skirta kuriai auditorijai. Techniškai tai atrodo paprastai: nurodai kalbą, nurodai šalį, ir paieškos variklis žino, ką rodyti. Praktiškai – tai viena iš tų sričių, kur klaidos slepiasi kiekviename kampe.

Svarbu suprasti vieną dalyką nuo pat pradžių: hreflang nėra skirtas pasakyti Google, kokia kalba parašytas puslapis. Tam yra lang atributas HTML elemente ir Content-Language HTTP antraštė. Hreflang yra skirtas pasakyti: „Šis puslapis egzistuoja keliomis versijomis, ir štai kuri versija skirta kuriam vartotojui.” Tai santykių žemėlapis tarp puslapių, ne kalbos deklaracija.

Kaip hreflang žymos atrodo techniškai

Yra trys būdai implementuoti hreflang: per HTML <head> sekciją, per HTTP antraštes arba per XML sitemapą. Kiekvienas turi savo privalumų ir trūkumų.

Dažniausiai naudojamas HTML metodas atrodo taip:

<link rel="alternate" hreflang="lt" href="https://example.com/lt/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/" />
<link rel="alternate" hreflang="de" href="https://example.com/de/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/" />

Atkreipk dėmesį į x-default – tai specialus atributas, nurodantis „numatytąją” versiją vartotojams, kurių kalba/šalis neatitinka nė vienos nurodytos. Tai gali būti anglų kalba, pagrindinis domenų pasirinkimo puslapis arba bet kas, ką nusprendei rodyti „neklasifikuotiems” lankytojams.

HTTP antraščių metodas naudingas, kai kalbi apie PDF failus ar kitus ne-HTML resursus, kuriems negali tiesiogiai įterpti HTML kodo. Jis atrodo taip:

Link: <https://example.com/en/>; rel="alternate"; hreflang="en",
      <https://example.com/lt/>; rel="alternate"; hreflang="lt"

XML sitemap metodas yra geras pasirinkimas didelėms svetainėms, nes leidžia centralizuotai valdyti visus hreflang ryšius, neliečiant kiekvieno puslapio kodo. Struktūra atrodo taip:

<url>
  <loc>https://example.com/lt/</loc>
  <xhtml:link rel="alternate" hreflang="lt" href="https://example.com/lt/"/>
  <xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/"/>
</url>

Praktinis patarimas: jei turi didelę e-komercijos svetainę su tūkstančiais puslapių ir keliomis kalbomis, XML sitemap metodas yra gerokai lengviau valdomas. HTML metodas puikiai veikia mažesnėms svetainėms, bet kai puslapių skaičius auga, kiekvieno puslapio <head> sekcija gali tapti tikra košmaru.

Kalbos kodai ir šalies kodai – kur žmonės klysta

Čia prasideda tikras galvos skausmas. Hreflang naudoja ISO 639-1 kalbos kodus ir ISO 3166-1 Alpha-2 šalies kodus. Teoriškai aišku, praktiškai – pilna spąstų.

Kalbos kodas vienas: lt lietuvių kalbai, en anglų, de vokiečių. Šalies kodas pridedamas su brūkšneliu: en-GB britų anglų, en-US amerikiečių anglų, de-AT Austrijos vokiečių.

Dažniausios klaidos:

• Didžiosios/mažosios raidės – techniškai Google sako, kad nesvarbu, bet praktikoje rekomenduojama rašyti kalbos kodą mažosiomis, šalies kodą didžiosiomis: en-GB, ne EN-gb ar EN-GB.
• Neteisingi kodai – en-UK neegzistuoja. Jungtinė Karalystė yra GB, ne UK. Tai viena iš labiausiai paplitusių klaidų.
• Kalbos be šalies – kartais pakanka tik kalbos kodo. Jei turi vieną anglų kalbos versiją visam pasauliui, hreflang="en" yra teisingas pasirinkimas. Nereikia priverstinai pridėti šalies kodo, jei neturi skirtingų versijų skirtingoms šalims.
• Kinų kalbos ypatybės – zh-Hans yra supaprastinta kinų (Kinija, Singapūras), zh-Hant yra tradicinė kinų (Taivanas, Honkongas). Čia naudojami skript kodai, ne šalies kodai.

Praktinis patarimas: prieš implementuodamas, susikurk lentelę su visomis savo kalbų/šalių kombinacijomis ir patikrink kiekvieną kodą. Viena klaida vienoje žymėje gali sugadinti visą hreflang implementaciją tam puslapiui.

Abipusiškumo taisyklė – ta, kurią visi pamiršta

Tai bene svarbiausia hreflang taisyklė ir kartu labiausiai ignoruojama. Hreflang žymos turi būti abipusės. Tai reiškia: jei puslapis A nurodo puslapį B kaip alternatyvą, puslapis B turi nurodyti puslapį A kaip alternatyvą. Ir abu turi nurodyti save patys.

Pavyzdys: turi lietuvišką ir anglišką puslapio versijas.

Lietuviškame puslapyje (/lt/apie-mus/) turi būti:

<link rel="alternate" hreflang="lt" href="https://example.com/lt/apie-mus/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/about-us/" />

Angliškame puslapyje (/en/about-us/) turi būti:

<link rel="alternate" hreflang="lt" href="https://example.com/lt/apie-mus/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/about-us/" />

Jei šis abipusiškumas neįgyvendintas, Google gali ignoruoti hreflang žymas arba elgtis su jomis neprognozuojamai. Tai nėra rekomendacija – tai būtinybė.

Kodėl tai tokia dažna problema? Nes daugelis sistemų generuoja hreflang žymas automatiškai, bet tik iš vienos pusės. CMS sistema prideda žymas į kiekvieną puslapį, bet jei vienas puslapis neturi tinkamos nuorodos atgal, grandinė nutrūksta. Ypač dažnai tai nutinka, kai puslapiai pridedami rankiniu būdu arba kai tam tikros kalbos versijos yra neužbaigtos.

Skirtingos domenų struktūros ir kaip jos veikia hreflang

Daugiakalbė svetainė gali būti struktūruota keliais būdais, ir kiekvienas turi savo implikacijas hreflang implementacijai:

ccTLD (šalies domenai) – example.lt, example.de, example.fr. Stipriausias geografinis signalas Google, bet brangiausia ir sudėtingiausia struktūra. Hreflang čia veikia tarp skirtingų domenų, kas techniškai yra visiškai teisinga, bet reikalauja kruopštaus valdymo.

Subdomenai – lt.example.com, de.example.com. Vidutinis variantas – lengviau valdyti nei ccTLD, bet Google vis tiek traktuoja juos kaip atskirus subjektus, kas gali paveikti autoritetą.

Poaplankiai (subdirektorijos) – example.com/lt/, example.com/de/. Dažniausiai rekomenduojamas variantas SEO požiūriu, nes visas autoritetą koncentruoja viename domene. Hreflang implementacija čia paprastesnė, nes viskas yra po vienu stogu.

Praktinis patarimas: jei tik pradedate daugiakalbę svetainę ir neturite specifinių priežasčių rinktis ccTLD ar subdomenus, eikite su poaplankiais. Mažiau galvos skausmo, lengviau valdyti hreflang, ir autoritetą kaupi vienoje vietoje.

Vienas svarbus niuansas: jei naudoji skirtingus domenus ar subdomenus, hreflang žymose turi nurodyti pilnus URL su domenu, ne santykinius kelius. href="/lt/apie-mus/" neveiks – turi būti href="https://example.lt/apie-mus/".

Dažniausios hreflang klaidos ir kaip jas rasti

Kalbėjome apie abipusiškumą, bet tai tik viena iš daugelio galimų problemų. Štai pilnesnis klaidų sąrašas, kurį matau vėl ir vėl auditų metu:

Nukreipimas į 404 puslapius – hreflang žymoje nurodytas URL grąžina 404 klaidą. Google ignoruos tokią žymą. Tai nutinka, kai puslapiai ištrinami, bet hreflang žymos neatnaujinamos.

Nukreipimas į peradresuotus puslapius – jei hreflang žymoje nurodytas URL peradresuoja į kitą URL (301 redirect), Google gali sekti peradresavimą, bet tai nėra gera praktika. Visada nurodyk galutinį URL.

Kanonizacijos konfliktas – jei puslapis turi rel="canonical" nurodantį į kitą puslapį, bet hreflang žymos nurodo į originalų puslapį, tai sukuria prieštaravimą. Taisyklė: hreflang žymose nurodyti URL turi sutapti su tų puslapių canonical URL.

Trūkstama x-default žyma – ne visada būtina, bet labai rekomenduojama. Be jos, vartotojai, kurių kalba/šalis neatitinka nė vienos versijos, gali gauti atsitiktinę versiją.

Skirtingi URL formatai – viename puslapyje nurodytas https://example.com/lt/, kitame https://example.com/lt (be trailing slash). Google gali traktuoti juos kaip skirtingus URL. Būk nuoseklus.

Kaip rasti šias klaidas? Keletas įrankių:

• Google Search Console – International Targeting ataskaita rodo hreflang klaidas, bet ne visas ir ne visada greitai.
• Screaming Frog – vienas geriausių įrankių hreflang auditui. Gali nuskaityti visą svetainę ir parodyti visas hreflang problemas, įskaitant abipusiškumo klaidas.
• Ahrefs ir Semrush – abi platformos turi site audit funkcijas su hreflang tikrinimais.
• hreflang Testing Tool – paprastas online įrankis greitam vieno puslapio patikrinimui.

Hreflang ir dinaminis turinys – kai viskas tampa sudėtingiau

Statinės svetainės su hreflang yra vienas dalykas. Bet ką daryti, kai turi e-komercijos platformą su tūkstančiais produktų, kurie dinamiškai generuojami iš duomenų bazės? Arba kai turinys skiriasi priklausomai nuo vartotojo?

Dinaminis hreflang generavimas reikalauja, kad kiekvienas puslapis žinotų savo alternatyvias versijas. Tai reiškia, kad duomenų bazėje turi būti saugomi ryšiai tarp skirtingų kalbų versijų. Paprasčiausias būdas – URL struktūra, kuri leidžia automatiškai generuoti alternatyvius URL.

Pavyzdžiui, jei produkto URL struktūra yra /[kalba]/produktai/[slug]/, galima automatiškai generuoti hreflang žymas, tiesiog pakeičiant kalbos dalį URL. Bet tai veikia tik tada, kai slug yra vienodas visose kalbose arba kai turi aiškų vertimų žemėlapį.

Sudėtingiau, kai skirtingų kalbų puslapiai turi skirtingus slug’us (kas yra gera SEO praktika – versti URL į vietinę kalbą). Tada reikia aiškios duomenų bazės struktūros, kuri saugo ryšius tarp puslapių.

Praktinis patarimas didelėms svetainėms: jei naudoji WordPress, įskiepiai kaip WPML ar Polylang automatiškai tvarko hreflang žymas. Jei naudoji custom CMS ar framework, investuok laiko į tinkamą hreflang generavimo logiką nuo pat pradžių – vėliau tai taisyti bus daug brangiau.

Dar vienas svarbus aspektas: JavaScript rendered puslapiai. Jei hreflang žymos generuojamos JavaScript, Google gali jų nepamatyti arba pamatyti su vėlavimu. Visada geriau turėti hreflang žymas server-side rendered HTML, ne JavaScript. Jei naudoji SPA (Single Page Application), įsitikink, kad SSR (Server-Side Rendering) teisingai generuoja šias žymas.

Kai hreflang nepadeda – ir ką daryti tada

Reikia būti sąžiningam: hreflang nėra magiška lazdelė. Yra situacijų, kai jis neveikia taip, kaip tikimasi, ir situacijų, kai jo visai nereikia.

Pirma, hreflang yra patarimas Google, ne direktyva. Skirtingai nuo noindex, kurį Google paprastai gerbia, hreflang yra tik rekomendacija. Google gali nuspręsti rodyti kitą versiją, jei mano, kad ji labiau tinkama vartotojui. Tai nutinka, kai, pavyzdžiui, vartotojas ieško anglų kalba iš Lietuvos – Google gali nuspręsti rodyti anglišką versiją, net jei hreflang nurodo lietuvišką.

Antra, hreflang neišsprendžia turinio kokybės problemų. Jei tavo vertimai yra blogi arba puslapiai neoptimizuoti vietinei rinkai, hreflang nepakeis situacijos. Tai tik techninis signalas – turinys turi dirbti pats.

Trečia, hreflang nepadeda su duplicate content problemomis, jei puslapiai iš tikrųjų yra identiški. Jei tavo „skirtingos kalbų versijos” iš tikrųjų yra tas pats turinys su minimaliomis variacijomis, Google gali traktuoti juos kaip duplikatus, nepaisant hreflang žymų.

Kada hreflang tikrai reikalingas? Kai turi realiai skirtingą turinį skirtingoms kalboms ar šalims, kai matai, kad Google rodo netinkamas versijas vartotojams, ir kai turi pakankamai resurso teisingai implementuoti ir palaikyti šias žymas. Maža svetainė su dviem kalbomis, kur turinys beveik identiškas – galbūt hreflang nėra prioritetas. Didelė tarptautinė platforma – tai būtinybė.

Galiausiai, hreflang yra viena iš tų techninių SEO sričių, kur pusė darbo yra teisingas diegimas, o kita pusė – nuolatinis monitoringas. Svetainės keičiasi, puslapiai pridedami ir trinami, URL struktūros atnaujinamos. Kiekvieną kartą, kai keičiasi svetainės struktūra, reikia patikrinti, ar hreflang žymos vis dar teisingos. Tai nėra „nustatyk ir pamiršk” – tai gyvas, nuolat prižiūrimas komponentas, kuris, kai veikia teisingai, vartotojui yra visiškai nematomas, bet paieškos varikliui – labai svarbus orientyras.