L’hreflang è un attributo dell’elemento link che dichiara ai motori di ricerca quale versione linguistica o geografica di una pagina mostrare a un determinato utente.
La cosa utile da sapere prima di toccare il codice: non fa salire nulla in classifica. A parità di posizionamento scambia l’URL mostrato in SERP con quello giusto per la lingua e il paese di chi ha cercato. Se il problema è «il mio sito non si posiziona in Germania», l’hreflang non lo risolve. Se è «gli utenti tedeschi atterrano sulla pagina italiana», allora sì.
Quando serve, e a quante aziende italiane serve davvero
La documentazione di Google Search Central elenca tre casi: contenuto tradotto per intero in più lingue; stessa lingua con varianti locali minime, come prezzi, valuta e condizioni di spedizione; template tradotto e contenuto principale in una lingua sola, che è la situazione dei forum e delle pagine con contenuti generati dagli utenti.
Fuori da questi tre casi l’attributo non porta niente. Su un sito monolingua rivolto a un solo mercato aggiunge righe da tenere aggiornate e basta. Va anche chiarito il perimetro sui contenuti duplicati: Google considera duplicate le versioni localizzate solo quando il contenuto principale resta non tradotto, cioè nel caso tipico del sito in inglese per Stati Uniti, Regno Unito e Australia dove cambiano soltanto valuta e dettagli commerciali.
Quanti siti italiani rientrano nel perimetro? Secondo il report Imprese e Ict dell’Istat, nel 2025 ha effettuato vendite online il 14,7% delle imprese italiane con almeno 10 addetti, con punte del 34,6% in alloggio e ristorazione e del 19,1% nel commercio. Il sottoinsieme che vende anche fuori dai confini è più piccolo ancora. È lì che l’hreflang ha senso, in progetti di SEO internazionale veri, o nella SEO per l’industria manifatturiera quando lo stesso catalogo va servito a buyer di paesi diversi.
La sintassi: due codici, nessuna invenzione
L’annotazione base sta nella sezione head e ha questa forma:
<link rel="alternate" hreflang="it" href="https://www.example.com/it/" />
<link rel="alternate" hreflang="en-GB" href="https://www.example.com/uk/" />
<link rel="alternate" hreflang="x-default" href="https://www.example.com/" />Il valore è composto da un codice lingua obbligatorio in formato ISO 639-1 e da un codice regione facoltativo in formato ISO 3166-1 Alpha 2. Google accetta solo codici presenti in quelle due liste. La coppia non deve rispecchiare la lingua ufficiale del paese: de-BE, tedesco per il Belgio, è valido.
| Valore | Valido | Perché |
|---|---|---|
it | Sì | Codice lingua ISO 639-1, italiano a prescindere dalla regione |
it-CH | Sì | Italiano per gli utenti in Svizzera |
de-BE | Sì | Tedesco per il Belgio: la lingua non deve essere quella ufficiale del paese |
zh-Hant | Sì | Sistema di scrittura in formato ISO 15924 (cinese tradizionale) |
x-default | Sì | Valore riservato per le lingue senza corrispondenza |
IT | No | La sola regione non è mai un valore valido, serve il codice lingua |
en-UK | No | UK non è un codice assegnato in ISO 3166-1 Alpha 2, il Regno Unito è GB |
en-EU | No | EU e UN sono riservati e non hanno effetto sulla Ricerca Google |
es-419 | No | Codice non presente in ISO 3166-1 Alpha 2, l’America Latina non è targettizzabile |
Una precisazione che elimina metà dei dubbi: Google non usa l’hreflang, e nemmeno l’attributo HTML lang, per capire in che lingua è scritta una pagina. La lingua la determina dal contenuto con i suoi algoritmi. Dichiarare hreflang="de" su una pagina scritta in inglese non la farà comparire nelle ricerche in tedesco, la renderà solo incoerente.
Le tre condizioni che rendono valido un cluster
Un insieme di pagine collegate da hreflang funziona solo se è chiuso e coerente. Le condizioni sono tre e valgono tutte insieme.
- Link di ritorno. Se la pagina A dichiara B, B deve dichiarare A. Il meccanismo esiste per impedire a un dominio qualsiasi di nominarsi versione alternativa di un sito che non controlla. Senza conferma di ritorno le annotazioni vengono ignorate o interpretate male.
- Autoreferenzialità. Ogni pagina elenca anche sé stessa. Il blocco di annotazioni è identico su tutte le versioni del cluster, ed è questa identità a renderlo verificabile.
- URL assoluti e indicizzabili.
https://example.com/it/va bene,/it/no. E l’URL dichiarato deve rispondere 200, essere canonico e non avere il noindex.
Le varianti non devono stare sullo stesso dominio. Un cluster che collega example.it, example.de ed example.fr è valido quanto uno costruito su sottocartelle, quindi la scelta dell’architettura resta indipendente dall’hreflang.
Tre metodi di implementazione, e conviene sceglierne uno
Google ne supporta tre e li considera equivalenti: i tag link nell’head, le intestazioni HTTP e la sitemap XML.
- I tag nell’head sono il metodo più diffuso e il più facile da ispezionare. Su un sito con dieci lingue diventano decine di righe su ogni pagina, e ogni lingua nuova obbliga ad aggiornare tutte le versioni esistenti.
- Le intestazioni HTTP servono per i file non HTML, i PDF in primo luogo, dove un
headnon c’è. - La sitemap XML centralizza le annotazioni in un punto solo e si presta alla generazione automatica. In cambio gli errori non si vedono ispezionando la pagina.
Usarli insieme non porta vantaggi. La documentazione lo scrive per esteso: gestire tre implementazioni invece di una è solo più difficile.
x-default fa anche una cosa di cui non si parla
Il valore riservato x-default indica la pagina da mostrare quando nessuna variante corrisponde alle impostazioni dell’utente. Di solito punta a una pagina di selezione lingua o alla versione internazionale, e non richiede alcun codice lingua.
L’8 maggio 2023 Gary Illyes ha aggiunto sul blog di Google Search Central un dettaglio che in giro si legge poco: gli URL dichiarati nelle annotazioni hreflang, x-default compreso, possono essere usati da Google per l’individuazione di nuovi URL e quindi pianificati per la scansione. Su un sito internazionale grande, dove è difficile garantire che ogni pagina localizzata sia collegata bene internamente, il cluster diventa anche un canale di scoperta.
Dove si rompe davvero, con i numeri
Patrick Stox di Ahrefs ha analizzato 374.756 domini che usano hreflang: il 67% ha almeno un problema. È un campione globale, non italiano, ma la distribuzione degli errori è istruttiva perché non corrisponde a quella dei consigli in circolazione.
| Problema rilevato | Domini interessati |
|---|---|
| Pagine senza x-default | 56,3% |
| Tag autoreferenziale mancante | 18% |
| Annotazioni verso URL in redirect o non raggiungibili | 16,9% |
| Link di ritorno mancante | 15,3% |
| Annotazioni verso URL non canonici | 8% |
| Valori hreflang errati | 4,6% |
| Attributo lang incoerente con l’annotazione | 3,2% |
Il dato meno intuitivo è il primo. L’x-default manca su più della metà dei domini e formalmente non è obbligatorio; dopo il chiarimento di Illyes sull’individuazione degli URL, però, ometterlo costa qualcosa in più di una rete di sicurezza mancata.
Gli altri sono quasi tutti errori di manutenzione, non di prima implementazione: annotazioni verso URL spostati o cancellati, link di ritorno rimasti indietro dopo l’aggiunta di una lingua. Un cluster si rompe quando qualcuno imposta un redirect 301 o cambia uno slug, e si rompe in silenzio.
Il conflitto con il canonical
Hreflang e rel=”canonical” lavorano su piani diversi e vanno usati insieme, con una sola regola operativa: ogni pagina del cluster deve avere un canonical che punta a sé stessa.
L’errore che manda all’aria l’intera implementazione è impostare su tutte le versioni linguistiche un canonical verso la versione principale, di solito quella inglese. Così si chiede a Google di deindicizzare le versioni locali mentre l’hreflang gli dice che devono restare tutte in indice. I due segnali si contraddicono e in genere a perdere è l’hreflang. Vanno inoltre in due tag separati: rel="canonical, alternate" nella stessa riga non è sintassi valida.
C’è un dettaglio storico che spiega perché tante configurazioni vecchie sono fatte male. Nel post del 5 dicembre 2011 con cui Christopher Semturs annunciava rel="alternate" hreflang, Google suggeriva di affiancare il canonical fra pagine quasi identiche destinate a paesi diversi. Quella riga oggi porta un aggiornamento in calce: per semplificare l’implementazione, Google non consiglia più di usare rel="canonical" in quel modo. Chi ha ereditato un sito internazionale di qualche anno fa dovrebbe controllare proprio quel punto.
Come si verifica, ora che Search Console non lo segnala più
Il report Targeting internazionale di Search Console, che elencava gli errori hreflang rilevati sul sito, è stato ritirato. La pagina di assistenza di Google dice due cose insieme: il report non c’è più e i tag hreflang restano supportati e usati. Il monitoraggio è quindi passato per intero agli strumenti esterni.
Per una singola pagina pubblicata la documentazione di Google cita due strumenti di terze parti: il tool di test di Merkle e il generatore di tag di Aleyda Solis. Per il controllo a livello di sito serve un crawler: Screaming Frog ha un report hreflang dedicato che intercetta link di ritorno mancanti, URL che non rispondono 200 e codici non validi, e controlli analoghi stanno nei site audit di Ahrefs e Semrush.
Su WordPress la generazione è quasi sempre in mano al plugin multilingua, WPML o Polylang, che costruiscono le annotazioni dalle relazioni fra traduzioni impostate nel CMS. Il che sposta l’oggetto del controllo: non si verifica il codice scritto a mano, si verifica che ogni traduzione sia collegata alla sua versione originale nel back office. Una pagina tradotta ma non associata esce dal cluster e nessuno se ne accorge guardando il sito.
Qui sta la ragione per cui l’hreflang merita un controllo ricorrente e non una configurazione chiusa una volta sola. È uno dei pochi interventi di SEO tecnica che degradano senza lasciare tracce: non genera un errore in Search Console, non produce un errore 404, non abbassa un punteggio. Un giorno gli utenti francesi ricominciano ad atterrare sulla versione inglese e nessuno collega la cosa al rilascio di tre settimane prima. Se stai aprendo un sito su più mercati, il momento di guardarlo è prima che succeda: il nostro lavoro sulla SEO parte spesso da un crawl di questo tipo.
Domande frequenti sull’hreflang
No. Non fa posizionare meglio una pagina: a parità di posizionamento sostituisce l'URL mostrato in SERP con quello giusto per lingua e paese dell'utente. Nel post con cui lo ha annunciato nel dicembre 2011, però, Google scriveva che uno degli obiettivi era consolidare i segnali fra le pagine dichiarate come varianti dello stesso contenuto.
No. Ha senso solo se esistono più versioni linguistiche dello stesso contenuto, oppure più versioni nella stessa lingua rivolte a paesi diversi. Su un sito monolingua rivolto a un solo mercato aggiunge manutenzione senza alcun beneficio.
Sì, a una condizione: il canonical di ogni pagina del cluster deve puntare a sé stessa. Un canonical che dalla versione italiana punta a quella inglese contraddice l'hreflang e in genere lo rende inefficace. I due attributi vanno inoltre in due tag link separati, mai combinati nella stessa riga.
No, ma Google lo consiglia come pagina di riserva per gli utenti la cui lingua non corrisponde a nessuna versione dichiarata. Manca sul 56,3% dei domini analizzati da Ahrefs ed è anche l'annotazione che Google può usare per scoprire nuovi URL da scansionare.
Perché UK non è un codice assegnato nello standard ISO 3166-1 Alpha 2: il codice del Regno Unito è GB, quindi il valore corretto è en-GB. Google indica EU, UN e UK come valori riservati ad altro, che non hanno alcun effetto sulla Ricerca.
