Hreflang: come implementarlo e come verificarlo

L’hreflang (o tag hreflang) è un’annotazione che dichiara quali URL sono la stessa pagina in un’altra lingua o per un altro paese. Serve a Google per scambiare l’URL che mostra in SERP con quello adatto a chi sta cercando. Non garantisce l’indicizzazione. E non dice a Google in che lingua è scritta la pagina.

Le regole che sembrano quattro capricci slegati (autoreferenza, reciprocità, codici validi, x-default) sono la stessa proprietà vista da quattro lati: il set è un grafo, e finché non chiude Google butta via l’annotazione e sceglie da sé.

I tre posti in cui puoi implementarla, head HTML, header HTTP e sitemap XML, sono equivalenti per Google: la sintassi cambia, il risultato no. Sceglierne uno basta.

Da quando il rapporto Targeting internazionale è stato ritirato da Search Console, la verifica è tutta manuale: sorgente della pagina, controllo URL, checker esterni, crawl del sito.

Che cos’è l’hreflang, in una riga

L’hreflang è l’attributo con cui una pagina dichiara le proprie versioni alternative per lingua e per paese. Il valore è un codice lingua, con l’eventuale aggiunta di regione o di script: it, en-gb, zh-Hant.

Non è un tag a sé stante. Vive dentro un <link rel="alternate"> nell’head, dentro un header HTTP Link: o dentro un <xhtml:link> in sitemap, e serve a una cosa sola: quando Google ha già deciso di mostrare quel contenuto, l’annotazione gli permette di sostituire l’URL con la versione più adatta a chi ha fatto la ricerca.

Il resto di quello che gli viene attribuito non lo fa. Non dichiara la lingua della pagina: la documentazione sulle versioni localizzate scrive che «Google non utilizza hreflang o l’attributo HTML lang per rilevare la lingua di una pagina; utilizza, invece, gli algoritmi per determinarla». Non fa entrare nell’indice pagine che l’indice non vuole e non mette al riparo da niente. Sul posizionamento la documentazione tace, ma il meccanismo parla da sé: l’annotazione entra in gioco quando Google ha già scelto il contenuto da mostrare, e non è lì che si vincono posizioni.

Le due condizioni per cui serve davvero sono banali e restrittive: hai lo stesso contenuto in più lingue, oppure hai lo stesso contenuto nella stessa lingua ma differenziato per mercato (prezzi in sterline e in dollari, spedizioni diverse, condizioni legali diverse). Un sito monolingua con un’unica versione non ha niente da annotare.

Su un e-commerce con varianti di paese la questione si intreccia con la gestione degli URL duplicati: quella parte l’ho trattata nel pezzo sulla SEO per e-commerce.

La pagina italiana della documentazione porta come ultimo aggiornamento il 27 aprile 2026, la versione inglese il 22 dicembre 2025.

Il set hreflang è un grafo: se non chiude, Google lo butta

Un set hreflang è un grafo: i nodi sono le versioni della pagina, gli archi sono le annotazioni. Google lo processa solo dove le coppie di nodi si puntano a vicenda, e ogni nodo deve elencare anche sé stesso.

Pensalo come la lista dei soci di un circolo affissa in bacheca. Ogni socio ne tiene una copia, e su ogni copia ci sono tutti, lui compreso. Se sulla tua copia manchi tu, quella lista non è la tua. Se tu ci hai scritto Marco ma sulla copia di Marco non ci sei, in bacheca vale quella di Marco.

La reciprocità non è una formalità burocratica, ha un motivo scritto: «Se due pagine non rimandano l’una all’altra, i tag vengono ignorati per fare in modo che un utente su un altro sito non possa creare arbitrariamente un tag che si autonomini versione alternativa di una delle tue pagine». Senza quella regola potrei attaccare al tuo portone un cartello con scritto «la versione francese di questa casa è casa mia» e mettermi ad aspettare la posta.

