Hreflang: cos'è, come implementarlo e come verificarlo

immagine di un ecommerce in lingua italiana visualizzato su un cellulare. Due frecce indicano le rispettive traduzioni in inglese e francese

Se gestisci un sito o un eCommerce in più lingue, prima o poi ti sei imbattuto nell’attributo hreflang. È il modo con cui dici a Google: «questa pagina esiste anche in inglese, in tedesco, in francese — mostra quella giusta alla persona giusta».

La maggior parte delle guide su hreflang si ferma alla teoria. Questa parte da un punto diverso: come verifichi che gli hreflang del tuo sito ci siano davvero e funzionino.

Perché nella nostra esperienza il problema quasi mai è non sapere cosa sia hreflang. Il problema è credere di averlo implementato quando non è così.

Ci siamo passati anche noi, su questo stesso sito, a luglio 2026: 1.619 pagine in due lingue, il plugin configurato correttamente da anni, e gli hreflang spariti dall'<head> senza che nessuno se ne fosse accorto. Ti raccontiamo come l’abbiamo scoperto e come si risolve.

Cos’è il tag hreflang e a cosa serve

L’hreflang è un’annotazione che indica a un motore di ricerca la lingua e, se serve, l’area geografica a cui è destinata una pagina web. Serve a due cose:

Mostrare la versione giusta all’utente giusto. Chi cerca in tedesco dalla Germania deve atterrare sulla pagina tedesca, non su quella italiana.
Evitare che le traduzioni vengano lette come contenuti duplicati. Se hai la stessa scheda prodotto in inglese su tre URL diversi per Stati Uniti, Regno Unito e Australia, le differenze possono essere minime: valuta, spedizioni, taglie. Senza hreflang, Google potrebbe trattarle come duplicati e sceglierne una sola.

Con hreflang dichiari in modo esplicito che si tratta dello stesso contenuto, ottimizzato per pubblici diversi.

Un esempio concreto di quando serve davvero: un’azienda che vende in Francia e in Canada francofono.

Stessa lingua, ma metodi di pagamento, valuta e tempi di spedizione completamente diversi. Servono due pagine, e serve un modo per dire a Google quale mostrare a chi.

Hreflang e attributo lang non sono la stessa cosa

È una confusione frequente. L’attributo lang sul tag <html> dichiara in che lingua è scritta quella pagina: serve ai browser, agli screen reader e all’accessibilità.

L’attributo hreflang invece mette in relazione pagine diverse tra loro.

Servono entrambi e non si sostituiscono a vicenda. Se cerchi informazioni su html lang SEO, tieni presente questa distinzione: il lang da solo non risolve nulla in ottica multilingua.

Come verificare se il tuo sito ha gli hreflang

Questa è la parte che nella maggior parte delle guide manca, ed è quella da cui ti conviene partire.

Prima di studiare la sintassi, guarda cosa c’è già sul tuo sito: molto spesso la sorpresa è dietro l’angolo.

Il controllo manuale, in trenta secondi

Apri una pagina qualsiasi del tuo sito e premi Ctrl+U (Cmd+Option+U su Mac) per vedere il codice sorgente. Poi Ctrl+F e cerca hreflang.

Quello che devi trovare, dentro l'<head>, è una serie di righe fatte così:

Tre elementi da controllare: sono <link rel=”alternate”>, stanno nell'<head>, e gli URL puntano alla traduzione di quella specifica pagina.

La trappola del selettore di lingua

Qui casca l’asino, ed è successo anche a noi.

Il selettore di lingua del tuo sito — le bandierine IT / EN nel menu — genera link che contengono anche loro l’attributo hreflang. Con WPML sono fatti così:

Questi non sono gli hreflang SEO. Sono link di navigazione. Puntano alla home di ciascuna lingua, non alla versione corrispondente della pagina che stai guardando, e Google non li usa per associare fra loro le traduzioni.

