<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
xmlns:xhtml="http://www.w3.org/1999/xhtml">
<url>
<loc>https://example.ro/produs-demo</loc>
<xhtml:link rel="alternate" hreflang="ro-RO" href="https://example.ro/produs-demo" />
<xhtml:link rel="alternate" hreflang="en" href="https://example.com/demo-product" />
<xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/demo-product" />
</url>
<url>
<loc>https://example.com/demo-product</loc>
<xhtml:link rel="alternate" hreflang="ro-RO" href="https://example.ro/produs-demo" />
<xhtml:link rel="alternate" hreflang="en" href="https://example.com/demo-product" />
<xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/demo-product" />
</url>
</urlset>Setarea de hreflang între domenii complet diferite (domain.ro și domain.com) pare simplă până când vezi că Google indexează paginile de engleză pe rezultatele din România. Am trecut prin asta anul trecut la o migrare pentru o platformă cu peste 40k URL-uri și 150k vizite lunare, unde am pierdut inițial ~15% din traficul pe .ro din cauza unor legături bidirecționale ratate. Să le luăm pe rând.
Unde greșește lumea: Canonical vs Hreflang
Cea mai frecventă eroare pe care o văd în audituri este legată de rel="canonical". Mulți devs pun pe site.com/product-a un canonical către site.ro/produs-a, gândindu-se că limba română e sursa primară sau că economisesc crawl budget. E total greșit.
Regula de aur e clară: fiecare pagină dintr-un cluster de hreflang trebuie să aibă canonical self-referencing (către ea însăși).
Dacă pui canonical cross-domain, practic îi spui botului: "ignoră pagina asta pe engleză, folosește-o pe cea din RO". În secunda doi, Google îți anulează complet atributele hreflang pentru varianta .com, iar în Search Console îți apare eroarea Alternate page with proper canonical tag.
Header HTML, XML Sitemap sau HTTP Headers?
Ai trei opțiuni unde să pui legăturile: în <head>, în sitemap-ul XML, sau în HTTP Response Headers.
Pentru proiectul de 40k URL-uri, le-am pus inițial direct în HTML-ul randat de server. A fost o decizie neinspirată. Dimensiunea documentului a crescut cu aproape 8KB pe fiecare pagină doar din taguri (aveam 5 țări vizate), iar caching-ul la nivel de CDN pe Edge a devenit complicat la fiecare modificare de URL.
Trade-off-ul e simplu:
- HTML
<head>e excelent pentru site-uri mici (sub 500-1000 de pagini). E foarte simplu de inspectat din browser cuView Sourceși depanezi rapid. - XML Sitemap este soluția corectă pentru e-commerce sau aplicații mari. Păstrezi HTML-ul curat, reduci TTFB-ul și poți genera sitemaps asincron prin background jobs, fără să încarci timpii de răspuns din SSR.
Coduri ISO și legătura x-default
Trebuie să fii atent la două detalii tehnice care strică liniștit tot setup-ul:
- Codurile de țară/limbă: Formatul este
limba-TARA. Limba e ISO 639-1, iar țara ISO 3166-1 Alpha-2. O greșeală clasică een-ukîn loc deen-gb. Dacă puien-uk, Google o ignoră tăcut, fără eroare explicită în parser. - Tagul
x-default: Arată către versiunea fallback când niciun alt limbaj nu se potrivește. Fără el, pierzi traficul din țări precum Moldova sau utilizatorii din România care au sistemul de operare și browserul setate nativ pe engleză.
Cum verifici corectitudinea
Nu aștepta după Google Search Console. Raportul de International Targeting poate avea întârzieri de până la două-trei săptămâni.
Eu folosesc Screaming Frog configurat pe crawl cross-domain. Activez opțiunea Extract Hreflang și pun ambele domenii în scope. Instrumentul verifică automat dacă există legătura reciprocă (return tag). Dacă .ro indică spre .com, dar .com uită să indice înapoi spre .ro, Google va ignora conexiunea pentru că nu poate confirma că ambele domenii sunt controlate de aceeași entitate.
Voi cum gestionați hreflang-ul: îl generați direct din CMS în HTML sau preferați un pipeline separat pentru XML Sitemaps?