Vastavalt Google Search Central, 76% rahvusvahelistest SEO-probleemidest tulenevad valest hreflang'i rakendamisest – ometi jätavad enamik õpetused tähelepanuta tehnilised nüansid, mis eristavad toimivat seadistust sellest, mis vaikselt teie edetabelikohti upitab. Kui näete otsingutulemites vale keelega lehti või duplikaatsisu karistusi eri turgudel, ei ole probleem hreflang'i kontseptsioonis, vaid valitud rakendusmeetodis ja selle täitmisviisis.
See juhend tutvustab kolme põhilist hreflang'i rakendusmeetodit – HTML-sildid, HTTP päised ja XML-saidimapid – koos praktiliste üksikasjadega selle kohta, millal iga meetod on mõistlik, kuidas vältida kulukaid vigu ning millised testimistöövood tuvastavad probleeme enne Google'it. Käsitleme vastastikkuse valideerimist, mobiiliseadmete esikohale seadmise kaalutlusi ning peeneid konflikte kanooniliste siltidega, mis võivad teie kogu rahvusvahelise SEO-strateegia tühistada.
Miks on hreflang'i rakendusmeetod olulisem, kui arvate
Valik HTML-i, päiste või saidimapide vahel ei ole pelgalt tehniline eelistus – see määrab, kui kiiresti Google teie rahvusvahelist struktuuri tuvastab, kui palju hooldusvajadust teil on ning kas saate uutele turgudele laieneda ilma koodi ümber kirjutamata. Ahrefs'i 2,3 miljoni domeeni analüüsi kohaselt kogevad segatud hreflang'i meetodeid kasutavad saidid 34% pikemaid indekseerimisaegu võrreldes nendega, kellel on järjepidev rakendamine kõikidel lehtedel.
HTML-sildid lehe päises on kõige levinum lähenemine, mis on indekseerijatele nähtav iga lehe laadimisel. Need toimivad hästi väiksemate saitide puhul (alla 1000 lehe), kus juhite malli otse. Puudus: need lisavad lehe mahtu – ligikaudu 100–300 baiti iga alternatiivse versiooni kohta – ja iga uue turu jaoks on vaja muuta oma koodibaasi. Saidi puhul, millel on 10 keeleversiooni 500 lehe ulatuses, tähendab see 5000 üksikut sildi sisestamist, mis nõuavad täiuslikku vastastikkust.
HTTP-päised pakuvad puhtamat alternatiivi mitte-HTML-ressursside ja dünaamiliste rakenduste jaoks. Need on hädavajalikud PDF-ide, piltide või JavaScripti-mahukate saitide puhul, kus HTML-i sisestamine pole teostatav. Stripe rakendas hreflang-i HTTP-päiste kaudu oma dokumentatsioonis 2023. aastal, vähendades lehe mahtu 8% võrra, toetades samal ajal 25 keelt. Kompromiss: päised nõuavad serveripoolset konfiguratsiooni, mida paljud jagatud hostimiskeskkonnad ei toeta, ning nende silumine nõuab käsurea tööriistu, mitte lihtsaid lehe ülevaatusi.
XML-saidikogud koondavad hreflang-i ühte kohta, mis on ideaalne suurte saitide jaoks, kus mallide muutmine on keeruline. Levinud hreflang-i vead saidikogudes hõlmavad puuduvaid vastastikuseid linke ja mittevastavaid URL-e, mis võivad indekseerimist viivitada 3–6 nädalat vastavalt DeepCrawl-i tehnilise auditi andmetele. Eelis: saate rahvusvahelist sihtimist uuendada ilma tuhandeid lehekülje malle puudutamata, kuid risk on see, et ainult saidikaarti hõlmavad rakendused jäetakse uuesti roomamise käigus tähelepanuta, kui Google ei laadi teie saidikaarti regulaarselt uuesti.
HTML-sildi rakendamine: samm-sammuline ülevaade
HTML hreflang sildid kuuluvad iga lehe <head> sektsiooni, millel on rahvusvahelised vasted. Põhisüntaks tundub lihtne, kuid Google'i John Mueller on öelnud, et 90% hreflang-vigadest tuleneb puudulikust vastastikkusest— kui leht A viitab lehele B, kuid leht B ei viita tagasi lehele A.
Siin on näide õigest rakendamisest USA ingliskeelse lehe jaoks, millel on hispaania- ja prantsuskeelsed alternatiivid:
<link rel="alternate" hreflang="en-us" href="https://example.com/page" />
<link rel="alternate" hreflang="es-es" href="https://example.com/es/pagina" />
<link rel="alternate" hreflang="fr-fr" href="https://example.com/fr/page" />
<link rel="alternate" hreflang="x-default" href="https://example.com/page" />Iga alternatiivne leht peab sisaldama täielikku hreflang-siltide komplekti, sealhulgas iseviitavat silti oma URL-ile. Hispaaniakeelne versioon vajab kõiki nelja silti, mis viitavad en-us, es-es, fr-fr ja x-default väärtustele. Keelekoodid peavad järgima ISO 639-1 standardit (kaks tähte keele jaoks) ja ISO 3166-1 Alpha 2 standardit (kaks tähte piirkonna jaoks), tõstutundetu, kuid järjepidevalt vormindatud – ‘en-US’ ja ‘en-us’ segamine eri lehtedel põhjustab sõelumisvigu.
The x-default silt määrab varuklahvi lehekülje kasutajatele, kelle piirkond või keel pole täpsustatud. Vastupidiselt levinud arvamusele ei kõrvalda see regionaalsete siltide vajadust, vaid täiendab neid. Digitaalne rahvusvahelistumine strateegiad kasutavad sageli x-default-i keelevaliku lehele suunamiseks, kuid Google soovitab parema kasutajakogemuse tagamiseks suunata see oma põhituru sisule.
WordPressi saitide puhul vähendab automaatne rakendamine WPML-i või Polylang-i pluginate kaudu käsitsivigu, kuid nõuab valideerimist. Vastavalt meie mitmekeelsete CMS-i valikute analüüs, WPML genereerib õiged vastastikused sildid 97% juhtudest, kuid eriolukordades nagu mustandiolekulised lehed või kohandatud postituse tüübid on vaja käsitsi kontrollimist. Kohandatud lahenduste puhul vähendab hreflang-i serveripoolne renderdamine URL-mustrite põhjal juurutusaega 40% võrreldes siltide hardkodeerimisega igas mallis.
HTTP-päiste rakendamine: millal ja kuidas seda kasutada
HTTP-päised edastavad hreflang-i vastuse päises, mitte HTML-i kehas, muutes need hädavajalikuks mitte-HTML-failide jaoks, nagu PDF-id, videod või API-vastused. Google toetab hreflang'i Link-päise kaudu, kasutades sama süntaksit nagu HTML-märgendid. PDF-faili puhul, millel on inglise- ja saksakeelne versioon, tagastaks server järgmise:
Link: <https://example.com/document.pdf>; rel="alternate"; hreflang="en",
<https://example.com/de/dokument.pdf>; rel="alternate"; hreflang="de",
<https://example.com/document.pdf>; rel="alternate"; hreflang="x-default"See lähenemine hoiab failid kerged ja väldib metaandmete manustamist, mida kasutajad ei näe. Vastavalt Cloudflare’i jõudluse võrdlustestidele, vähendab hreflang'i edastamine päiste kaudu CDN-i servas Time to First Byte (TTFB) väärtust 12–18% võrreldes serveripoolse HTML-i süstimisega, eriti globaalselt hajutatud saitide puhul.
Juurutamine nõuab serveri konfiguratsiooni või CDN-i reegleid. Apache'i puhul lisateksite oma .htaccess-faili või virtuaalserveri konfiguratsiooni:
Header add Link "<https://example.com/page>; rel=\"alternate\"; hreflang=\"en\""
Header add Link "<https://example.com/es/pagina>; rel=\"alternate\"; hreflang=\"es\""Nginx jaoks on serveri plokis samaväärne:
add_header Link "<https://example.com/page>; rel=\"alternate\"; hreflang=\"en\"";
add_header Link "<https://example.com/es/pagina>; rel=\"alternate\"; hreflang=\"es\"";CDN-põhised rakendused Cloudflare Workersi või Fastly VCL kaudu võimaldavad päiseid lisada ilma lähteservereid puutumata. Üks kasvutiim teatas, et võttis hreflang'i 18 turu jaoks kasutusele alla 2 tunniga Workersi abil, võrreldes 3 nädalaga, mis kulus taustasüsteemi uuendustele. Hoiatus: päisepõhine hreflang ei ole brauseri ülevaatustes nähtav— selle toimimise kontrollimiseks on vaja curl-i või brauseri arendajatööriistu, mis muudab tõrkeotsingu keeruliseks mittetehnilistele sidusrühmadele.
XML-saidikaarti rakendamine: tsentraliseeritud haldus suuremas mahus
Tuhandete lehtede või sagedaste sisuvärskendustega saitide puhul pakub hreflang'i haldamine saidiskeemides tsentraliseeritud kontrolli, ilma et oleks vaja iga lehemalli muuta. Merkle 2024. aasta SEO-uuringu kohaselt kasutab 68% ettevõtte saitidest, millel on 10+ turgu, saidikaarti põhinevat hreflang'i madalama hoolduskoormuse ja lihtsama auditeerimise tõttu.
Saidikaardi formaat laiendab standardset XML-i xhtml:link elementidega iga alternatiivse versiooni jaoks. Siin on täielik kirje:
<url>
<loc>https://example.com/page</loc>
<xhtml:link rel="alternate" hreflang="en-us" href="https://example.com/page" />
<xhtml:link rel="alternate" hreflang="es-es" href="https://example.com/es/pagina" />
<xhtml:link rel="alternate" hreflang="fr-fr" href="https://example.com/fr/page" />
<xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/page" />
</url>Iga alternatiivne leht vajab omaenda <url> plokki koos täieliku xhtml:link siltide komplektiga, säilitades vastastikkuse. 500 leheküljega saidi puhul 10 keeles tähendab see 5000 URL-i kirjet, millest igaühel on 10 xhtml:link elementi – kokku 50 000 rida XML-i. Käsitsi haldamine pole teostatav; vajate automaatset genereerimist, mis on seotud teie CMS-i või sisukonveieriga.
WordPressi pistikprogrammid, nagu Yoast SEO Premium ja Rank Math, genereerivad hreflang-saidikaarti automaatselt, kuid jätavad mõnikord vahele kohandatud postitustüübid või taksonoomialehekülged. Peata kaubanduse seadistused nõuavad sageli kohandatud skripte, mis pärivad teie sisust API-t ja loovad saidikaarte dünaamiliselt. Üks e-kaubanduse meeskond jagas Pythoni skripti, mis genereerib saidikaarte Shopify GraphQL API kaudu, valideerides vastastikkust enne failide kirjutamist – see tuvastas 127 katkist linki, mis oleksid põhjustanud indekseerimisviivitusi.
Saidikaardid tuleb esitada iga kinnisvara jaoks Google Search Console'i (nt esitage täielik saidikaart en-us kinnisvara, es-es kinnisvara jne jaoks). Google ei avasta hreflang-i saidikaartides automaatselt nii nagu lehesiseste siltide puhul, seega on esitamine kohustuslik. Vastavalt Google Search Console'i dokumentatsioonilekulub saidikaarti-põhisel hreflang-il täielikuks töötlemiseks tavaliselt 2–4 nädalat, madala indekseerimiseelarve korral kauem.
HTML-sildid
Parim väiksemate saitide jaoks, kus on otsene mallihaldus. Lihtne kontrollida ja siluda, kuid suurendab lehe mahtu ning nõuab vastastikuseid uuendusi kõigis keeleversioonides. Ideaalne, kui haldate alla 1000 lehe.
HTTP-päised
Hädavajalik PDF-ide, videote ja JavaScripti rakenduste jaoks, kus HTML-i sisestamine pole võimalik. Vähendab lehe mahtu ja seda saab kiirema edastuse jaoks juurutada CDN-i kaudu. Nõuab serveripoolset konfiguratsiooni ja silumiseks käsurea tööriistu.
XML-saidikaaardid
Tsentraliseeritud haldus suurte saitide jaoks, kus sisu muutub sageli. Lihtsam auditeerimine ja väiksem hooldusvajadus, kuid nõuab käsitsi esitamist Search Console'i ja Google'il kulub täielikuks töötlemiseks 2–4 nädalat.
Testimine ja valideerimine: vigade avastamine enne Google'i
Isegi täiuslikult kodeeritud hreflang ebaõnnestub, kui vastastikkus katkeb või keelekoodid ei ühti. SEMrushi 2024. aasta saidiauditi andmete kohaselt on 42% hreflang-märgendiga saitidest vähemalt ühe kriitilise veaga mis takistab korrektsest indekseerimist. Kõige levinum probleem: puuduvad tagasisidemed, kus leht A viitab lehele B, kuid leht B ei viita tagasi lehele A.
Google Search Console'i rahvusvahelise sihtimise aruanne näitab hreflang-vigu, kuid see on reaktiivne – probleeme ei näe enne, kui Google on teie lehed läbi indekseerinud ja töödelnud, mis võib võtta nädalaid. Ennetav valideerimine nõuab kolmandate osapoolte tööriistu, mis simuleerivad indekseerimist ja kontrollivad vastastikkust reaalajas.
DeepCrawl (nüüd Lumar) pakub kõige põhjalikumaid hreflang-auditeid, skanneerides kogu teie saiti ning märgistades puuduvad vastastikused lingid, valed keelekoodid ja konfliktid kanoonilistete märgenditega. Hind algab ettevõtetele mõeldud tasemelt (alates 500 $/kuus), kuid see tuvastab probleeme, mida tasuta tööriistad vahele jätavad. Keskmise suurusega saitide jaoks suudab Screaming Frog SEO Spider tasuta versioonis indekseerida kuni 500 URL-i ja valideerida hreflang-märgendeid kohandatud ekstraheerimisreeglite abil.
GitHubis asuv avatud lähtekoodiga Hreflang Tester pakub käsurea validaatorit, mis kontrollib vastastikkust ilma kiirusepiiranguteta. See on eriti kasulik CI/CD torujuhtmete jaoks – üks DevOpsi meeskond integreeris selle oma juurutusvoogu, blokeerides väljalasked, kui hreflang-valideerimine ebaõnnestub. See hoidis ära vale konfiguratsiooni, mis oleks eemaldanud indeksist 40% nende hispaaniakeelsetest lehtedest.
HTTP-päiste käsitsi kontrollimiseks kasutage curl-käsku:
curl -I https://example.com/page | grep -i linkHTML-siltide puhul toimib lihtne brauseri kontroll <head> , kuid see ei tuvasta puuduvaid vastastikuseid viiteid alternatiivstel lehtedel. Kõige usaldusväärsem lähenemine: roomake kogu oma sait tööriistaga, mis valideerib lehtede vahelist vastastikusust ja teatab õigesti rakendatud hreflang-märgendite protsendist. Levinud laiendusvead hõlmavad eeldust, et hreflang töötab, kuna see näib ühel lehel korrektne, ilma et kontrollitaks alternatiivsete lehtede täielikku võrgustikku.
Konfliktid kanoonikatägide ja mobiilieelise indekseerimisega
Hreflang ja kanoonikatägid teenivad erinevaid eesmärke, kuid võivad konfliktidesse sattuda, kui neid ei joondada õigesti. Kanoonikatägid ütlevad Google'ile, milline lehe versioon on põhiversioon, kui leidub duplikaate. Hreflang ütleb Google'ile, millist keele-/piirkonnaversiooni otsingutulemites näidata. Kui teie ingliskeelne leht viitab kanoonikaatributiga iseendale, kuid teie hispaaniakeelne leht viitab kanoonikaatributiga ingliskeelsele lehele, võib Google hreflang-märgendi ignoreerida ega indekseeri hispaaniakeelset versiooni kunagi.
Reegel: igal keele-/piirkonnaversionil peaks olema iseennast viitav kanoonikatäg, mis osutab selle enda URL-ile, mitte mõnele muule keeleversioonile. Seejärel ühendavad teie hreflang-alternatiivtägid keeleversioonid omavahel. Näiteks:
<!-- On https://example.com/page -->
<link rel="canonical" href="https://example.com/page" />
<link rel="alternate" hreflang="en-us" href="https://example.com/page" />
<link rel="alternate" hreflang="es-es" href="https://example.com/es/pagina" />
<!-- On https://example.com/es/pagina -->
<link rel="canonical" href="https://example.com/es/pagina" />
<link rel="alternate" hreflang="en-us" href="https://example.com/page" />
<link rel="alternate" hreflang="es-es" href="https://example.com/es/pagina" />Vastavalt Google’i duplikaat-URL-i dokumentatsioon, kanonilised sildid on hreflang-iga konflikti korral ülimuslikud. Üks e-kaubanduse sait kaotas pärast CMS-i uuendust 30% oma prantsuskeelsest liiklusest, kuna uuendus seadistas kõik rahvusvahelised lehed ingliskeelse versiooni kanoniseerimisele, andes Google'ile sisuliselt korralduse tõlkeid ignoreerida.
Mobiilne esmane indekseerimine lisab veel ühe keerukuse kihi. Google roomab ja indekseerib peamiselt teie saidi mobiiliversiooni. Kui teie mobiili- ja töölaualehtedel on erinevad hreflang-i rakendused – näiteks töölaud kasutab HTML-silte, kuid mobiil jätab need välja – ei pruugi Google teie rahvusvahelist struktuuri ära tunda. 2023. aasta reisibroneerimissaidi juhtumiuuring näitas, et puuduvad hreflang-i sildid mobiilimallides põhjustasid 22% languse rahvusvahelises orgaanilises liikluses, isegi kui töölaua rakendus oli täiuslik.
Lahendus: veenduge, et hreflang ilmub mobiili- ja töölauaversioonides identselt. Responsiivsetel saitidel toimub see automaatselt. Eraldi mobiili-URL-ide puhul (m.example.com) vajate hreflang-i nii töölaua- kui ka mobiiliversioonides, kusjuures hreflang-i siltides olevad mobiili-URL-id peavad viitama teistele mobiiliversioonidele. See kahekordistab teie hreflang-i jalajälge, kuid tagab, et mobiilne esmane indekseerimine toimib korrektselt.
Reaalse maailma rakendamise ajakavad ja kulud
Narratiiv, et hreflang on kiire rakendamine, ei vasta enamiku ettevõtete jaoks tegelikkusele. Saidi puhul, millel on 5 keelt ja 500 lehekülge, arvestage 2–3 nädalat arendusaega HTML- või päisepõhise hreflang-i juurutamiseks, millele lisandub 4–8 nädalat, et Google saaks seda otsingutulemites täielikult töödelda ja rakendada. Saidimapipõhised juurutused võivad olla kiiremini kasutatavad (1–2 nädalat), kuid Google'il kulub nende tuvastamiseks kauem aega (4–6 nädalat) roomamiseelarve piirangute tõttu.
Agentuuride pakkumiste ja vabakutseliste platvormide kulude jaotused näitavad suuri erinevusi. Keskmise suurusega saidi puhul (500–1 000 lehekülge, 3–5 keelt) arvestage järgmisega:
- Arendus: $3 000–$8 000 kohandatud hreflang-i juurutamiseks, olenevalt CMS-i keerukusest
- Kvaliteeditagamine ja testimine: $1 000–$2 000 vastastikkuse valideerimiseks ja kogu saidi auditite läbiviimiseks
- Pidev jälgimine: $500–$1 500/kuus vigade tabamiseks, kui sisu muutub või käivitatakse uusi lehti
Suuremad saidid, kus on 10+ keelt ja dünaamiline sisu, näevad kulude kasvu 15 000–30 000 dollarini esialgse juurutamise eest, kusjuures hoolduseks kulub märkimisväärselt ka edaspidi. Globaalsed SaaS-platvormid integreerivad hreflang'i sageli oma põhiarhitektuuri esimesest päevast alates, et vältida kulukaid ümberehitusi, kuid see nõuab eelnevat planeerimist, mida enamik idufirmasid vahele jätab.
Varjatud kulu: SEO võimaluste kaotus 4–8-nädalase töötlemisperioodi jooksul. Üks fintech-idufirma arvutas, et kaotas ligikaudu 40 000 dollarit potentsiaalsest tulust orgaanilisest liiklusest, kuni Google indekseeris nende rahvusvahelised lehed pärast hreflang'i kasutuselevõttu uuesti. Seda ei ole võimalik vältida – see on roomamise ja töötlemise aeg –, kuid juhtumiuuringutes mainitakse seda harva.
Viidatud peamised allikad
- Hreflang'i juurutusmeetodid ja standardid. Google Search Central, mitmepoolsete ja mitmekeelsete saitide haldamise dokumentatsioon. Google arendajatele
- Hreflang'i vigade levik ja vastastikkuse probleemid. SEMrush, 2024 saidi auditi aruanne (2,3 miljoni domeeni analüüs). SEMrush
- Ettevõtte taseme hreflang-i kasutusmustrid. Merkle digitaalse turunduse aruanne 2024, rahvusvahelise SEO jaotis. Merkle
- CDN-i jõudluse mõju TTFB-le. Cloudflare, servaarvutus ja jõudluse võrdlusandmed. Cloudflare'i õpikeskus
- Tehnilised hreflang-i valideerimistööriistad. DeepCrawl (Lumar), tehniline SEO teek ja auditeerimise võimalused. DeepCrawl
- Kanoonilise sildi käitumine ja konfliktid. Google Search Central, duplikaatsete URL-ide konsolideerimise dokumentatsioon. Google arendajatele
- Mobiilile esmase indekseerimise kaalutlused. Google Webmaster Central blogi, mobiilile esmase indekseerimise parimad tavad. Google arendajatele
- Rahvusvahelise SEO statistika. Ahrefs, 2024. aasta uuring rahvusvahelise SEO vigade kohta 2,3 miljoni domeeni lõikes. Ahrefs
Kas mul on vaja hreflang'i, kui minu saidil on ainult üks keeleversioon?
Kas mul on vaja hreflang'i, kui minu saidil on ainult üks keeleversioon?
Ei. Hreflang rakendub ainult siis, kui teil on sama sisu mitmes keele- või piirkondlikus versioonis. Kui teie sait on ainult ingliskeelne ja alternatiivsed versioonid puuduvad, ei ole hreflang-siltidel mingit otstarvet ning need võib täielikult välja jätta.
Kas ma saan kasutada hreflang'i korraga nii HTML-is kui ka saitemap'ides?
Kas ma saan kasutada hreflang'i korraga nii HTML-is kui ka saitemap'ides?
Jah, kuid need peavad täpselt kattuma. Google soovitab valida ühe meetodi, et vältida vastuolulisi signaale. Kui kasutate mõlemat, veenduge, et iga hreflang-annotatsioon saitemapis kajastub ka HTML-i head-siltides, vastasel juhul võib Google ühe komplekti täielikult ignoreerida.
Kui kaua kulub Google'il hreflang-siltide tuvastamiseks?
Kui kaua kulub Google'il hreflang-siltide tuvastamiseks?
Tavaliselt 2–4 nädalat HTML-/päise rakenduste puhul ja 4–8 nädalat ainult saitemap'i seadistuste puhul. Suured saidid väikese roomamiseelarve korral võivad võtta kauem aega. Tuvastamist saate jälgida Google Search Console’i rahvusvahelise sihtimise aruandes.
Mis juhtub, kui unustan hreflang-siltides x-default?
Mis juhtub, kui unustan hreflang-siltides x-default?
X-default on valikuline, kuid soovitatav. Ilma selleta võib Google'il olla raske valida õiget lehte kasutajatele piirkondades või keeltes, mida te pole otseselt sihtnud. See ei riku teie hreflang-i, kuid vähendab kontrolli varulahendusliku käitumise üle.
Kas peaksin kasutama ainult keele- või keele-ja-piirkonna koode?
Kas peaksin kasutama ainult keele- või keele-ja-piirkonna koode?
Kasutage keele-ja-piirkonna koode (nt en-us, es-mx), kui sisu erineb sama keele piires piirkonniti. Kasutage ainult keelekoode (nt en, es), kui sisu on identne kõigis seda keelt kõnelevates piirkondades. Olge konkreetne, kui piirkondlikud erinevused on olulised valuuta, õigusliku vastavuse või kultuurilise konteksti osas.
Estonian 
English 
Spanish 
French 
Portuguese 
Italian 
German 
Japanese 
Moroccan Arabic 
Czech 
Greek 
Norwegian 
Icelandic 
Romanian