Il risultato è insidioso: fai Ctrl+F, trovi la parola hreflang due o tre volte, concludi «ci sono» e passi oltre. Invece non c’è niente.

Come distinguerli in un colpo d’occhio: gli hreflang veri iniziano con <link rel=”alternate” e stanno nell'<head>. Quelli del selettore iniziano con <a href e stanno nel <body>, spesso con una classe tipo wpml-ls-link o simili.

Gli strumenti per il check

Se il controllo a mano ti sembra macchinoso, ci sono strumenti che fanno il lavoro per te:

hreflang Tags Testing Tool di Dentsu — incolli un URL e ti dice cosa trova, sia nella pagina sia nella sitemap XML.
Hreflang Tag Checker — estensione Chrome. Legge gli hreflang della pagina che stai visitando e verifica che si rimandino correttamente a vicenda. È il modo più rapido per un controllo al volo.
Generatore di tag hreflang di Aleyda Solis — utile in fase di implementazione, per generare il markup corretto senza sbagliare i codici.
Screaming Frog — ha una scheda dedicata agli hreflang. È l’opzione giusta quando devi controllare un sito intero e non una pagina sola.

Perché in Search Console non trovi più il report hreflang

Se stai cercando gli errori hreflang dentro Google Search Console, fermati: non ci sono più.

Il rapporto Targeting internazionale, che dal 2014 segnalava gli errori hreflang di tutto il sito e permetteva di impostare un paese di destinazione, è stato dichiarato deprecato da Google il 24 agosto 2022 e rimosso il 22 settembre 2022.

Google ha spiegato che il targeting manuale per paese aveva poco valore per l’ecosistema, e ha confermato che continua a supportare e usare gli hreflang.

Tradotto in pratica: Google usa ancora i tuoi hreflang, ma non ti dice più se sono sbagliati. Il controllo è passato interamente dalla tua parte.

Ti restano lo strumento di controllo URL di Search Console per la singola pagina, e un crawler per il sito intero.

Molte guide in circolazione — anche recenti — rimandano ancora a quel rapporto. Se ne trovi una che lo fa, sai che non è aggiornata.

Verificare tutto il sito, non una pagina sola

Controllare una pagina a campione ti dice se il meccanismo funziona in generale.

Non ti dice se funziona ovunque, e i buchi si annidano proprio nei casi particolari: archivi, tassonomie, pagine tradotte a metà, contenuti pubblicati solo in una lingua.

Su questo sito abbiamo affrontato il problema con un crawler che estrae gli hreflang dall'<head> di ogni pagina e li archivia.

Il risultato sulle 1.619 pagine: 4.854 annotazioni hreflang, tre valori (it, en, x-default), copertura completa.

Le uniche tre anomalie erano tutte legittime — una pagina da cancellare, un archivio esistente solo in italiano, una voce di glossario esistente solo in inglese.

Questo tipo di verifica sistematica è parte di quello che facciamo in un audit SEO tecnico: non «gli hreflang ci sono», ma «gli hreflang ci sono su tutte le pagine, puntano a URL validi e si rimandano a vicenda».

La sintassi corretta di hreflang

La forma base di un tag hreflang è questa:

Tre attributi, tutti obbligatori:

rel=”alternate” — dichiara che si tratta di una versione alternativa
hreflang — il codice lingua, eventualmente con il codice paese
href — l’URL assoluto e completo della versione alternativa

Tre regole che non ammettono eccezioni:

Reciprocità. Se la pagina A punta alla B, la B deve puntare alla A. Se manca il rimando, Google ignora l’intera annotazione. È l’errore più comune in assoluto.
Autoreferenzialità. Ogni pagina deve includere un hreflang che punta a sé stessa. Sembra ridondante, ma è richiesto.
URL assoluti e canonici. Niente percorsi relativi, niente URL che finiscono in redirect o in 404. L’URL nell’hreflang deve coincidere con quello dichiarato nel rel=”canonical” di quella pagina.

Quest’ultimo punto merita attenzione: hreflang e canonical devono raccontare la stessa storia.