Da lì discende l’autoreferenza, che è la riga che più spesso manca: «Per la versione in ogni lingua è necessario indicare la versione stessa e le versioni in tutte le altre lingue». Serve perché il set che una pagina dichiara sia autoconsistente: senza il proprio nodo, quel blocco descrive un gruppo di cui la pagina che lo ospita non fa parte.

L’aritmetica che ne esce spaventa più di quanto dovrebbe. Con N versioni ogni pagina porta N annotazioni, e il set completo ne conta N × N. Tre lingue fanno tre righe per pagina e nove in tutto; dodici mercati fanno dodici righe per pagina. Le righe crescono con il numero di versioni, non con il numero di pagine: un catalogo da diecimila prodotti in tre lingue resta a tre righe per pagina.

Su dodici mercati la matrice completa diventa ingestibile, e la documentazione ne tiene conto: puoi omettere alcune lingue su alcune pagine, Google continua a processare quelle che si puntano a vicenda, e la raccomandazione è collegare le nuove versioni alle lingue di origine o dominanti. Il grafo non deve essere completo, deve chiudere sugli archi che dichiari.

La sintassi: lingua, regione, script

Il valore dell’attributo è un codice lingua ISO 639-1 di due lettere, con una regione ISO 3166-1 Alpha 2 facoltativa dopo un trattino. La lingua da sola vale (it), la regione da sola no (ch non esiste come annotazione), e lo script si dichiara con ISO 15924 quando la stessa lingua si scrive in due alfabeti.

La formula «due lettere più due lettere», ripetuta ovunque, regge finché non incontri il cinese o il serbo.

L’ultima riga è quella che salta a tutti. Con le sole varianti regionali di una lingua copri i paesi che hai elencato e nessun altro, e la documentazione chiede di aggiungere un URL catch-all per quella lingua. L’esempio che porta è l’inglese: con URL specifici per l’Irlanda (en-ie), il Canada (en-ca) e l’Australia (en-au), va fornito un URL generico (en) per chi cerca in inglese negli Stati Uniti, nel Regno Unito e in tutte le altre località dove si parla inglese. Vale identico per ogni lingua con varianti regionali: un es accanto a es-es e es-mx. È un problema diverso da quello che risolve x-default, e va risolto in aggiunta.

Sul cinese la combinazione lingua-script-regione si estende: zh-Hans-US dichiara il cinese semplificato per gli utenti negli Stati Uniti. Se gestisci un sito in cinese e ti sei fermato a zh-CN e zh-TW stai puntando a due paesi, non a due sistemi di scrittura, e lasci fuori tutti i lettori di cinese che vivono altrove.

I codici invalidi non danno errore da nessuna parte: la riga resta nell’HTML, il validatore del browser non fiata, e l’annotazione viene ignorata.

x-default: a cosa serve davvero

x-default è l’URL da mostrare quando nessuna delle versioni dichiarate corrisponde alla lingua o al paese di chi cerca. Non è obbligatorio, e non sostituisce il catch-all di sola lingua.

L’esempio è nel post di Google su x-default, dell’8 maggio 2023: un set con annotazioni per inglese e spagnolo e x-default sulla versione inglese manda un utente francofono sulla versione inglese. Senza quella riga il francofono non corrisponde a nessuna combinazione dichiarata, e la scelta torna a Google (questa seconda parte è una deduzione mia: né quel post né l’introduzione dell’aprile 2013 dicono cosa accade in assenza di x-default).

Dove farlo puntare dipende da cosa hai. La home con selettore di lingua e la home che reindirizza in automatico sono i due casi tipici già dell’introduzione del 2013; su un sito senza pagina neutra, la versione nella lingua franca del tuo pubblico è la scelta pratica, e nel set inglese-spagnolo la documentazione fa esattamente così.

Lo stesso post aggiunge una cosa che di solito passa inosservata: gli URL dichiarati nelle annotazioni, x-default compreso, possono servire a Google per scoprire URL. Sui siti grandi è un effetto collaterale gradito.

