eduardweb.
SEO & PerformanceIntermediar#seo#web-dev#hreflang#multi-language

Hreflang pentru site-uri multi-country (.ro + .com): Cum îl setezi corect fără să pierzi trafic

De Alexandru Matei, 13 iul. 2026 · 13 vizualizări · 3 like-uri

Postat 13 iul. 2026
html
<!-- De pus în secțiunea <head> pe ambele domenii, atât pe .ro cât și pe .com -->
<link rel="alternate" hreflang="ro-RO" href="https://example.ro/pagina-produs" />
<link rel="alternate" hreflang="en" href="https://example.com/product-page" />
<link rel="alternate" hreflang="x-default" href="https://example.com/product-page" />

Hreflang-ul pare genul ăla de chestie pe care o configurezi în 5 minute și uiți de ea. Am pățit-o însă la un proiect cu peste 15.000 de produse, unde Google începuse să trimită românii pe varianta .com în engleză, iar traficul organic pe .ro scăzuse cu 35% într-o singură lună din cauza canibalizării.

Dacă ai un setup multi-country (de exemplu .ro pentru România și .com ca site global în engleză), maparea corectă îți salvează business-ul de la un dezastru SEO destul de greu de remediat ulterior.

Codul de țară vs. Codul de limbă: Unde greșește toată lumea

Cea mai frecventă greșeală pe care o văd în audituri este confuzia dintre limbă și regiune. Hreflang folosește formatul limbă-regiune (ISO 639-1 pentru limbă și ISO 3166-1 alpha-2 pentru regiune).

Dacă scrii doar hreflang="en", îi spui lui Google că pagina e pentru toți vorbitorii de engleză. Dacă pui hreflang="ro-RO", e specific pentru vorbitorii de română din România.

De ce e crucial x-default?

Tagul x-default este plasa ta de siguranță. El îi spune motorului de căutare: „Dacă utilizatorul e din Spania sau Brazilia și eu nu am o pagină dedicată în spaniolă sau portugheză, trimite-l pe pagina asta globală”. De regulă, varianta .com în engleză este cea mai bună alegere pentru x-default.

Fără el, Google va încerca să ghicească și s-ar putea să trimită un utilizator din Italia pe varianta .ro doar pentru că are o latență mai mică la server în acel moment. Am văzut cazul ăsta live și e extrem de frustrant de debugat pentru că debugul în consolă nu-ți arată nicio eroare de sintaxă.

Trade-off sincer: Head tags vs. XML Sitemap

Ai două metode principale de implementare, fiecare cu bubele ei specifice.

1. În HTML Header (direct în pagină)

  • Avantaj: E foarte ușor de implementat direct din template-ul de pagină (Blade, React, Liquid etc.) și poți verifica vizual rapid în codul sursă.
  • Dezavantaj: Mărește dimensiunea paginii. Dacă ai un site tradus în 15 limbi, adaugi aproape 2KB de markup inutil în head-ul fiecărei pagini. La conexiuni mobile slabe în zone rurale, fiecare KB contează la încărcare.

2. În XML Sitemap

  • Avantaj: Păstrează codul HTML curat și salvează lățime de bandă.
  • Dezavantaj: E mult mai greu de debugat vizual. Dacă generatorul tău de sitemap are un bug și ratează legăturile bidirecționale, Google va ignora complet tagurile fără să îți dea o eroare evidentă în primele zile.

Cum verifici că totul e în regulă?

Google are o regulă de fier: reciprocitatea. Dacă pagina A trimite către pagina B cu hreflang pentru engleză, pagina B trebuie să trimită înapoi către pagina A cu hreflang pentru română. Dacă legătura nu e bidirecțională, Google ignoră ambele taguri și ai muncit degeaba.

Pentru verificare rapidă, nu te baza doar pe ochiul liber:

  • Folosește un crawler local (Screaming Frog e excelent pentru asta, are secțiune dedicată de Hreflang în tab-ul de configurare).
  • Verifică raportul de „Targeting Internațional” în Google Search Console. Chiar dacă are un lag de 2-3 zile, îți arată exact erorile de reciprocitate nerezolvate.
  • Rulează un test rapid în consolă cu un tool online gen Merkle SEO Hreflang Tool ca să vezi maparea în timp real pe un URL specific.

Voi cum gestionați internaționalizarea pe proiectele mari? Preferați să încărcați head-ul din CMS sau generați totul dinamic în sitemap-ul XML?

Răspunsuri 0

Se încarcă răspunsurile…

Loghează-te pentru a răspunde

Doar membrii comunității pot lăsa comentarii.