Se la pagina italiana ha un canonical che punta alla versione inglese e contemporaneamente un hreflang che la dichiara italiana, stai mandando due segnali opposti. Il canonical di ogni pagina deve puntare a sé stessa.

Codici lingua e paese: quali usare e quali no

Il valore dell’attributo hreflang è composto da un codice lingua obbligatorio e da un codice paese facoltativo:

Lingua: due lettere, formato ISO 639-1. Esempi: it, en, de, fr, es.
Paese: due lettere, formato ISO 3166-1 Alpha 2. Esempi: IT, GB, US, CH.

Si scrivono uniti da un trattino: en-GB, de-AT, es-MX.

Attenzione ai codici che sembrano giusti e non lo sono. Lo spagnolo è es, non sp.

L’inglese britannico è en-GB, non en-UK (UK non è un codice ISO). Il giapponese è ja, non jp. Un codice non valido non genera un errore visibile: semplicemente l’annotazione viene ignorata, in silenzio.

Altre due regole meno note: non puoi indicare solo il paese — hreflang=”us” non significa «Stati Uniti», verrebbe letto come un codice lingua inesistente. E non esistono codici per i continenti: non puoi targettizzare «l’Europa».

Il valore x-default

x-default è un valore speciale che indica dove mandare un utente quando nessuna delle lingue dichiarate corrisponde alle sue impostazioni:

Tipicamente si usa per la pagina di selezione della lingua, oppure per la versione principale o internazionale del sito.

Non è obbligatorio, ma è fortemente consigliato: senza, un utente che cerca in una lingua che non hai previsto viene lasciato alla scelta di Google.

Una nota terminologica: x-default va scritto esattamente così, in inglese. È un valore letterale del codice, non un termine da tradurre.

Non essere troppo specifico

Un consiglio che si rivela utile più spesso di quanto ci si aspetti: usa il codice paese solo se hai davvero contenuti diversi per quel paese.

Immagina un sito con tre versioni in tedesco: Germania, Svizzera, Austria. La tentazione è dichiarare de-DE, de-CH, de-AT. Ma cosa succede a chi cerca in tedesco dal Belgio? Nessuna delle tre corrisponde.

Se la versione tedesca «generale» va bene per tutti i germanofoni non coperti dagli altri casi, dichiarala semplicemente come de. I motori di ricerca abbinano sempre dal più specifico al meno specifico, quindi chi cerca dalla Svizzera continuerà a ricevere de-CH, e tutti gli altri avranno una risposta sensata.

Nella maggior parte dei casi, specificare solo la lingua è la scelta più robusta.

I tre modi per implementare hreflang

Google supporta ufficialmente tre collocazioni. Sono equivalenti come validità: devi sceglierne una e usare solo quella, perché dichiarazioni contraddittorie in posti diversi creano conflitti.

1. Tag link nell’head HTML

Il metodo più diffuso e più facile da verificare. Si aggiungono i tag <link> nell'<head> di ogni pagina:

Il limite: ogni pagina deve elencare tutte le lingue. Con venti lingue significa venti righe per pagina, circa 1,5 KB in più su ogni caricamento, e altrettante query al database che il CMS deve eseguire per generarle.

Su siti molto grandi diventa un costo reale in termini di prestazioni e di crawl budget.

Fino a quattro o cinque lingue, però, è la scelta migliore: è la più semplice da controllare, e ogni strumento di analisi la legge.

2. Header HTTP

Serve per i contenuti che non sono HTML e nei quali quindi non puoi inserire un tag: PDF, documenti, immagini.

Link: <https://www.esempio.it/documento.pdf>; rel=”alternate”; hreflang=”it”,
<https://www.esempio.it/en/document.pdf>; rel=”alternate”; hreflang=”en”

Ha lo stesso problema di peso del metodo precedente, spostato però su ogni singola richiesta HTTP.

3. Sitemap XML

