Hreflang: guida all'implementazione per la SEO internazionale

Quando un sito serve più mercati o più lingue, il problema non è solo tradurre i contenuti: è fare in modo che Google mostri a ciascun utente la versione giusta. Un utente svizzero di lingua tedesca che atterra sulla versione tedesca per la Germania vedrà prezzi in euro invece che in franchi, condizioni di spedizione sbagliate e magari un numero di telefono che non può chiamare. L'attributo hreflang esiste per risolvere esattamente questo scenario: comunica ai motori di ricerca quale versione linguistica o geografica di una pagina mostrare, in base alla lingua e alla posizione dell'utente.

Introdotto da Google nel dicembre 2011, l'hreflang è oggi uno degli elementi tecnici più delicati della SEO internazionale: concettualmente semplice, ma con un tasso di errore in fase di implementazione altissimo. In questa guida vediamo come funziona, come si implementa nei tre metodi supportati, quali regole vanno rispettate perché Google lo consideri valido e quali sono gli errori che più spesso ne annullano l'effetto.

L'hreflang è un attributo che si applica a un elemento link con rel="alternate" e dichiara la relazione tra le diverse versioni localizzate di uno stesso contenuto. Nella sua forma base, inserita nella sezione head di una pagina HTML, si presenta così:

<link rel="alternate" hreflang="it" href="https://www.example.com/it/" />

<link rel="alternate" hreflang="en" href="https://www.example.com/en/" />

La logica è quella di un cluster: tutte le pagine che rappresentano lo stesso contenuto in lingue o mercati diversi si dichiarano a vicenda, formando un insieme chiuso di URL alternativi. Quando Google riceve una query da un utente con una determinata lingua e localizzazione, può pescare dal cluster la versione più pertinente e mostrarla in SERP al posto di quella che avrebbe ottenuto il ranking.

Vale la pena chiarire subito tre punti che generano fraintendimenti ricorrenti.

1. L'hreflang non è un fattore di ranking. Non fa posizionare meglio una pagina; fa in modo che, a parità di posizionamento, venga mostrato l'URL corretto per quell'utente. Il beneficio SEO è indiretto ma concreto: migliore esperienza utente, riduzione della frequenza di rimbalzo dovuta ad atterraggi sulla lingua sbagliata, e consolidamento dei segnali all'interno del cluster.
2. Google non usa l'hreflang per determinare la lingua di una pagina. La lingua viene rilevata algoritmicamente dal contenuto stesso, e Google ignora anche l'attributo HTML lang. L'hreflang serve solo a mappare le varianti tra loro. Ne consegue che dichiarare hreflang="de" su una pagina il cui contenuto è in inglese non la farà mai comparire nelle ricerche in tedesco.
3. L'hreflang risolve anche un potenziale problema di contenuti duplicati, ma con un perimetro preciso. Google considera duplicate le versioni localizzate solo quando il contenuto principale resta non tradotto: è il caso tipico di un sito in inglese per Stati Uniti, Regno Unito e Australia, dove cambiano solo valuta e dettagli commerciali. In quello scenario l'hreflang dice a Google che la quasi-duplicazione è intenzionale e che ogni versione ha un suo pubblico legittimo.

L'implementazione ha senso in tre scenari, che sono poi quelli descritti dalla stessa documentazione Google. Il primo è il sito multilingua vero e proprio, dove il contenuto è tradotto integralmente in più lingue. Il secondo è il sito multi-regione nella stessa lingua, con varianti minime del contenuto: prezzi, valute, spedizioni, riferimenti legali. Il terzo è il caso ibrido, ed è il più frequente nei progetti internazionali strutturati: un contenuto tradotto in più lingue e, all'interno della stessa lingua, declinato per più paesi (en-US, en-GB, en-AU e così via).

Al contrario, su un sito monolingua rivolto a un solo mercato l'hreflang non porta alcun beneficio, e implementarlo per abitudine aggiunge solo complessità di manutenzione.

Il valore dell'attributo segue il formato lingua-regione, dove la lingua è obbligatoria e la regione facoltativa:

hreflang="lingua" → solo lingua, qualsiasi regione

