Lingue

Hreflang

Cos'è hreflang, i tre modi per implementarlo, le regole di reciprocità e autoreferenzialità, i codici di lingua/regione validi e come controllare i cluster su larga scala.

Prima pubblicazione: 25 giu 2026 · Ultimo aggiornamento: 3 ago 2026 · Advanced
Lingue
AIScritto daAI v2
1 segnale di evidenza in questa pagina

Hreflang dice ai motori di ricerca quale versione linguistica/regionale di una pagina mostrare a quale utente. Lo dichiari in uno dei tre modi: tag HTML nell'head, intestazioni HTTP o sitemap XML, usando i codici lingua ISO 639-1 e regione ISO 3166-1 alpha-2. Funziona solo come cluster reciproco: ogni pagina deve collegarsi a se stessa e a tutte le sue alternative, e se manca un link di ritorno, Google ignora la coppia. È un suggerimento, non una direttiva: un hreflang errato viene ignorato, non penalizzato. È anche fragile: nel mio studio su 374 756 domini che usano hreflang, oltre il 67% aveva almeno un problema. Bing lo usa a malapena (content-language è il segnale più forte lì). Questo hub spiega tutto e ti indirizza agli approfondimenti.

TL;DR — Hreflang è un segnale di cluster reciproco: ogni pagina elenca se stessa e tutti gli alternate, e un tag di ritorno mancante invalida la coppia. Dichiaralo in un solo modo — head HTML, header HTTP Link (PDF), o sitemap XML (meglio su larga scala). I codici sono lingua ISO 639-1 + regione ISO 3166-1 alpha-2; en-UK è sbagliato, è en-GB. È un suggerimento, non una direttiva (Mueller) — hreflang sbagliato viene ignorato, non penalizzato, e Google può sovrascriverlo per consolidamento della stessa lingua o motivi di indicizzazione. Si rompe costantemente: nel mio studio Ahrefs su 374 756 domini, oltre il 67 % aveva almeno un problema. Bing lo tratta come un segnale molto più debole di content-language. Fai audit dei cluster visivamente piuttosto che in fogli di calcolo.

Hreflang è un cluster, non un tag

Hreflang sits between one piece of content and the right version showing up for each market's search. Fonte: /international-seo/hreflang/

© Patrick Stox LLC · CC BY 4.0 ·

A hreflang cluster is a bidirectional graph — one missing return link breaks just that pair. Fonte: /international-seo/hreflang/

© Patrick Stox LLC · CC BY 4.0 ·

Il modello mentale che risolve la maggior parte della confusione su hreflang: non è un tag per pagina, è un grafo bidirezionale. Il requisito di Google è diretto — “Each language version must list itself as well as all other language versions,” e “if two pages don’t both point to each other, the tags will be ignored.” (traduzione) «Ogni versione linguistica deve elencare se stessa e tutte le altre versioni linguistiche» e «se due pagine non puntano entrambe l’una all’altra, i tag verranno ignorati». Quindi se la pagina X punta a Y ma Y non punta a X, quel collegamento viene silenziosamente eliminato. Un tag di ritorno mancante può far sì che le annotazioni interessate vengano ignorate o interpretate in modo errato — ma Google dice che può comunque elaborare le coppie che sono correttamente reciproche, quindi una relazione rotta non necessariamente abbatte ogni annotazione in un cluster più grande.

Evidence for this claim Each hreflang set should include the page itself, use fully qualified URLs, and include return links; without reciprocity, the affected annotations may be ignored or misinterpreted. Scope: Google Search hreflang guidelines; the documentation does not say one missing return link invalidates every annotation in a cluster. Confidence: high · Verified: Google: Localized versions guidelines

Da questo derivano due punti non negoziabili:

  • Reciprocità. Ogni riferimento deve essere restituito. È qui che le implementazioni si rompono su larga scala — nel momento in cui un template, un campo CMS o le pagine di una regione escono dalla sincronia, i link di ritorno spariscono.
  • Auto-riferimento. Ogni pagina elenca se stessa. Mueller lo chiama “optional—but good practice”; (traduzione) «opzionale, ma buona pratica»; in pratica, un set auto-referenziale è il modo più pulito per mantenere i cluster coerenti e viene segnalato come problema quando manca.