Un x-default mancante non rompe niente del resto del set: le combinazioni coperte continuano a funzionare come prima.

I tre modi per dichiararlo, e perché ne scegli uno solo

Head HTML, header HTTP e sitemap XML fanno la stessa cosa, e la documentazione lo mette per iscritto: «I tre metodi sono equivalenti dal punto di vista di Google e puoi scegliere tu quello che è più pratico per il tuo sito. Sebbene sia possibile utilizzare tutti e tre i metodi contemporaneamente, ciò non comporta vantaggi per la Ricerca (in realtà, potrebbe essere molto più difficile gestire tre implementazioni invece di sceglierne solo una).»

Nell’head il blocco va ripetuto identico su tutte le pagine del set, quella che lo ospita inclusa.

<link rel="alternate" hreflang="it" href="https://esempio.it/scarpe/" />
<link rel="alternate" hreflang="en-gb" href="https://esempio.it/en-gb/shoes/" />
<link rel="alternate" hreflang="en-us" href="https://esempio.it/en-us/shoes/" />
<link rel="alternate" hreflang="en" href="https://esempio.it/en/shoes/" />
<link rel="alternate" hreflang="x-default" href="https://esempio.it/en/shoes/" />

Sui file non HTML l’head non c’è, e allora si passa dall’header di risposta. Uno solo, con i valori separati da virgola, non tre header Link: diversi.

Link: <https://esempio.it/listino.pdf>; rel="alternate"; hreflang="it", <https://esempio.it/en/pricelist.pdf>; rel="alternate"; hreflang="en", <https://esempio.it/en/pricelist.pdf>; rel="alternate"; hreflang="x-default"

In sitemap le annotazioni sono figli di <url> e richiedono il namespace xhtml dichiarato su <urlset>, altrimenti il file non valida. Ogni versione ha il suo blocco <url>, e ogni blocco ripete l’elenco completo.

<?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://esempio.it/scarpe/</loc>
    <xhtml:link rel="alternate" hreflang="it" href="https://esempio.it/scarpe/"/>
    <xhtml:link rel="alternate" hreflang="en" href="https://esempio.it/en/shoes/"/>
  </url>
  <url>
    <loc>https://esempio.it/en/shoes/</loc>
    <xhtml:link rel="alternate" hreflang="it" href="https://esempio.it/scarpe/"/>
    <xhtml:link rel="alternate" hreflang="en" href="https://esempio.it/en/shoes/"/>
  </url>
</urlset>

Il resto della sintassi delle sitemap, limiti e invio compresi, sta nella guida alla sitemap XML.

Se me lo chiedi: sui siti su cui metto le mani scelgo l’head, e non per eleganza. È l’unico dei tre che si verifica con un Ctrl+U in due secondi, senza aprire un terminale e senza rileggere un file da diecimila righe, e quando una cosa si controlla in due secondi la controlli davvero. Passo alla sitemap solo quando il template non è modificabile o le versioni sono tante, all’header HTTP solo per i PDF.

Un ultimo vincolo di sintassi, arrivato con l’aggiornamento del 12 giugno 2024 intitolato «Chiarimento sugli attributi del tag link» nel registro delle modifiche alla documentazione: «i tag link per indicare le versioni alternative di una pagina non devono essere combinati in un singolo tag link». L’esempio che la documentazione porta è la combinazione di hreflang con media dentro lo stesso <link>. Ricade sotto la stessa regola anche il rel="canonical, alternate" che si vede in giro: una riga, due dichiarazioni, nessuna delle due che funziona.

hreflang e canonical: due lavori diversi sullo stesso URL

Il canonical sceglie quale URL vale come versione principale di un contenuto che esiste in copie identiche; l’hreflang sceglie quale versione linguistica mostrare a chi. Convivono sulla stessa pagina, non si sostituiscono e non si sommano.