hreflang="lingua-REGIONE" → lingua per una regione specifica

I codici non sono arbitrari. La lingua va espressa in formato ISO 639-1 (due lettere minuscole: it, en, de, fr), la regione in formato ISO 3166-1 Alpha 2 (due lettere maiuscole: IT, US, GB, CH). Sono quindi validi valori come de (tedesco, ovunque), en-GB (inglese per il Regno Unito) o anche combinazioni non ovvie come de-BE (tedesco per il Belgio): la coppia lingua-paese non deve rispecchiare la lingua ufficiale del paese.

Gli errori su questi codici sono tra i più comuni in assoluto, perché alcune sigle intuitive sono sbagliate. "be" non è il Belgio ma il codice lingua del bielorusso; "UK" non è un codice ISO valido per il Regno Unito (il codice corretto è GB); "EU" e "UN" sono codici riservati e Google li ignora del tutto. Non esiste inoltre la possibilità di targetizzare un continente o un'area commerciale: chi vuole coprire l'Europa deve dichiarare i singoli paesi, oppure usare il solo codice lingua senza regione.

Un ulteriore livello, meno noto, è il codice di scrittura in formato ISO 15924, utile per le lingue con più sistemi di scrittura. Il caso classico è il cinese: zh-Hant per il tradizionale, zh-Hans per il semplificato, fino a combinazioni complete come zh-Hans-US (cinese semplificato per utenti negli Stati Uniti). Se lo script non viene dichiarato, Google lo deduce dal contenuto.

Regola non negoziabile: la regione da sola non è mai un valore valido. hreflang="US" è un errore; serve sempre almeno il codice lingua, quindi en-US.

Il cluster hreflang copre le combinazioni dichiarate, ma cosa succede a un utente la cui lingua non corrisponde a nessuna versione? Per questo esiste il valore riservato x-default, che indica la pagina di riserva da mostrare quando nessuna variante è pertinente:

<link rel="alternate" hreflang="x-default" href="https://www.example.com/" />

Tipicamente l'x-default punta alla versione internazionale in inglese, alla homepage generica o, soluzione particolarmente indicata, a una pagina di selezione lingua/paese: in quel caso l'utente fuori target sceglie da sé la versione più adatta. L'x-default non richiede alcun codice lingua ed è formalmente facoltativo, ma ometterlo significa lasciare che sia Google a decidere quale versione mostrare agli utenti non coperti, con risultati non sempre prevedibili. Nei cluster internazionali strutturati va considerato parte dello standard implementativo.

Un dettaglio spesso trascurato: la pagina indicata come x-default può coincidere con una delle versioni già dichiarate nel cluster (per esempio la versione en generica). Non serve creare una pagina apposita.

Google supporta tre modalità di annotazione, equivalenti dal punto di vista algoritmico. La scelta è quindi una questione di praticità e di architettura del sito, non di efficacia. Usarne più di uno contemporaneamente non porta vantaggi e moltiplica le superfici di errore: se ne sceglie uno e lo si presidia.

Tag link nella sezione head

È il metodo più diffuso. Ogni pagina del cluster include, nella sezione head, l'elenco completo delle varianti, sè stessa inclusa. Riprendendo l'esempio della documentazione Google, un sito con versioni per inglese britannico, inglese americano, inglese generico e tedesco avrà su ogni pagina del cluster questo blocco identico:

<head>

<title>Widgets, Inc</title>

<link rel="alternate" hreflang="en-gb" href="https://en-gb.example.com/page.html" />

<link rel="alternate" hreflang="en-us" href="https://en-us.example.com/page.html" />

<link rel="alternate" hreflang="en" href="https://en.example.com/page.html" />

<link rel="alternate" hreflang="de" href="https://de.example.com/page.html" />

<link rel="alternate" hreflang="x-default" href="https://www.example.com/" />

</head>

Il limite di questo metodo è di scala: su siti con molte lingue, ogni pagina si porta dietro decine di righe nell'head, con un impatto marginale sul peso della pagina ma un costo di manutenzione reale. Ogni nuova lingua obbliga ad aggiornare l'head di tutte le versioni esistenti.