Le annotazioni si mettono nella sitemap, usando l’elemento xhtml:link. Per un solo URL con due lingue alternative:

<url>
<loc>https://www.esempio.it/pagina/</loc>
<xhtml:link rel=”alternate” hreflang=”it” href=”https://www.esempio.it/pagina/” />
<xhtml:link rel=”alternate” hreflang=”en” href=”https://www.esempio.it/en/page/” />
</url>

Il vantaggio è che non appesantisci le pagine e modifichi un file solo invece di tutto il sito. Lo svantaggio è la verificabilità: gli hreflang in sitemap non si vedono guardando la pagina, molti strumenti non li controllano, e se un domani cambi la gestione delle sitemap rischi di perderli senza accorgertene.

È esattamente il motivo per cui, su un sito di dimensioni normali, noi consigliamo l’<head>: quello che si vede si controlla.

Hreflang su WordPress: WPML e Polylang

Su WordPress non scrivi gli hreflang a mano: li genera il plugin multilingua. I due più diffusi sono WPML e Polylang, ed entrambi li producono automaticamente per ogni contenuto tradotto.

Automaticamente, però, non vuol dire per sempre.

Cosa può succedere con WPML (il caso che abbiamo vissuto)

A luglio 2026, controllando il nostro sito, abbiamo trovato l'<head> senza hreflang. WPML era configurato correttamente, le traduzioni collegate, nessun errore da nessuna parte.

Il motivo: a partire da WPML SEO 2.2.2 il comportamento predefinito è cambiato. Gli hreflang vengono generati nelle sitemap XML invece che nell'<head>, per una ragione ragionevole — alleggerire l'<head> sui siti con molte lingue e molte pagine.

Formalmente non è un errore: come abbiamo visto, la sitemap è una collocazione valida. Ma in pratica significa che i tuoi hreflang diventano invisibili a quasi tutti gli strumenti di analisi, alle estensioni del browser e a chiunque faccia un controllo a occhio.

E se un aggiornamento del plugin fa un giro strano, non te ne accorgi.

Come riportarli nell’head:

Vai su WPML → Lingue (in inglese: Languages)
Scorri fino alla sezione SEO Options (Opzioni SEO)
Attiva «Display alternative languages in the HEAD section» (Mostra lingue alternative nella sezione HEAD)
Salva

Se compare anche l’opzione «Position of hreflang link», lasciala sul valore predefinito. Se il tema o un altro plugin genera link di lingua sbagliati, il valore «Later in the head section» risolve il conflitto: è il piano B, non la prima scelta.

Polylang

Polylang inserisce gli hreflang nell'<head> di default e non richiede configurazioni particolari.

Le verifiche da fare sono le stesse: che le traduzioni siano effettivamente collegate fra loro nel pannello di Polylang, e che i contenuti pubblicati in una lingua sola non generino annotazioni orfane.

Il passaggio che quasi tutti dimenticano: la cache

Hai attivato l’opzione, ricarichi la pagina, fai Ctrl+U, e non è cambiato niente. Panico.

Non è il plugin: è la cache. Con WP Rocket, o con la cache dell’hosting, o con una CDN davanti, il sito continua a servire la copia statica generata prima della modifica — quella senza hreflang. Finché non svuoti la cache, il cambiamento non esiste.

WP Rocket: Impostazioni → Svuota e precarica la cache
Svuota anche la cache dell’hosting (Kinsta, SiteGround, Aruba, quello che usi)
Se hai una CDN, svuota anche quella

Regola generale, valida ben oltre gli hreflang: dopo ogni modifica all'<head> — hreflang, dati strutturati, meta tag — svuota la cache prima di verificare. Altrimenti stai guardando il passato e traendo conclusioni sbagliate.

Gli errori più comuni con gli hreflang

Dalla nostra esperienza sui progetti multilingua, in ordine di frequenza:

Mancanza di reciprocità. La pagina italiana punta a quella inglese, ma l’inglese non ricambia. Google scarta l’intera annotazione. Succede tipicamente quando una traduzione viene creata in un secondo momento o scollegata per errore nel CMS.
Manca l’autoreferenziale. Ogni pagina deve dichiarare anche sé stessa. Sembra inutile, non lo è.
Codici sbagliati. sp per lo spagnolo, en-UK per il Regno Unito, jp per il giapponese. Tutti errati, tutti silenziosi.
URL che non rispondono 200. Hreflang che puntano a pagine in redirect, in 404, o bloccate da noindex. L’annotazione punta al nulla.
Conflitto con il canonical. Hreflang e canonical che indicano cose diverse. Il canonical vince, e il lavoro sugli hreflang è sprecato.
Manca x-default. Non è un errore formale, ma lasci scoperti tutti gli utenti che non rientrano nelle lingue dichiarate.
Dichiarazioni in più posti contemporaneamente. Head e sitemap insieme, magari generati da due plugin diversi che non si parlano. È il caso peggiore, perché sembra che ci sia più copertura mentre in realtà c’è un conflitto.
Manutenzione dimenticata. Cancelli una pagina e non aggiorni le sue controparti; sposti un URL e gli hreflang delle altre lingue continuano a puntare al vecchio indirizzo.

Su quest’ultimo punto: gli hreflang non sono un lavoro che si fa una volta.

Ogni volta che cancelli o reindirizzi una pagina, le sue controparti nelle altre lingue vanno aggiornate. Su un sito che pubblica con regolarità, la deriva è inevitabile senza un controllo periodico.

Hreflang e SEO internazionale: quando serve e quando no

Ti serve hreflang se:

Hai lo stesso contenuto in più lingue
Hai contenuti nella stessa lingua ma destinati a paesi diversi (prezzi, valuta, spedizioni, normative)
Hai una pagina di selezione della lingua all’ingresso del sito

Non ti serve se:

Il sito è in una lingua sola
Hai tradotto solo qualche pagina isolata senza una struttura multilingua coerente
Le versioni sono contenuti diversi, non traduzioni dello stesso contenuto

Una precisazione che vale la pena fare: hreflang non è un fattore di posizionamento. Non fa salire una pagina in classifica.

Fa in modo che, a parità di posizione, venga mostrata la versione corretta. È un lavoro di igiene tecnica, non di crescita.

Questo significa anche che gli hreflang, da soli, non risolvono un progetto internazionale.

Sono un tassello di una strategia SEO internazionale che comprende la struttura degli URL, la ricerca di parole chiave per ciascun mercato — che non è la traduzione delle keyword italiane — e contenuti scritti per quel pubblico, non tradotti meccanicamente.

Su questo ultimo punto insistiamo sempre con i clienti: una traduzione automatica pubblicata senza revisione produce pagine grammaticalmente corrette e strategicamente inutili, perché ignorano come le persone cercano davvero in quella lingua.

Se stai valutando un’espansione internazionale, il lavoro di un’agenzia SEO internazionale comincia proprio da lì.

Domande frequenti

Hreflang cosa sono?

Gli hreflang sono annotazioni che indicano ai motori di ricerca la lingua e l’eventuale paese di destinazione di una pagina web.

Si inseriscono nell'<head> HTML, negli header HTTP o nella sitemap XML, e servono a far corrispondere ogni versione linguistica di un contenuto con il pubblico giusto, evitando che le traduzioni vengano lette come contenuti duplicati.

Cos’è il tag hreflang?

È un tag HTML nella forma <link rel=”alternate” hreflang=”it” href=”…” /> che segnala a Google la lingua e, facoltativamente, il paese a cui è destinata una pagina.

Il suo scopo è mostrare all’utente la versione corretta del contenuto ed evitare problemi di contenuto duplicato sui siti multilingua.

Come si scrive correttamente il tag hreflang?

La sintassi è <link rel=”alternate” hreflang=”it” href=”https://esempio.it/pagina/” />.

