Cos’è l’hreflang e perché conta in una strategia multilingua
hreflang è un’annotazione che indica ai motori di ricerca la versione linguistica o geografica più adatta di una pagina. Serve a mostrare all’utente il contenuto giusto in base a lingua e area (es. italiano Italia vs italiano Svizzera), riducendo problemi di contenuti quasi duplicati e migliorando copertura e CTR nelle SERP internazionali.
Funziona per siti multilingua (stessa area, lingue diverse) e per siti multiregionali (stessa lingua, aree diverse). È utile anche per brand con prezzi, valute o normative che variano per Paese.
Principio chiave: cluster di equivalenza e reciprocità
L’hreflang non “traduce” la pagina: collega tra loro versioni equivalenti della stessa risorsa. Ogni URL in un cluster deve rimandare a tutte le altre (reciprocità) ed essere auto-referenziale (includere anche sé stesso). Se una pagina non è indicizzabile, non dovrebbe stare nel cluster.
Quando applicarlo e quando evitarlo
Applicalo quando hai versioni dello stesso contenuto per lingue/aree diverse (es. /it/, /en-gb/, /fr-ch/). Evitalo se le pagine non sono equivalenti (contenuti o intenti diversi), se sono noindex, se cambiano spesso URL o se non puoi garantire reciprocità costante.
Codici lingua e area: la sintassi corretta
La sintassi segue lo standard BCP 47: lingua (ISO 639-1) + opzionale -REGIONE (ISO 3166-1 alpha-2). Esempi corretti: it, it-IT, en, en-GB, fr-CH. Evita codici non standard (es. en-UK è errato: usa en-GB).
x-default indica la versione “fallback” quando non c’è corrispondenza diretta (es. una pagina selettore lingua o una versione globale).
Dove inserire l’hreflang: HTML, header o sitemap
Hai tre modalità equivalenti. Scegline una e mantienila coerente in tutto il sito.
1) Tag HTML nel <head>
Inserisci link alternates in ogni pagina del cluster:
<link rel="alternate" hreflang="it-IT" href="https://www.esempio.com/it/pagina/" />
<link rel="alternate" hreflang="en-GB" href="https://www.esempio.com/uk/page/" />
<link rel="alternate" hreflang="fr-CH" href="https://www.esempio.com/ch-fr/page/" />
<link rel="alternate" hreflang="x-default" href="https://www.esempio.com/global/page/" />Pro: semplice da leggere. Contro: più pesante da mantenere se il sito è ampio, e non dovrebbe essere iniettato tardi via JS (rischio che il crawler non lo veda in tempo).
2) Header HTTP
Utile per file non HTML (PDF, ecc.) o dove non puoi toccare il DOM:
Link: <https://www.esempio.com/it/pagina/>; rel="alternate"; hreflang="it-IT",
<https://www.esempio.com/uk/page/>; rel="alternate"; hreflang="en-GB",
<https://www.esempio.com/global/page/>; rel="alternate"; hreflang="x-default"3) Sitemap XML con xhtml:link
Scalabile per siti grandi o multi-country su più domini:
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
xmlns:xhtml="http://www.w3.org/1999/xhtml">
<url>
<loc>https://www.esempio.com/it/pagina/</loc>
<xhtml:link rel="alternate" hreflang="it-IT" href="https://www.esempio.com/it/pagina/" />
<xhtml:link rel="alternate" hreflang="en-GB" href="https://www.esempio.com/uk/page/" />
<xhtml:link rel="alternate" hreflang="x-default" href="https://www.esempio.com/global/page/" />
</url>
</urlset>Pro: gestione centralizzata, minore peso sull’HTML. Contro: serve pipeline di generazione affidabile e monitoraggio degli errori.
Architetture internazionali: ccTLD, sottodomini o sottocartelle
ccTLD (es. esempio.fr): chiaro segnale geografico, gestione separata; costoso e richiede link building per ogni dominio.
Sottodomini (es. fr.esempio.com): discreta separazione; attenzione a DNS, CDN, metriche e duplicazioni.
Sottocartelle (es. esempio.com/fr/): implementazione più semplice, concentrazione dei segnali; richiede governance chiara di template e contenuti.
Qualunque scelta tu faccia, l’hreflang collega gli URL equivalenti cross-dominio o cross-path, purché siano indicizzabili e reciprocamente riferiti.
Allineare hreflang, canonical e indicizzabilità
Canonical e hreflang devono collaborare. Ogni pagina dovrebbe avere canonical verso sé stessa (auto-referenziale) se è la versione preferita per quella lingua/area. Evita canonical incrociati tra lingue: confondono i segnali.
Non inserire nel cluster pagine noindex, con Disallow nel robots.txt o con status non 200. Gli URL devono essere canonici e 200, presenti in sitemap pulite e collegati dall’interlinking.
x-default: quando e come usarlo
Usa x-default per una pagina “globale” o per uno store locator/selettore lingua. x-default deve essere presente nel cluster ed essere reciproco come le altre versioni.
JavaScript e rendering: non perdere i segnali
Se il sito è client-side rendered, i tag nel <head> non devono essere iniettati in ritardo. Preferisci SSR/SSG o inserisci gli alternates in HTML “primo paint”. Evita che script o A/B test modifichino gli href degli alternates.
eCommerce e multi-regione: managing quasi duplicati
Nello stesso idioma (es. it-IT vs it-CH) cambia prezzi, valute, disponibilità, normative. Per evitare duplicazioni:
1) mostra differenze reali e utili per l’area (valuta, spedizione, resi); 2) usa hreflang per collegare le versioni; 3) mantieni canonical auto-referenziale; 4) evita reindirizzamenti automatici aggressivi basati su IP (consenti lo switch volontario).
Localizzazione reale oltre la traduzione
Localizza UI, formati di data/ora, misure, metodi di pagamento, esempi e referenze. Le pagine saranno più utili e differenziate, con benefici su ranking e conversioni. Integra FAQ locali e contatti corretti per assistenza.
Paginazioni, parametri e filtri
Non inserire nel cluster pagine filtrate o parametriche se non rappresentano equivalenti reali in tutte le lingue/aree. Mantieni l’hreflang su versioni “pulite” e canoniche. Paginazioni: l’hreflang va su ogni pagina della serie, mappando l’equivalente nella serie estera.
Gestione su CMS ed ecosistemi reali
Qualunque sia il CMS (WordPress, Shopify, headless), assicurati che l’output rispetti: 1) head statico con alternates; 2) canonical pulito; 3) URL coerenti; 4) sitemap con xhtml:link aggiornati. In contesti enterprise, centralizza la generazione dell’hreflang nella pipeline di build/deploy per ridurre errori manuali.
Verifica e monitoraggio
Controlla campioni di URL a ogni rilascio. Usa l’Ispezione URL in Search Console per verificare che Google legga gli alternates. Monitora crescita del CTR per Paese/Lingua in Search Console e conversioni per area in GA4. Tieni uno storico degli errori corretti (es. mismatch di lingua/paese, href rotti, http vs https misti).
Esempi di mapping reale: tre scenari
Scenario A: sito multilingua su un solo mercato
Un’università in Italia offre pagine in italiano e inglese per lo stesso corso. Usa it e en senza regione, canonical auto-referenziali, alternates reciproci e x-default verso la pagina di selezione lingua.
Scenario B: eCommerce con siti per Paese
ccTLD .it, .fr, .de. Ogni scheda prodotto include: prezzo locale, imposte, resi. Hreflang cross-domain collega le versioni. Sitemap per dominio con xhtml:link e job notturno di validazione dei cluster.
Scenario C: blog corporate con contenuti adattati
Stesso tema, esempi e call differenziati per area (normative, strumenti, vocabolario). Anche se i testi divergeno leggermente, il topic e l’intento restano equivalenti: l’hreflang resta valido e aiuta a servire la versione più utile.
Checklist operativa per l’hreflang (da salvare)
- Definisci lingue/aree e struttura URL (ccTLD, subdomain, subfolder) in modo stabile.
- Per ogni pagina, crea il cluster di equivalenti e garantisci reciprocità + auto-referenza.
- Scegli un’unica modalità (HTML, header o sitemap) e applicala in modo coerente.
- Usa codici BCP 47 validi (es. it-IT, en-GB, fr-CH) e, se serve,
x-default. - Canonical auto-referenziale su ogni versione; evita canonical incrociati tra lingue.
- Non includere nel cluster URL non 200, noindex o bloccati dal robots.txt.
- Allinea l’hreflang con sitemap XML pulite e interlinking coerente.
- Evita iniezioni JS tardive degli alternates; preferisci SSR/SSG.
- Testa campioni in Search Console e monitora CTR per Paese/Lingua.
- Documenta regole e responsabilità (chi aggiorna, quando, come validare) per ridurre errori.
Errori da evitare con l’hreflang
- Codici non standard (es. en-UK) o mancata distinzione tra lingua e area quando necessario.
- Assenza di reciprocità: un URL punta alle varianti, ma non riceve link hreflang di ritorno.
- Mischiare http/https e versioni con/ senza slash finale nello stesso cluster.
- Inserire pagine
noindex, 3xx/4xx/5xx o bloccate nel cluster. - Canonical incrociati tra lingue: disperdono segnali e confondono la versione preferita.
- Iniettare i tag via JS a caricamento concluso o dopo un A/B test che cambia gli href.
- Hreflang su URL filtrati/parametrici senza equivalenti nelle altre versioni.
- Mancanza di
x-defaultquando esiste una pagina “selettore lingua”.
Domande frequenti sull’hreflang
Devo usare sempre lingua + area o basta la lingua?
Se la stessa lingua ha contenuti, prezzi o leggi differenti per Paese, usa anche l’area (es. it-IT vs it-CH). Se il contenuto è identico e l’area non cambia l’esperienza, può bastare la sola lingua.
Posso mescolare hreflang in HTML e in sitemap?
Meglio evitare miscele. Scegli una modalità e applicala ovunque. Se devi passare da HTML a sitemap (o viceversa), gestisci la transizione con una finestra di sovrapposizione breve e coerente.
Cosa succede se una variante va offline o diventa noindex?
Rimuovila dal cluster su tutte le versioni per non generare riferimenti rotti o a pagine non indicizzabili. Ripristina l’hreflang solo quando la pagina torna 200 e indicizzabile.
A cosa serve l’attributo x-default?
Indica la destinazione predefinita per utenti non coperti dalle varianti specifiche. Tipico per selettori lingua o versioni globali. Deve essere reciproco come le altre entry.
L’hreflang migliora il posizionamento?
Non è un “boost” diretto di ranking. Aiuta a mostrare la versione giusta al pubblico giusto, migliorando pertinenza e CTR. Indirettamente, riduce conflitti tra duplicati internazionali e migliora l’esperienza.