Intestazioni HTTP

Per i contenuti non HTML, come i PDF, il tag nell'head non è ovviamente disponibile. In questi casi le annotazioni si passano nella risposta del server tramite l'intestazione Link, con gli URL racchiusi tra parentesi angolari e le varianti separate da virgole:

Link: <https://example.com/file.pdf>; rel="alternate"; hreflang="en",
<https://de-ch.example.com/file.pdf>; rel="alternate"; hreflang="de-ch",
<https://de.example.com/file.pdf>; rel="alternate"; hreflang="de"

Anche qui vale la regola del set completo: l'intestazione deve essere identica per ogni versione della risorsa e includere tutte le varianti.

Sitemap XML

Il terzo metodo sposta le annotazioni fuori dalle pagine, dentro la sitemap. Richiede la dichiarazione del namespace xhtml e, per ogni URL, un elemento xhtml:link per ciascuna variante, inclusa la pagina stessa:

<?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://www.example.com/english/page.html</loc>

<xhtml:link rel="alternate" hreflang="de"

href="https://www.example.de/deutsch/page.html"/>

<xhtml:link rel="alternate" hreflang="de-ch"

href="https://www.example.de/schweiz-deutsch/page.html"/>

<xhtml:link rel="alternate" hreflang="en"

href="https://www.example.com/english/page.html"/>

</url>

</urlset>

Lo stesso blocco va ripetuto per ogni URL del cluster, cambiando il loc principale. La sitemap è generalmente la scelta migliore per siti di grandi dimensioni: centralizza le annotazioni in un unico punto, non appesantisce le pagine e si presta alla generazione automatica. Il rovescio della medaglia è la dimensione del file, che cresce rapidamente (un sito con 10 lingue genera 10 righe di annotazione per ogni URL, per ogni versione), e la minore visibilità degli errori, che non si vedono ispezionando la pagina.

Qualunque sia il metodo scelto, Google applica le stesse condizioni di validità, e la loro violazione è la ragione per cui gran parte delle implementazioni hreflang in circolazione è parzialmente o totalmente ignorata.

La prima è la bidirezionalità, o conferma di ritorno: se la pagina A dichiara B come alternativa, B deve dichiarare A. I link di ritorno sono il meccanismo con cui Google verifica che entrambi i siti concordino sulla relazione, impedendo a un dominio terzo di dichiararsi arbitrariamente "versione alternativa" di un sito che non controlla. Senza conferma di ritorno, le annotazioni vengono ignorate o interpretate in modo scorretto.

La seconda è l'autoreferenzialità: ogni pagina deve includere anche il riferimento a sé stessa. Il set di annotazioni è identico su tutte le versioni del cluster, ed è proprio questa identità a renderlo coerente.

La terza riguarda gli URL, che devono essere assoluti e completi di protocollo: https://example.com/it/ è valido, //example.com/it/ o /it/ no. Gli URL dichiarati devono inoltre essere URL canonici e indicizzabili, che rispondono con status 200: puntare l'hreflang a URL con redirect, noindex o errori 4xx compromette il funzionamento del cluster.

Da notare che le varianti non devono necessariamente stare sullo stesso dominio: l'hreflang funziona anche tra ccTLD diversi (example.it, example.de, example.fr), tra sottodomini o tra directory, e questo lo rende compatibile con qualunque architettura internazionale.

Infine, una buona pratica di copertura: se si dichiarano più varianti regionali della stessa lingua (en-IE, en-CA, en-AU), conviene dichiarare anche la versione generica en come fallback per tutti gli altri utenti anglofoni, oltre naturalmente all'x-default per le lingue non coperte.

Hreflang e rel=canonical operano su piani diversi e vanno usati insieme, ma con attenzione.

• Il canonical dice a Google quale URL considerare la versione di riferimento tra pagine duplicate;
• l'hreflang mappa versioni localizzate che devono restare tutte indicizzabili, ciascuna per il proprio mercato.

