<url>
<loc>https://www.example.ro/</loc>
<xhtml:link
rel="alternate"
hreflang="ro-ro"
href="https://www.example.ro/" />
<xhtml:link
rel="alternate"
hreflang="en-gb"
href="https://www.example.com/" />
<xhtml:link
rel="alternate"
hreflang="x-default"
href="https://www.example.com/" />
</url>Am avut recent un caz la un client cu două domenii separate: un .ro pentru piața locală și un .com în engleză pentru restul lumii. Google îi tot încurca paginile, afișând versiunea de .ro utilizatorilor din UK, ceea ce ne mânca cam 15% din rata de conversie fiindcă oamenii ajungeau pe o pagină cu moneda greșită și limbă necunoscută. Problema? O implementare de hreflang făcută pe genunchi, care mai mult inducea în eroare crawlerii decât să-i ajute.
Nu e suficient să arunci un tag în <head> și să speri la ce e mai bun. Hreflang-ul este unul dintre cele mai sensibile mecanisme de SEO tehnic pentru că necesită o precizie chirurgicală. Dacă ai greșit o virgulă sau un cod de țară, Google ignoră tot setul de instrucțiuni.
Regula de aur: Reciprocitatea totală
Cea mai mare greșeală pe care am văzut-o la proiecte de peste 10k pagini este lipsa reciprocității. Dacă pagina ta în română (site.ro/produs) trimite către versiunea în engleză (site.com/product), atunci neapărat și pagina din engleză trebuie să trimită înapoi către cea din română.
E ca un handshake între servere. Dacă A zice că e prieten cu B, dar B nu recunoaște relația, Google zice „pas” și decide el singur care pagină e mai relevantă. De cele mai multe ori, decide prost. Am pățit să văd pagini de staging indexate în locul celor de producție doar pentru că legăturile hreflang erau rupte sau pointau către URL-uri cu 404.
Unde le pui? Head vs. Sitemap
Pentru site-uri mici, e ok să le pui în HTML. Dar la un magazin online cu 50.000 de produse, dacă bagi câte 5-10 taguri de hreflang în <head>, crești dimensiunea documentului inutil. La un proiect de anul trecut, am economisit cam 30% la timpul de descărcare al HTML-ului (Time to First Byte a rămas la fel, dar render-ul s-a îmbunătățit) mutând totul în Sitemap-ul XML.
Trade-off-ul e simplu: în HTML e mai ușor de debuguit cu „View Source”, dar în Sitemap e mult mai scalabil și nu poluezi codul frontend-ului. Totuși, dacă alegi calea Sitemap-ului, asigură-te că scriptul care îl generează e bulletproof. O singură eroare în script și ai scos tot site-ul din indexarea corectă pe regiuni.
Codurile ISO și x-default
M-am prins târziu că mulți folosesc en-UK în loc de en-GB. Google e foarte strict aici: codul de limbă trebuie să fie în format ISO 639-1, iar cel de regiune ISO 3166-1 alpha-2.
Și nu uita de x-default. Acesta e „plasa de siguranță”. Dacă un user te vizitează din Brazilia și tu ai doar .ro și .com (în engleză), unde îl trimiți? Fără x-default, Google va ghici. Eu îl setez mereu pe versiunea globală (.com), ca să fiu sigur că orice user care nu se potrivește pe segmentele mele specifice primește măcar o limbă de circulație internațională.
Cum verifici dacă ai făcut treabă bună
Nu te baza pe „pare ok”. Folosesc de ani de zile Screaming Frog pentru audituri de genul ăsta. Are o secțiune dedicată de Hreflang unde îți arată imediat „Unlinked Lead Hints” sau „Missing Reciprocal Hyperlinks”.
O altă metodă e verificarea în Google Search Console, deși raportul de „International Targeting” a fost mutat și e tot mai greu de găsit prin noile interfețe. Dacă după 2 săptămâni de la implementare încă vezi în GSC că ai „No return tags”, înseamnă că ai dat-o în bară cu reciprocitatea.
În final, hreflang-ul e despre control. Îi spui tu lui Google ce să facă, în loc să-l lași pe el să ghicească intenția utilizatorului tău.
Voi cum gestionați sitemap-urile mari cu hreflang, le generați on-the-fly sau aveți un job programat noaptea?