Sono richiesti anche URL assoluti e completi — https://example.com/foo, mai //example.com/foo o /foo.

Tre metodi — e i compromessi

Google tratta i tag HTML, le intestazioni HTTP e le sitemap XML come equivalenti: non c’è alcun vantaggio SEO nell’implementarne più di uno. Scegli un metodo per sito in base a ciò che il tuo stack può mantenere in modo affidabile; mescolarli invita a conflitti.

  • Tag HTML <head>. Il più semplice e visibile. Svantaggio: su un sito con decine di lingue, ogni pagina porta un grande blocco di tag <link>, aggiungendo peso al markup, e qualsiasi pagina nel <body> (da HTML malformato o iniezione JS) è non valida: l’hreflang conta solo nel <head> della pagina come Google la rende/la analizza.
  • Intestazioni HTTP Link. L’unica opzione per risorse non HTML come i PDF. Inviate nella risposta, quindi non appesantiscono il documento.
  • Sitemap XML. La scelta giusta su larga scala. Le annotazioni vivono centralmente (figli xhtml:link sotto ogni <url>, con il namespace xmlns:xhtml="http://www.w3.org/1999/xhtml"), quindi puoi rigenerare l’intero cluster da un database senza ridistribuire le pagine. Non esiste un metodo “più veloce” — sia l’HTML che le sitemap vengono risolti al momento della scansione — ma le sitemap sono molto più facili da testare perché puoi validare l’intero grafo in un unico file invece di scansionare ogni pagina.
Evidence for this claim Google accepts hreflang in HTML, HTTP headers, or XML sitemaps and says the methods are equivalent from its perspective. Scope: Google Search hreflang implementation methods. Confidence: high · Verified: Google: Localized versions

Collegamenti reciproci su larga scala: dove si rompono

In un sito con 5 lingue, si tratta di una matrice 5×5 di riferimenti per set di pagine, rigenerata ogni volta che aggiungi o rimuovi una lingua, correggi uno slug o migri un URL. Le modalità di errore sono prevedibili:

  • Formati URL incoerenti. Slash finale vs. assente, http vs. https, www vs. dominio nudo, o percorsi con maiuscole vs. minuscole: qualsiasi discrepanza tra l’URL nell’ hreflang e l’URL che Google indicizza effettivamente rompe la corrispondenza del tag di ritorno.
  • Puntamento a URL reindirizzati o rotti. Un URL di una lingua cambia, il reindirizzamento viene inserito, ma l’hreflang punta ancora al vecchio URL. Il cluster ora fa riferimento a un 301 o a un 404.
  • Deriva del codice. jp invece di ja per il giapponese, codici a tre lettere dove ne servono due, en-UK invece di en-GB. I codici non validi vengono ignorati.

Esempio di distribuzione pratico: il tag di ritorno punta all’URL di ieri

Supponiamo che la pagina prodotto del Regno Unito sia stata spostata da /gb/shoes/ a /uk/shoes/. La pagina USA non è stata rigenerata, quindi pubblica ancora:

<link rel="alternate" hreflang="en-US" href="https://shop.example/us/shoes/" />
<link rel="alternate" hreflang="en-GB" href="https://shop.example/gb/shoes/" />

Il vecchio URL del Regno Unito reindirizza a /uk/shoes/, mentre la nuova pagina del Regno Unito collega di nuovo alla pagina USA dal suo URL canonico finale. Questo lascia due problemi distinti: l’annotazione USA punta a un reindirizzamento, e l’URL finale del Regno Unito non è lo stesso URL dichiarato dalla pagina USA. Correggi il generatore in modo che entrambe le pagine pubblichino il set completo utilizzando URL finali indicizzabili:

<link rel="alternate" hreflang="en-US" href="https://shop.example/us/shoes/" />
<link rel="alternate" hreflang="en-GB" href="https://shop.example/uk/shoes/" />

Valida entrambe le direzioni dopo la distribuzione; controllare solo il tag sorgente USA non rileverebbe l’errore del tag di ritorno. Questo è un cluster .example illustrativo.