La riga operativa sta nella documentazione sugli URL duplicati: «Se utilizzi gli elementi hreflang, assicurati di specificare una pagina canonica nella stessa lingua o nella migliore lingua sostitutiva, se una pagina canonica non esiste per la stessa lingua.» Nel caso normale la pagina inglese si dichiara canonica di sé stessa, l’italiana di sé stessa, e ognuna porta il set completo di annotazioni. Il caso storto è la seconda metà della frase, ed è quello di chi ha un mercato senza pagina propria: se per quella lingua una canonica non esiste, la canonica va messa sulla lingua sostitutiva più vicina, non sulla lingua principale del sito per abitudine.

L’errore che manda in vacca interi siti multilingua è il canonical di tutte le versioni puntato alla lingua principale. Chi lo fa di solito lo fa in buona fede, per «evitare i duplicati»: sta dicendo a Google che la versione inglese non è una pagina a sé, e le annotazioni che la nominano restano senza un destinatario stabile.

Stessa pagina, un secondo chiarimento: le annotazioni rel="canonical" con attributi hreflang, lang, media o type non vengono usate per la canonicalizzazione. Metterle non aggiunge informazione, e quel rel="canonical, alternate" in un tag solo resta vietato dal chiarimento del giugno 2024.

Sul duplicato in sé quella pagina non parla mai di penalizzazioni: tratta la scelta dell’URL da mostrare e il raggruppamento dei segnali, e finisce lì. Le versioni linguistiche di una pagina, poi, non sono nemmeno duplicati: sono contenuti diversi che dicono la stessa cosa in lingue diverse.

Gli errori, in ordine di quanto rompono

Ogni errore qui sotto è lo stesso grafo che non chiude, visto da un lato diverso. L’ordine è quello del danno: i primi tre annullano il set, gli ultimi lo erodono.

Return link mancante. La pagina italiana dichiara l’inglese, l’inglese non dichiara l’italiana. Succede quasi sempre dopo l’aggiunta di una lingua nuova: il template nuovo nasce completo, i vecchi restano com’erano. Google ignora la coppia e mostra l’URL che ha scelto da solo. Il tag c’è, il nodo no.

Autoreferenza mancante. Il blocco elenca tutte le altre versioni e salta sé stesso, di solito perché il template genera l’elenco «delle altre lingue» ciclando su un array da cui la lingua corrente è esclusa. Il fix sta in una riga di codice, l’unica difficoltà è accorgersene: nessuno strumento ti avverte, e l’HTML sembra a posto.

Codici invalidi. en-UK, es-419, eng-gb. Nessun messaggio, da nessuna parte: l’annotazione viene ignorata in silenzio e tu continui a contarla fra quelle attive finché non la rileggi carattere per carattere.

Il quarto errore è l’URL che non risponde 200. Puoi annotare solo pagine vive e indicizzabili: un’annotazione verso una pagina in redirect, in 404 o in noindex dichiara un nodo che non esiste, e il set si accorcia da sé. Se la pagina di destinazione è esclusa apposta dall’indice, il problema non è l’hreflang: ne ho scritto nella guida al tag noindex.

Il quinto è il conflitto col canonical, quello del paragrafo precedente. Il sesto è la dichiarazione ripetuta in più posti: head e sitemap che dicono cose diverse dopo che qualcuno ha aggiornato solo una delle due. Non c’è un vincitore prevedibile, c’è solo un set che a volte chiude e a volte no.

URL relativi o senza protocollo. Gli URL alternativi vanno scritti per intero, con lo schema: non //esempio.it/foo e non /foo. Possono invece stare su domini diversi, cosa che sorprende sempre chi ha un ccTLD per mercato.

Annotazioni fuori posto. Il <link> va nell’head, non nel body, e non vale se lo inietti via JavaScript dopo il caricamento. Vale anche per la trappola più diffusa: gli attributi hreflang sui tag <a> del selettore di lingua non sono annotazioni valide. Sono un’indicazione per il browser e per le tecnologie assistive, niente di più. Contano solo <link rel="alternate"> nell’head, l’header HTTP e la sitemap: se il tuo selettore di lingua ha gli hreflang sui link cliccabili e nell’head non c’è nulla, il set semplicemente non esiste.