La regola operativa è una sola: ogni pagina del cluster hreflang deve avere un canonical autoreferenziale. L'errore tipico, e devastante, è impostare su tutte le versioni linguistiche un canonical verso la versione principale (per esempio quella inglese): così facendo si chiede a Google di deindicizzare le versioni locali, e l'hreflang che le dichiara diventa contraddittorio. Google si trova con due segnali in conflitto e in genere risolve ignorando l'hreflang. Canonical cross-lingua e hreflang sulla stessa pagina sono incompatibili per definizione.

Lo stesso principio vale per i redirect automatici basati su IP o lingua del browser: oltre a non sostituire l'hreflang, rischiano di danneggiarlo, perché Googlebot scansiona prevalentemente da IP statunitensi e un redirect forzato può impedirgli di raggiungere le versioni locali. Meglio un banner che suggerisce la versione corretta lasciando libero l'utente, e Googlebot, di navigare.

Ricapitolando i punti visti finora dal lato opposto, questi sono gli errori che più spesso emergono in audit:

• annotazioni senza link di ritorno, tipicamente perché una nuova lingua è stata aggiunta senza aggiornare le versioni esistenti;

• codici ISO errati o invertiti (UK invece di GB, be per il Belgio, regione senza lingua);
• URL relativi o non canonici nelle annotazioni;
• set incompleti, dove alcune versioni dichiarano il cluster e altre no;
• canonical cross-lingua in conflitto con l'hreflang;
• x-default omesso;
• l'errore sintattico di combinare hreflang con altri attributi (per esempio media) nello stesso elemento link, cosa che ne invalida l'interpretazione.

C'è poi l'errore di processo, il più sottovalutato: considerare l'hreflang un'attività una tantum. Ogni pagina nuova, ogni URL modificato, ogni lingua aggiunta o rimossa altera il cluster, e un cluster parzialmente rotto degrada in silenzio. L'hreflang va trattato come un asset da monitorare, non come una configurazione da fare una volta sola.

Dal settembre 2022 Google Search Console non offre più il report International Targeting, che segnalava gli errori hreflang rilevati (e permetteva il geo-targeting manuale dei domini generici). Il monitoraggio è quindi interamente a carico di strumenti esterni.

Per la generazione dei tag il riferimento resta l'hreflang Tags Generator di Aleyda Solis, citato dalla stessa documentazione Google insieme all'hreflang Test Tool di Merkle per la validazione puntuale di singole pagine pubblicate. Per l'analisi a livello di sito, i crawler come Screaming Frog offrono report hreflang dedicati che intercettano i problemi ricorrenti: link di ritorno mancanti, URL che non rispondono 200, codici lingua non validi, autoreferenzialità assente. Anche le suite come Semrush e Ahrefs includono controlli hreflang nei rispettivi site audit.

Su siti internazionali di dimensioni rilevanti, la validazione hreflang dovrebbe entrare nel crawl periodico di monitoraggio tecnico, con particolare attenzione dopo ogni rilascio che tocca URL, template o gestione delle lingue.

L'hreflang è lo strumento con cui si governa il matching tra utenti e versioni localizzate di un sito, e insieme la protezione contro i problemi di quasi-duplicazione tra mercati della stessa lingua. Funziona solo se implementato come sistema chiuso e coerente: set completi e identici su tutte le versioni, bidirezionalità, autoreferenzialità, URL assoluti e canonici, codici ISO corretti, x-default come rete di sicurezza. Un solo metodo di implementazione, scelto in base all'architettura del sito, e un monitoraggio continuo tramite crawler, dato che Search Console non copre più questo fronte.

Va infine ricordato il suo perimetro: l'hreflang mappa le varianti, non fa ranking e non localizza il contenuto. La SEO internazionale si gioca prima di tutto su contenuti effettivamente localizzati, architettura coerente e segnali locali; l'hreflang è il livello tecnico che rende leggibile tutto questo ai motori di ricerca.

Se stai implementando o verificando la gestione dell'hreflang su un sito internazionale, il team SEO di Pro Web Digital Consulting può supportarti con un audit tecnico mirato, dalla validazione del cluster alla risoluzione dei conflitti con il canonical.

Contattaci per una consulenza.