La lezione dai miei interventi alle conferenze vale ancora: automatizza la generazione dell’hreflang da un’unica fonte di verità. L’hreflang mantenuto a mano su larga scala è una garanzia di degrado dei tag di ritorno.

Conflitti di canonicalizzazione

L’hreflang dipende da ciò che è indicizzato, non da ciò che è canonicalizzato — ma i due aspetti interagiscono, e sbagliare rompe i cluster:

  • I canonical autoreferenziali sono l’impostazione predefinita sicura. Ogni versione linguistica dovrebbe puntare a se stessa. Se la tua pagina spagnola punta alla pagina inglese, stai dicendo a Google che l’URL spagnolo non è quello da indicizzare — e hreflang che punta a un URL non canonico è uno degli errori più comuni.
  • Il caso limite dello stesso linguaggio e più paesi. Quando hai, ad esempio, pagine en-us e en-gb quasi identiche, Google può consolidarle e indicizzarne una — ma può comunque scambiare l’URL visualizzato nella SERP con la versione corretta per il paese tramite i link hreflang. Quindi un URL “canonicalizzato via” può ancora apparire per l’utente giusto. Questa è una funzionalità, non un bug, ma sorprende le persone che controllano la copertura dell’indice.
  • noindex e robots.txt. Una pagina bloccata dall’indicizzazione non può partecipare a un cluster — il suo hreflang non può essere applicato, e puntare a un URL noindex/bloccato rompe il link di ritorno. Non bloccare o mettere noindex alle varianti linguistiche che vuoi servire.

È un suggerimento, non una direttiva

Questo è il quadro da interiorizzare. Nel maggio 2025 su Bluesky, John Mueller ha risposto a un caso di pagine fr-be che apparivano nei risultati fr nonostante hreflang corretto: “hreflang doesn’t guarantee indexing, so it can also just be that not all variations are indexed,” (traduzione) «hreflang non garantisce l’indicizzazione, quindi può anche essere che non tutte le varianti siano indicizzate», e “I suspect this is a ‘same language’ case where our systems just try to simplify things for sites.” (traduzione) «Sospetto che questo sia un caso di ‘stessa lingua’ in cui i nostri sistemi cercano solo di semplificare le cose per i siti». Google si riserva il diritto di sovrascrivere hreflang per consolidamento della stessa lingua, lacune di indicizzazione o proprie scelte canoniche.

Le linee guida di Google sulla canonicalizzazione sono il lato opposto: raccomandano di scegliere un canonico nella stessa lingua della pagina (o il miglior sostituto disponibile), e dicono che preferisce URL che fanno parte di un cluster hreflang reciproco completo rispetto a URL simili al di fuori di esso. Questa è una preferenza, non una promessa — essere in un cluster costruito correttamente migliora le tue probabilità che l’URL giusto venga selezionato, ma non garantisce l’indicizzazione né quale URL appare.

La conseguenza pratica: hreflang sbagliato viene ignorato, non penalizzato. Se il tuo cluster è rotto, Google ripiega sulla propria rilevazione di lingua/regione. Il costo è un’opportunità (l’URL sbagliato appare per alcuni utenti), non un colpo al ranking. Quindi “il mio hreflang è sbagliato” raramente è un’emergenza — ma raramente sta facendo qualcosa di utile.

Bing e gli altri motori usano uno stack diverso

Hreflang è un segnale di Google (e Yandex). Lo stack di segnali di Bing è completamente diverso. Fabrice Canel, Principal Program Manager di Microsoft Bing, ha detto chiaramente che “hreflang is indeed a far weaker signal than content-language at Bing.” (traduzione) «hreflang è davvero un segnale molto più debole di content-language su Bing». Bing si affida all’intestazione HTTP / meta tag content-language, all’attributo <html lang="">, ai link in entrata, alla geografia dei visitatori e alla posizione del server/ccTLD, e Canel ha sconsigliato di “duplicating URLs just to have them tagged with these language-markets” (traduzione) «duplicare URL solo per averli etichettati con questi mercati linguistici» nella maggior parte dei casi. Baidu non supporta affatto hreflang (si basa sulla posizione di hosting, sulla registrazione del dominio cinese, sulla licenza ICP e su content-language). Quindi una configurazione internazionale robusta abbina hreflang per Google a un content-language / html lang corretto per tutti gli altri.