Manutenzione dimenticata. Migrazioni, cambi di permalink, pagine ritirate in un solo mercato. Il set era corretto il giorno del lancio e da allora nessuno l’ha più guardato, mentre gli URL annotati sono finiti dietro un 301: vale la pena rileggerlo insieme alla mappa dei redirect 301 ogni volta che ne sposti in blocco.

Come verifichi gli hreflang, ora che il report di Search Console non c’è più

A mano, e con strumenti di terze parti. Il rapporto Targeting internazionale è stato ritirato: Google continua a supportare e a usare i tag hreflang nelle pagine, ma non ti segnala più gli errori e non ti dà più il conteggio dei return link mancanti. Chi ti consiglia ancora di impostare il targeting per paese da Search Console ti sta mandando a cercare una funzione che Search Console non offre più: quella scelta, scrive Google, «è risultata poco utile per l’ecosistema e, pertanto, questa opzione non è più supportata».

Sulla singola pagina il controllo più rapido resta il sorgente. Ctrl+U, cerchi hreflang, conti le righe e verifichi che ci sia anche quella verso l’URL su cui ti trovi. L’autoreferenza mancante salta fuori subito.

Per il rendering c’è lo strumento di controllo URL di Search Console, che mostra l’HTML come lo vede Googlebot: serve quando il sospetto è che le annotazioni vengano aggiunte da uno script, perché lì si vede se ci sono davvero.

I checker esterni li elenca la documentazione stessa. Lo strumento di test dei tag hreflang di Merkle SEO valida le annotazioni di una singola pagina pubblicata e ti dice se il set che vede da fuori corrisponde a quello che credi di aver messo; accanto c’è il generatore di tag hreflang di Aleyda Solis, per scriverle invece che leggerle. Su entrambi la stessa pagina mette una clausola: «Questi strumenti non sono gestiti o controllati da Google.» Che è il modo educato per dire che un hreflang checker è un secondo paio d’occhi, non un’autorità: se il tester e il sorgente non concordano, ha ragione il sorgente.

Sul sito intero non si scappa dal crawl. Un crawler che estragga gli hreflang di tutte le pagine e confronti le coppie è l’unico modo per vedere la reciprocità, perché un controllo a campione trova gli errori di template e perde quelli sulle singole pagine, che sono la maggioranza. Va bene qualunque crawler che sappia estrarre le annotazioni pagina per pagina, Screaming Frog e Sitebulb compresi.

Nessuno di questi controlli parte da solo: vanno lanciati dopo ogni aggiunta di lingua, ogni migrazione e ogni cambio di struttura degli URL, che è poi la lista dei momenti in cui il set si rompe.

Struttura degli URL e redirect: il contorno che decide l’esito

La struttura degli URL è la prima decisione di SEO internazionale, e decide quanto lavoro dovrai fare con gli hreflang. Le opzioni sono quattro, e la guida ai siti multiregionali le mette in fila con vantaggi e svantaggi.

Sui contenuti simili o duplicati nella stessa lingua su URL diversi (il classico esempio.com e esempio.co.uk con lo stesso inglese) l’indicazione è scegliere una versione preferita, usare rel="canonical" e annotare con hreflang. Non serve riscrivere i testi per differenziarli.

Il redirect automatico fra versioni linguistiche è sconsigliato: la stessa guida chiede di evitare di spostare gli utenti da una versione linguistica a un’altra in base a quella che ritieni sia la loro lingua, perché quei reindirizzamenti impediscono a loro e ai motori di vedere tutte le versioni del sito. Accanto al divieto c’è il rimedio, che quasi nessuno applica: link ipertestuali alle versioni della pagina nelle altre lingue, e sceglie chi legge.

