Il tag hreflang è un attributo HTML che segnala ai motori di ricerca la lingua e, facoltativamente, il paese di destinazione di ciascuna versione di una pagina. Viene inserito nell’head del documento, in una sitemap XML o nell’HTTP header per comunicare a Google quale URL servire all’utente in base alla sua lingua e alla sua posizione geografica. La sua rilevanza cresce con la complessità del sito: viene analizzato durante gli audit di SEO internazionale, nei controlli di Google Search Console e ogni volta che le versioni localizzate di un sito non ricevono traffico dalla regione attesa.
Cos’è il tag hreflang e in quali casi si usa
Il tag hreflang appartiene all’insieme delle annotazioni di localizzazione usate nella SEO internazionale. Risponde a un problema preciso: quando un sito pubblica la stessa pagina in più lingue o per più paesi, Google ha bisogno di un segnale esplicito per capire quale versione mostrare a ciascun utente. L’attributo hreflang fornisce questo segnale in modo diretto e verificabile, indipendentemente dalla struttura degli URL adottata.
Definizione del tag hreflang
Il tag hreflang è un’annotazione rel=”alternate” che specifica la relazione tra versioni alternative della stessa pagina. Ogni elemento link include due informazioni: il valore dell’attributo hreflang, che identifica la lingua e il paese di destinazione, e il valore dell’attributo href, che punta all’URL corrispondente. Google legge l’insieme di queste annotazioni per costruire un cluster di pagine equivalenti e decidere quale mostrare in risposta a una query in funzione delle preferenze linguistiche e geografiche dell’utente.
L’attributo non garantisce il reindirizzamento automatico dell’utente alla versione localizzata: Google può ignorarlo se altri segnali sulla pagina sono contraddittori. Il suo scopo principale è aiutare il motore a selezionare il risultato corretto nella pagina dei risultati, non controllare il comportamento di navigazione dell’utente una volta arrivato sul sito.
Differenza tra sito multilingua e sito multiregione
Un sito multilingua pubblica contenuti in lingue diverse: italiano, inglese, tedesco, spagnolo. In questo caso l’hreflang specifica solo il codice lingua senza il codice paese, ad esempio hreflang=”it” o hreflang=”en”. L’annotazione dice a Google che quella pagina è destinata agli utenti che leggono in quella lingua, ovunque si trovino nel mondo.
Un sito multiregione pubblica varianti della stessa lingua per paesi diversi: inglese per il Regno Unito, inglese per gli Stati Uniti, inglese per l’Australia. In questo caso l’hreflang combina lingua e paese, ad esempio hreflang=”en-GB” o hreflang=”en-US”. I due approcci possono coesistere: un sito può avere sia pagine multilingua sia versioni regionali per alcuni mercati specifici, con annotazioni diverse per ciascuna combinazione.
Casi in cui l’annotazione hreflang è necessaria
L’hreflang serve quando esistono versioni diverse della stessa pagina destinate a utenti con lingua o paese diversi, e quando queste versioni hanno URL distinte. Se il sito pubblica la stessa pagina in italiano su /it/ e in inglese su /en/, Google ha bisogno dell’annotazione per non trattarle come contenuti duplicati e per servirle correttamente agli utenti nei rispettivi mercati.
L’annotazione non serve se il sito è in una sola lingua e non ha versioni localizzate, né se le varianti linguistiche sono gestite da parametri URL senza pagine separate indicizzabili. Nei casi in cui il contenuto cambia solo per piccole differenze regionali (come il simbolo della valuta o il formato della data) senza una traduzione reale, è preferibile valutare se la differenziazione giustifica la complessità di un cluster hreflang.
Effetti su SEO internazionale, UX e contenuti duplicati
Senza hreflang, Google potrebbe indicizzare solo una delle versioni linguistiche del sito o mostrare la versione sbagliata agli utenti. Un utente tedesco che trova in Google la pagina in italiano, pur esistendo una versione in tedesco, ha un’esperienza peggiore e con maggiore probabilità abbandona subito il sito. L’hreflang riduce questo rischio indirizzando il motore di ricerca verso la versione appropriata per ciascun segmento di utenti.
Sul fronte dei contenuti duplicati, le pagine che condividono lo stesso testo in lingue molto simili o che hanno porzioni di layout identiche possono essere percepite come duplicate. Il cluster hreflang segnala a Google che si tratta di versioni equivalenti e non di duplicazione non intenzionale, proteggendo il posizionamento di ciascuna versione nel mercato di riferimento.
Come funziona il tag hreflang
Il meccanismo dell’hreflang si basa su un sistema di annotazioni reciproche: ogni pagina del cluster deve dichiarare le proprie relazioni con tutte le altre versioni, inclusa se stessa. Google costruisce il cluster leggendo queste annotazioni e le usa al momento della query per selezionare l’URL più adatto all’utente. La coerenza interna del cluster è il requisito tecnico più importante: un’annotazione mancante o errata può rendere il cluster inutilizzabile.
Sintassi del markup rel alternate hreflang
Ogni annotazione hreflang nell’head HTML segue questa struttura: <link rel="alternate" hreflang="codice-lingua" href="https://esempio.com/pagina-localizzata" />. L’attributo rel=”alternate” indica che si tratta di una versione alternativa della pagina corrente. L’attributo hreflang contiene il codice lingua, da solo o combinato con il codice paese. L’attributo href contiene l’URL assoluto della versione di destinazione, incluso il protocollo https://.
Una pagina con tre versioni, italiana, inglese globale e inglese per il Regno Unito, avrà nell’head tre annotazioni hreflang più quella autoreferenziale che punta alla pagina stessa. Tutte e quattro le versioni devono contenere le stesse quattro annotazioni per formare un cluster coerente. L’ordine degli elementi all’interno dell’head non influisce sull’interpretazione da parte di Google.
Codici lingua e paese secondo gli standard ISO
Il codice lingua nell’attributo hreflang segue lo standard ISO 639-1 per le versioni localizzate: due lettere minuscole che identificano la lingua, come it per italiano, en per inglese, de per tedesco, fr per francese. Il codice paese, quando presente, segue lo standard ISO 3166-1 Alpha-2: due lettere maiuscole che identificano la nazione, come IT per Italia, GB per Regno Unito, US per Stati Uniti, DE per Germania.
Google non riconosce codici non previsti da questi standard: usare es-419 per lo spagnolo latinoamericano, ad esempio, non è supportato e l’annotazione viene ignorata. Occorre scegliere i codici dei singoli paesi (es-MX per il Messico, es-AR per l’Argentina) oppure usare solo il codice lingua es per lo spagnolo generico senza specificare la regione. Il codice paese non può essere usato da solo senza il codice lingua: hreflang=”IT” non è valido.
Uso del valore x-default nelle versioni di fallback
Il valore x-default identifica la pagina da servire agli utenti che non rientrano in nessuna delle combinazioni lingua-paese dichiarate nel cluster. Come chiarisce il blog ufficiale di Google Search Central sull’x-default, questo valore specifica l’URL neutrale di lingua e regione per un contenuto quando il sito non supporta la combinazione dell’utente. Un utente francese che arriva su un sito con sole versioni italiana e inglese verrà indirizzato alla pagina con hreflang=”x-default”, tipicamente la versione in inglese o una pagina di selezione della lingua.
La pagina x-default può coincidere con una delle versioni già dichiarate nel cluster (ad esempio la versione en) oppure essere una pagina distinta, come un selettore di lingua e paese. L’inserimento del valore x-default è facoltativo ma raccomandato: la sua assenza non genera errori tecnici, ma riduce la capacità del sistema di gestire utenti provenienti da mercati non coperti dalle annotazioni esistenti.
Come implementare hreflang nelle diverse risorse del sito
Google supporta tre metodi per inserire le annotazioni hreflang in un sito: nell’head HTML di ciascuna pagina, all’interno di una sitemap XML dedicata, e tramite HTTP header per le risorse non HTML. I tre metodi sono equivalenti per Google, ma si adattano a contesti tecnici diversi. Il requisito comune a tutti è che ogni metodo sia applicato in modo coerente all’intero cluster, senza mescolare approcci diversi per la stessa pagina.
Metodi di implementazione del tag
Inserimento nell’head HTML
Il metodo più diffuso prevede l’inserimento dei tag link nell’head di ogni pagina HTML del sito. Ogni pagina del cluster deve contenere tutte le annotazioni hreflang che definiscono il gruppo, inclusa quella autoreferenziale che punta alla pagina stessa. Se una pagina ha dieci varianti linguistiche, ognuna delle dieci pagine conterrà dieci tag link nel proprio head.
Questo approccio è diretto e facilmente verificabile con strumenti di analisi del codice sorgente. Il limite principale riguarda la scalabilità: su siti con migliaia di pagine e decine di varianti linguistiche, la gestione manuale o tramite template dei tag può diventare complessa e soggetta a errori. I CMS con plugin di localizzazione generano solitamente questi tag in modo automatico.
Implementazione in sitemap XML
In alternativa all’head HTML, le annotazioni hreflang possono essere inserite in una sitemap XML usando l’elemento xhtml:link con gli stessi attributi. Ogni nodo URL della sitemap deve includere un elemento xhtml:link per ciascuna versione del cluster, compresa se stesso. Questo metodo è indicato per siti di grandi dimensioni dove modificare l’head di ogni pagina sarebbe oneroso.
La sitemap hreflang va caricata in una directory che abbia autorità sugli URL che elenca. Se la sitemap si trova in /en/, può gestire solo gli URL discendenti di /en/. Per coprire l’intero sito è necessario caricare la sitemap nella directory radice oppure usare più sitemap, una per ciascuna sottodirectory linguistica, tutte referenziate nel file sitemap index.
Implementazione tramite HTTP header per PDF e file non HTML
Per i documenti che non hanno un head HTML, come i file PDF o altri file binari, l’unico metodo disponibile è l’HTTP header. Il server restituisce nella risposta HTTP un header Link con gli stessi attributi rel=”alternate” e hreflang usati nei tag HTML. Questo richiede accesso alla configurazione del server o la possibilità di aggiungere header personalizzati tramite il CMS o il server web (Apache, Nginx).
L’HTTP header è tecnicamente il metodo più robusto perché non dipende dal rendering del documento, ma la sua configurazione richiede competenze tecniche superiori rispetto agli altri due approcci. Viene usato raramente per le pagine HTML standard, dove il tag nell’head è più gestibile, ma diventa l’unica opzione quando le risorse scaricabili devono essere inserite nel cluster hreflang.
Regole tecniche che governano il cluster hreflang
Un cluster hreflang funziona correttamente solo se rispetta un insieme di regole tecniche precise. Google le descrive nella documentazione sulla gestione di siti multiregione e multilingua: i requisiti riguardano la struttura delle annotazioni, il formato degli URL, la coerenza con il canonical e la compatibilità con l’architettura del dominio.
Tag autoreferenziali e annotazioni reciproche
Ogni pagina del cluster deve contenere un’annotazione hreflang che punta a se stessa: questo è il tag autoreferenziale. La sua assenza non impedisce tecnicamente a Google di elaborare il cluster, ma ne riduce la coerenza. Se la pagina A punta alle pagine B e C ma non a se stessa, il cluster risulta incompleto e Google potrebbe trattarlo come ambiguo.
Le annotazioni reciproche (o tag di ritorno) richiedono che ogni pagina che viene citata nelle annotazioni di un’altra pagina citi a sua volta quella stessa pagina. Se la versione italiana punta alla versione inglese, la versione inglese deve puntare alla versione italiana. Un cluster in cui la reciprocità è rispettata solo parzialmente è uno degli errori tecnici più frequenti rilevati negli audit hreflang.
URL assolute, canoniche e raggiungibili
Gli URL nelle annotazioni hreflang devono essere assoluti, non relativi. Usare /en/pagina invece di https://esempio.com/en/pagina non è corretto e può causare interpretazioni errate da parte di Google. L’URL deve includere il protocollo (https://), il dominio completo e il percorso esatto della pagina.
Ogni URL dichiarato in un’annotazione hreflang deve essere raggiungibile dal crawler: non deve essere bloccato da robots.txt, non deve restituire un errore 404 o 500, non deve essere in redirect 301, e non deve avere il tag noindex. Un URL non accessibile rende la relativa annotazione inutilizzabile e può compromettere l’intero cluster. Google non segue i redirect nelle annotazioni hreflang: l’URL deve puntare direttamente alla versione finale della pagina.
Relazione tra hreflang e canonical
Il tag canonical e il tag hreflang svolgono funzioni diverse e devono essere usati in modo coerente. Il canonical indica la versione preferita di una pagina in presenza di duplicati; l’hreflang indica le versioni equivalenti in lingue o paesi diversi. Le due annotazioni possono coesistere nello stesso head senza conflitti, a condizione che il canonical di ciascuna versione punti alla pagina stessa e non a un’altra versione linguistica.
Un errore comune è impostare il canonical di tutte le versioni linguistiche verso la stessa pagina, tipicamente quella nella lingua principale. Questo annulla l’effetto dell’hreflang: Google consolida le versioni come duplicate e indicizza solo quella canonicale. Come indicato nella documentazione Google sulla canonicalizzazione degli URL, se si usano tag hreflang occorre specificare un canonical in ogni lingua, cioè quello corrispondente alla versione stessa.
Gestione della struttura tra domini, sottodomini e sottodirectory
Le annotazioni hreflang funzionano indipendentemente dalla struttura degli URL adottata. Un cluster può includere URL appartenenti a ccTLD diversi (esempio.it, esempio.de), a sottodomini (it.esempio.com, de.esempio.com) o a sottodirectory dello stesso dominio (esempio.com/it/, esempio.com/de/). Google non ha preferenze tecniche tra questi approcci per l’hreflang, anche se i ccTLD forniscono un segnale di targeting geografico più forte per la SEO internazionale.
Un cluster hreflang può attraversare domini diversi senza problemi tecnici. Le restrizioni della sitemap (che può contenere solo URL discendenti dalla sua directory) non si applicano ai tag nell’head HTML, che possono puntare a qualsiasi URL. Questo rende l’implementazione nell’head la scelta più flessibile quando il cluster distribuisce versioni su più domini o sottodomini.
Errori comuni del tag hreflang
La maggior parte dei problemi con l’hreflang deriva da errori nella definizione dei codici, nella struttura del cluster o nello stato degli URL dichiarati. Gli errori non sempre producono avvisi immediati in Google Search Console: alcuni si manifestano come calo di traffico dai mercati internazionali o come mancata indicizzazione delle versioni localizzate, rendendo la diagnosi più lenta.
Codici lingua-regione errati o non standard
L’utilizzo di codici non previsti dagli standard ISO 639-1 e ISO 3166-1 Alpha-2 rende l’annotazione non riconoscibile da Google, che la ignora senza generare un errore esplicito. Codici come es-419 (spagnolo latinoamericano), zh-hans (cinese semplificato con script) o en-uk (errato, il codice corretto è en-GB con la B maiuscola) non vengono elaborati correttamente.
Un altro errore frequente riguarda l’uso del solo codice paese senza il codice lingua, ad esempio hreflang=”DE”. Google non accetta questa forma: il primo elemento dell’attributo deve sempre essere il codice lingua a due lettere. Per targettizzare i parlanti tedesco in Germania si usa hreflang=”de-DE”, mentre per i parlanti tedesco in tutta Europa senza specificare il paese si usa hreflang=”de”.
Tag di ritorno mancanti e cluster incompleti
Il cluster hreflang richiede che le annotazioni siano reciproche: se la versione italiana cita la versione inglese, la versione inglese deve citare l’italiana. Un cluster dove solo alcune pagine contengono le annotazioni complete è considerato incompleto e Google non può usarlo in modo affidabile. Questa situazione si verifica spesso durante le migrazioni parziali o quando alcune sezioni del sito vengono localizzate senza aggiornare le controparti nelle altre lingue.
I tag di ritorno mancanti sono l’errore più frequente rilevato dagli strumenti di audit hreflang. Screaming Frog, nella sua funzionalità di analisi hreflang, genera un report specifico per le annotazioni non reciproche, mostrando quale URL dichiara la relazione e quale URL manca nella risposta. Questo tipo di controllo è difficile da eseguire manualmente su siti con molte versioni linguistiche.
URL in redirect, 404, 500 o noindex
Google non considera valide le annotazioni hreflang che puntano a URL con status HTTP diversi da 200. Un URL che restituisce 404 (non trovato), 500 (errore server), che è in redirect 301 verso un’altra pagina, o che contiene il tag noindex viene escluso dal cluster. Il risultato è un cluster incompleto o del tutto non elaborabile, a seconda di quante annotazioni siano coinvolte.
Questo errore emerge spesso dopo ristrutturazioni del sito in cui le URL localizzate vengono spostate senza aggiornare le annotazioni hreflang nelle pagine rimanenti. Il controllo sistematico dello stato HTTP di tutti gli URL dichiarati in un cluster hreflang deve essere parte dell’audit tecnico di un sito internazionale.
Duplicazione del metodo di implementazione e conflitti tra segnali
Inserire le stesse annotazioni hreflang sia nell’head HTML sia nella sitemap XML per le stesse pagine genera duplicazioni che possono creare segnali contraddittori se i due set non sono perfettamente sincronizzati. Google gestisce questa situazione tentando di riconciliare i dati, ma la coerenza non è garantita. La raccomandazione è scegliere un solo metodo per ciascuna pagina e applicarlo in modo uniforme sull’intero sito.
Un caso particolare riguarda i siti che usano plugin WordPress per l’hreflang e allo stesso tempo hanno annotazioni inserite manualmente nel tema o tramite altri plugin. La sovrapposizione genera duplicazioni difficili da rilevare senza un’ispezione diretta del codice sorgente, poiché entrambe le fonti possono sembrare corrette viste singolarmente.
Avvisi di Google Search Console e casi da ignorare
Google Search Console riporta gli errori hreflang nella sezione dedicata al targeting internazionale. Gli avvisi più comuni segnalano codici lingua non validi, valori hreflang sconosciuti e annotazioni non reciproche. Questi avvisi devono essere valutati caso per caso: alcune segnalazioni riguardano URL non canonici o pagine bloccate intenzionalmente, e non richiedono intervento se la configurazione è deliberata.
Un avviso che può essere ignorato con consapevolezza è quello relativo all’hreflang su pagine con noindex quando la scelta di non indicizzarle è intenzionale, ad esempio per le versioni in fase di staging. Un avviso che richiede sempre attenzione è invece quello sui tag di ritorno mancanti, che segnala cluster strutturalmente incompleti con effetti diretti sulla visibilità nei mercati internazionali.
Come verificare il tag hreflang e risolvere i problemi
La verifica dell’hreflang richiede l’uso combinato di più strumenti: Google Search Console per i dati di copertura e gli errori aggregati, crawler come Screaming Frog per l’audit tecnico del cluster, e strumenti di test specifici per la validazione della sintassi delle singole annotazioni. Nei siti gestiti con CMS, la configurazione del plugin di localizzazione aggiunge un livello di verifica ulteriore.
Controlli in Google Search Console
Google Search Console espone i dati sull’hreflang nella sezione Copertura e nel report Targeting internazionale. Il report Targeting internazionale mostra gli avvisi relativi ai codici lingua non validi e alle annotazioni con errori. La sezione Copertura consente di verificare se le URL dichiarate nel cluster vengono indicizzate o se presentano problemi di scansione. Lo strumento di Ispezione URL permette di analizzare una singola pagina e vedere come Google la ha elaborata, incluse le annotazioni hreflang presenti al momento dell’ultima scansione.
Un controllo efficace consiste nel verificare separatamente ciascuna versione linguistica del cluster tramite Ispezione URL, controllando che l’URL canonico coincida con la versione stessa e che le annotazioni hreflang siano lette correttamente. Se Google mostra un canonical diverso da quello atteso, è probabile che il tag canonical sia in conflitto con le annotazioni hreflang.
Audit con Screaming Frog e tool di test
Screaming Frog analizza il sito in scansione e raccoglie tutte le annotazioni hreflang trovate nelle pagine. Il report dedicato mostra, per ogni URL, le annotazioni dichiarate, gli URL corrispondenti e la presenza o assenza delle annotazioni di ritorno. La visualizzazione per cluster permette di identificare rapidamente le versioni incomplete o quelle con URL che restituiscono errori HTTP.
Per la validazione della sintassi delle singole annotazioni esistono strumenti online come Hreflang Tag Testing Tool che permettono di incollare il codice HTML di una pagina e ricevere un’analisi degli errori di formato. Questi strumenti non sostituiscono l’audit completo del cluster, ma sono utili per validare la struttura prima di pubblicare una nuova implementazione o dopo modifiche puntuali al template.
I controlli minimi da eseguire in un audit hreflang comprendono:
- Verifica dello stato HTTP di tutti gli URL dichiarati nel cluster, per escludere 404, redirect e pagine bloccate.
- Controllo della reciprocità tra tutte le coppie di versioni, per identificare annotazioni di ritorno mancanti.
- Confronto tra canonical e annotazioni hreflang, per rilevare conflitti in cui il canonical di una versione punta a un’altra.
Gestione del tag hreflang su WordPress e CMS multilingua
Su WordPress, la gestione dell’hreflang è tipicamente delegata a plugin di localizzazione come WPML, Polylang o TranslatePress. Questi plugin generano automaticamente i tag nell’head di ogni pagina tradotta, gestendo i tag autoreferenziali e le annotazioni reciproche senza intervento manuale. La configurazione corretta dei plugin richiede di associare esplicitamente ogni pagina tradotta alla sua versione originale, senza affidarsi al solo rilevamento automatico della lingua.
Un punto critico nei CMS multilingua è la gestione delle pagine parzialmente tradotte: se solo alcune pagine del sito hanno una versione in lingua straniera, le annotazioni hreflang devono essere presenti solo su quelle pagine e non estese all’intero sito. Aggiungere annotazioni hreflang a pagine prive di una contropartita localizzata produce cluster incompleti e avvisi in Google Search Console che segnalano annotazioni senza tag di ritorno.