Il tasso di errore è la storia

Over 67% of domains using hreflang have at least one issue — missing x-default is the top offender. Fonte: Data: Ahrefs

Quando ho condotto il più grande studio hreflang fino ad oggi su Ahrefs — 374 756 domini, quasi 10 volte più grande di qualsiasi studio precedente — oltre il 67% dei domini che usano hreflang aveva almeno un problema. La distribuzione:

Problema% di domini
x-default mancante56,3%
Tag autoreferenziali mancanti18,0%
Riferimento a pagine rotte/redirette16,9%
Tag reciproci mancanti15,3%
Puntamento a URL non canonici8,0%
Codici lingua/paese errati4,6%
Attributi lingua incoerenti3,2%
Più pagine per la stessa lingua2,5%
Stessa pagina per più lingue2,5%

Il riepilogo del mio studio è ancora valido: hreflang è complesso e difficile da implementare correttamente, e può rompersi in molti modi diversi.

Audit su larga scala — visualizza il cluster, non leggere un foglio di calcolo

Guarda il tuo cluster con returntag:

  1. Incolla l’URL di una pagina, l’URL di una sitemap o un elenco di URL di pagine nello strumento.
  2. Fai clic su Validate cluster.
  3. Leggi la vista GRAPH — i link di ritorno mancanti o errati risaltano per colore di gravità — oppure passa a MATRIX per una vista riga per riga, ed esporta un CSV di elenco di correzioni se devi consegnarlo a qualcun altro.

Il motivo per cui gli errori hreflang si nascondono è che un problema di tag di ritorno è una relazione tra pagine, e le relazioni sono quasi impossibili da leggere attraverso le righe di un foglio di calcolo. Ahrefs Site Audit è stato il primo strumento a rappresentare il cluster hreflang come un grafo — apri i dettagli URL di qualsiasi pagina e la scheda Hreflangs disegna l’intero cluster come una rete, con le pagine rotte e i link mancanti/errati evidenziati in rosso. Puoi vedere a colpo d’occhio quale tag di ritorno manca o quale link è stato aggiunto per errore — ed è molto più facile mostrarlo a uno stakeholder che un CSV. Site Audit esegue anche i controlli sottostanti (annotazione non valida, auto-riferimento mancante, più di una pagina per lingua, mancata corrispondenza hreflang/html lang, tag reciproco mancante, destinazione non canonica, destinazione rotta) che corrispondono direttamente all’elenco degli errori dello studio.

Oltre a questo:

  • GSC URL Inspection conferma come un singolo URL è stato indicizzato e indicizzato. Nota che il vecchio rapporto International Targeting è stato deprecato il 22 settembre 2022 — Google ha detto che “had little value for the ecosystem.” I tag hreflang stessi funzionano ancora; solo il rapporto è sparito.
  • Test manuale della SERP con i parametri &hl= (lingua host) e &gl= (geolocalizzazione) su un URL di ricerca Google ti permette di visualizzare in anteprima come appaiono i risultati per una determinata località.

Hreflang è anche una questione di audit SEO tecnico

Sebbene la casa di hreflang sia la SEO internazionale, appare in quasi ogni audit SEO tecnico di un sito multilingue o multiregionale — si trova proprio accanto ai controlli di canonicalizzazione, indicizzazione e accessibilità alla scansione, ed è uno degli elementi più probabili di essere silenziosamente rotto. Se stai eseguendo un audit tecnico e il sito ha più di una località, il cluster hreflang appartiene alla checklist.

Dove andare dopo

Questo hub è la mappa per il sottocluster hreflang. Il primo approfondimento:

  • x-default — il valore di fallback per gli utenti la cui località non corrisponde a nessuno dei tuoi tag espliciti (un selettore di paese o una homepage globale). Non è obbligatorio, ma è stata l’omissione più comune nel mio studio (56,3 % dei siti). Il sottotopico dedicato copre quando usarlo, quando saltarlo e come interagisce con il resto del cluster.

Per la strategia più ampia che questo implementa, vedi il pilastro International SEO — hreflang è il livello tecnico di una strategia internazionale; non sostituisce una vera localizzazione (intento locale, contenuto locale, autorità locale).

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.