È il punto in cui i siti locale-adaptive si fanno male da soli. Per chi serve contenuti diversi in base al paese percepito o alla lingua preferita, la documentazione sulle pagine locale-adaptive raccomanda URL separati annotati con hreflang invece del contenuto dinamico sullo stesso URL, e spiega perché: Googlebot invia le richieste senza impostare l’header Accept-Language, e i suoi indirizzi IP predefiniti risultano negli Stati Uniti, anche se la scansione avviene pure da IP fuori dagli USA. Se la tua home cambia in base a quei due segnali, la versione che Googlebot vede e indicizza non è casuale: è quasi sempre quella statunitense.

Stessa pagina, una raccomandazione che di solito nessuno applica: le regole del robots.txt e i meta robots vanno tenuti coerenti fra le lingue. Bloccare /de/ seguendo la guida al robots.txt mentre annoti de in tutti i set è un modo elaborato per dichiarare un nodo e poi murarlo.

Hreflang nel 2026: risultati tradotti, traduzione automatica, Bing

Tre cose sono cambiate intorno all’hreflang mentre l’attributo restava identico a sé stesso, e cambiano il calcolo di quando conviene tradurre.

La prima: Google traduce da sé titolo e snippet dei risultati quando l’utente cerca in una lingua diversa da quella della pagina. La documentazione sui risultati tradotti, aggiornata al 20 febbraio 2026, dice che la funzione copre 21 lingue e che Google non ospita le pagine tradotte: traduce l’anteprima, il clic porta sulla tua pagina originale. Si disattiva con la regola notranslate, come meta tag o come X-Robots-Tag, e si misura col filtro dell’aspetto in Ricerca nel rapporto Prestazioni di Search Console. Non è un sostituto dell’hreflang, che continua a servire per scambiare l’URL fra versioni che esistono davvero.

La seconda riguarda chi sperava di risolvere con un plugin di traduzione automatica. Le spam policy di Google, pagina aggiornata al 19 maggio 2026, elencano la traduzione fra le trasformazioni automatiche che ricadono nell’abuso di contenuti su larga scala: «Scraping di feed, risultati di ricerca o altri contenuti allo scopo di generare molte pagine (ad esempio tramite trasformazioni automatiche come creazione di sinonimi, traduzione o altre tecniche di offuscamento) che forniscono scarso valore agli utenti». L’ultima riga è una condizione, non un contorno: a finire nel mirino è la pagina che non dà valore, non la traduzione in quanto tale. Ma annotare con hreflang trenta lingue generate in automatico non le riabilita. Il markup è corretto, il contenuto no.

La terza è Bing. Il 19 dicembre 2025 Fabrice Canel e Krishna Madhavan hanno scritto sul blog di Bing Webmaster di usare hreflang per il targeting di lingua e regione, con esempio esplicito: <link rel="alternate" hreflang="en-gb" href="https://www.example.com/uk/page/" />. Lo stesso post smonta la storia della penalizzazione per duplicati: «Il contenuto duplicato di per sé non innesca penalizzazioni nella ricerca, ma riduce la visibilità diluendo l’autorità, confondendo l’intento e rallentando la propagazione degli aggiornamenti verso i motori di ricerca e i sistemi di scoperta basati sull’AI» (traduzione mia). Il danno esiste, la sanzione no.

La checklist

Il criterio è uno: il grafo chiude?

• L’autoreferenza c’è su ogni pagina del set, comprese le foglie
• La reciprocità regge in entrambe le direzioni per ogni coppia che dichiari
• Gli URL sono assoluti, con il protocollo
• Ogni URL annotato risponde 200, non è in redirect e non è in noindex
• I codici lingua esistono davvero: niente en-UK, niente es-419, niente eng-
• C’è un catch-all di sola lingua accanto alle varianti regionali
• x-default punta a una pagina neutra o alla lingua franca del tuo pubblico
• La dichiarazione sta in un posto solo: head, header HTTP o sitemap
• Il canonical di ogni versione punta a sé stessa, nella sua lingua
• Nessun <link> combina due rel nello stesso tag
• Il set viene ricontrollato dopo migrazioni, cambi di permalink e nuove lingue

Domande frequenti