Hreflang pe bune între .ro și .com: capcanele clasice și cum verifici implementarea

Am pierdut acum doi ani vreo 40% din traficul organic pe un magazin extins din România (.ro) către Europa (.com) pentru că am tratat hreflang-ul ca pe o simplă formalitate. Googlebot a început să amestece URL-urile în SERP: userii din Iași primeau varianta în engleză cu prețuri în euro, iar românii din diaspora vedeau versiunea în lei fără livrare externă. Dacă ai două domenii separate și vrei să targetezi audiențe diferite, logica din spate e mai sensibilă decât pare.

Regula reciprocității și capcana x-default

Cea mai frecventă greșeală pe care o văd pe forumuri și în audituri e lipsa reciprocității. Hreflang funcționează exclusiv dacă ambele pagini se recunosc reciproc. Dacă pagina de pe domeniu.ro/produs indică spre domeniu.com/en/product, dar varianta de pe .com uită să trimită înapoi spre .ro, Google ignoră complet ambele instrucțiuni.

Fiecare pagină trebuie să aibă:

1. Un tag self-referencing (adica pagina se include și pe ea însăși în lista de alternative).
2. Link direct către versiunea echivalentă de pe celălalt domeniu.
3. Un fallback marcat cu x-default — pagina pe care vrei să o vadă un utilizator care caută din afara regiunilor vizate explicit (de exemplu, un vizitator din Australia).

Nu uita regula de aur a canonical-ului: hreflang trebuie să trimită ÎNTOTDEAUNA către URL-ul canonic. Dacă pui hreflang spre un link care dă 301 sau are canonical spre alt URL, ai aruncat crawl budget-ul pe geam.

În HTML <head> sau în XML Sitemap?

Aici e un trade-off clar de arhitectură. Implementarea direct în <head> e rapidă dacă ai un site mic sau un landing page simplu. O randezi din backend sau din template și aia e.

Problema apare la scară. La un magazin online cu 40k produse și 4 limbi diferite, să adaugi 5-6 taguri hreflang în DOM pe fiecare pagină înseamnă câteva sute de kilograme de HTML inutil transferat zilnic la scară mare. În plus, pe framework-uri moderne de frontend gen Next.js sau Nuxt, riști să ai discrepanțe la hidratare dacă nu ești atent.

Pentru site-uri mari, soluția sănătoasă e mutarea adnotărilor în XML Sitemap. Îți ține codul paginii curat, iar modificările de structură internațională nu cer redeploy de aplicație, ci doar regenerarea sitemap-ului.

Cum verifici înainte să te penalizeze Google

Nu aștepta după Google Search Console. Până când GSC raportează erorile la secțiunea International Targeting (care oricum a fost retrogradată în interfață), pierzi trafic săptămâni la rând.

Cea mai sigură metodă rămâne un crawl local cu Screaming Frog sau un script de Node/Python. În Screaming Frog bifezi la configurare crawl-ul de hreflang și verifici trei rapoarte specifice:

• Missing Return Links (unde ai uitat reciprocitatea)
• Non-canonical hreflang (dacă trimiți la URL-uri cu trailing slash lipsă sau redirecturi)
• Inconsistent language/country codes (ai pus din greșeală en-UK în loc de en-GB)

Un detaliu important: hreflang nu te scapă de problemele de conținut identic. Dacă iei conținutul de pe .ro, îl traduci automat prost pe .com și crezi că hreflang te salvează de filtrul de calitate Google, te înșeli amarnic.

Voi cum gestionați adnotările astea la proiecte mari: le generați dinamic în sitemap prin cron jobs sau le injectați direct în header din framework?