Il valore dell’attributo è un codice lingua ISO 639-1 di due lettere (it, en, de), eventualmente seguito da un trattino e da un codice paese ISO 3166-1 Alpha 2 (en-GB, fr-CA). L’URL deve essere assoluto e canonico.

A cosa serve hreflang nella SEO?

Serve a due cose: mostrare a ogni utente la versione della pagina nella sua lingua e per il suo mercato, migliorando l’esperienza d’uso; ed evitare che versioni molto simili in lingue o mercati diversi vengano interpretate come contenuti duplicati.

Non è un fattore di posizionamento: non fa salire in classifica, fa mostrare la pagina giusta.

Come si implementa hreflang su WordPress con WPML o Polylang?

Entrambi i plugin generano gli hreflang automaticamente per i contenuti tradotti.

Con WPML va però verificata l’opzione «Display alternative languages in the HEAD section» in WPML → Lingue → SEO Options: dalla versione 2.2.2 di WPML SEO il comportamento predefinito sposta gli hreflang nelle sitemap XML anziché nell'<head>. Dopo ogni modifica va svuotata la cache.

Cosa significa il messaggio «il tuo sito non ha tag hreflang»?

È un avviso generato da strumenti come Screaming Frog o Semrush quando su un sito multilingua non vengono trovate annotazioni hreflang.

Prima di allarmarti, verifica dove le sta cercando lo strumento: se gli hreflang sono nella sitemap XML anziché nell'<head>, alcuni strumenti li segnalano come mancanti pur essendo presenti e validi.

Come verificare se gli hreflang sono implementati correttamente?

Per una singola pagina: Ctrl+U e cerca <link rel=”alternate” nell'<head>, oppure usa l’estensione Chrome Hreflang Tag Checker.

Per l’intero sito serve un crawler come Screaming Frog. Attenzione: il rapporto Targeting internazionale di Google Search Console, che segnalava gli errori hreflang, è stato rimosso nel settembre 2022.

Qual è la differenza tra hreflang per lingua e per paese?

hreflang=”en” si rivolge a tutti gli utenti di lingua inglese, ovunque si trovino. hreflang=”en-GB” si rivolge specificamente a chi cerca in inglese dal Regno Unito.

Usa il codice paese solo se hai contenuti realmente diversi per quel mercato: se non li hai, il codice lingua da solo è più efficace e copre più utenti.

Gli hreflang funzionano anche su Bing?

Sì, Bing supporta gli hreflang, anche se storicamente attribuisce peso anche ad altri segnali per determinare la lingua di una pagina.

Yandex li supporta a sua volta. L’implementazione corretta per Google resta comunque valida per gli altri motori.

In sintesi

Gli hreflang sono un lavoro tecnico, non strategico: non fanno crescere il traffico, evitano che il traffico finisca sulla pagina sbagliata.

Sono però uno di quei lavori che quando manca si paga, e che si degrada silenziosamente nel tempo.

Tre cose da portarti via:

Verifica prima di studiare. Guarda cosa c’è già sul tuo sito con Ctrl+U, facendo attenzione a non confondere gli hreflang veri con i link del selettore di lingua.
Scegli una collocazione sola e, se il sito ha poche lingue, scegli l'<head>: è quella che puoi controllare.
Rimetti in calendario il controllo. Ogni pagina cancellata o spostata può rompere una coppia di hreflang, e da settembre 2022 Google non te lo segnala più.

Se hai un sito multilingua e non sai in che stato siano i tuoi hreflang, è esattamente il genere di verifica che facciamo in apertura di ogni audit SEO tecnico.

Se invece stai valutando un percorso più ampio, la nostra consulenza SEO per aziende parte sempre da qui: capire cosa c’è, prima di decidere cosa aggiungere.

Per approfondire la documentazione ufficiale: Versioni localizzate delle pagine su Google Search Central.

Sviluppo SEO per Ecommerce: articoli correlati

Ti consiglio di leggere anche questi articoli:

Hreflang: cos’è, come implementarlo e come verificare che funzioni