<!-- De pus în <head>-ul paginii https://site.ro/produs-exemplu -->
<link rel="alternate" hreflang="ro" href="https://site.ro/produs-exemplu" />
<link rel="alternate" hreflang="en" href="https://site.com/example-product" />
<link rel="alternate" hreflang="x-default" href="https://site.com/example-product" />
<!-- În mod identic, în <head>-ul paginii https://site.com/example-product -->
<link rel="alternate" hreflang="ro" href="https://site.ro/produs-exemplu" />
<link rel="alternate" hreflang="en" href="https://site.com/example-product" />
<link rel="alternate" hreflang="x-default" href="https://site.com/example-product" />Salutare tuturor. Am văzut recent pe forum câteva discuții despre magazine online care se extind în afară și se trezesc că Google le amestecă paginile în rezultate. Ba apare varianta în română pentru un user din UK, ba invers. Am trecut prin asta acum doi ani la un proiect cu peste 18.000 de URL-uri, unde un setup greșit ne-a costat aproape 25% din traficul organic pe internațional în prima lună de după migrare.
Hreflang-ul pare simplu la prima vedere: pui niște taguri în <head> și gata. În realitate, este probabil cel mai ușor mod de a-ți distruge SEO-ul dacă nu ești atent la detalii.
Regula de aur: Reciprocitatea absolută
Cea mai frecventă greșeală pe care o văd (și pe care am făcut-o și eu în trecut) este lipsa reciprocității. Dacă pagina ta în română (site.ro/produs) trimite către varianta în engleză (site.com/product), atunci și pagina în engleză trebuie să trimită înapoi exact la aceeași pagină în română.
Dacă uiți să pui link-ul de retur, Google pur și simplu ignoră ambele taguri. Zero avertismente în consolă uneori, doar te trezești că paginile nu se indexează corect.
Un alt detaliu crucial este x-default. Acesta îi spune motorului de căutare ce pagină să arate utilizatorilor care nu se potrivesc cu nicio limbă specificată. De obicei, aici pui varianta .com în engleză, ca fallback global.
Head vs. XML Sitemap: Trade-off-ul sincer
Când ai doar 10 pagini de prezentare, le pui direct în HTML-ul fiecărei pagini. Dar ce faci când ai mii de produse?
Dacă pui tagurile în HTML:
- Avantaj: E foarte ușor de inspectat cu
F12direct în browser. - Dezavantaj: Dacă ai 5 limbi/țări, adaugi 5 linii de cod pe fiecare pagină. La 20.000 de pagini, înseamnă kiloocteți buni de date inutile descărcați de fiecare vizitator. Pare puțin, dar la mobil pe o conexiune mai slabă se simte.
Dacă le pui în XML Sitemap:
- Avantaj: HTML-ul rămâne curat, timpul de încărcare al paginii nu este afectat absolut deloc.
- Dezavantaj: Este un coșmar să le generezi corect din backend și mult mai greu de depanat rapid când ceva nu merge.
Pentru proiectul de care vă spuneam, am ales varianta cu XML Sitemap. Ne-a salvat performanța pe mobil, dar ne-a luat vreo trei zile de debug intens să ne asigurăm că scriptul de generare nu dădea rateuri la produsele ieșite din stoc.
Cum verifici că funcționează corect?
Nu te baza pe extensiile simple de Chrome care doar îți arată dacă există tagurile în pagină. Ele nu verifică dacă paginile de destinație returnează cod 200 OK sau dacă există reciprocitatea din cealaltă parte.
- Screaming Frog: Este sfânt pentru asta. Îl pui să ruleze pe ambele domenii, activezi opțiunea de "Hreflang validation" în configurare și îți va arăta exact unde ai pagini lipsă sau erori de tipul "unlinked anchor".
- Google Search Console: Chiar dacă actualizarea datelor durează câteva zile, verifică raportul de International Targeting. Dacă vezi erori cu "no return tags", știi sigur că ai omis reciprocitatea pe undeva.
Voi cum gestionați asta la proiectele mari? Mergeți pe varianta simplă în HTML head sau vă complicați cu sitemap-ul XML pentru a salva acei câțiva milisecunde la încărcare?