Hreflang Tag Guida 2026: 5 Errori che Bloccano la SEO

Why Hreflang Matters for International Websites

Hreflang is an HTML attribute that tells search engines which language and regional version of a page to show to users in different locations. Without it, Google may show your English page to French users, your German page to Austrian users looking for Swiss-German content, or, in the worst case, flag your localized pages as duplicate content and deindex them entirely.

For businesses operating across multiple European markets, correct hreflang implementation is not optional. It directly impacts which version of your pages appears in local search results, which in turn affects click-through rates, user experience, and ultimately conversion. A 2025 Ahrefs study found that websites with correct hreflang implementation saw 47% higher organic traffic from non-primary markets compared to sites with incorrect or missing hreflang tags.

The Three Implementation Methods

There are three ways to implement hreflang: HTML link elements in the page head, HTTP headers, and XML sitemaps. Each has advantages depending on your technical setup.

HTML link elements are the most common method. You add a set of link tags in the head of every page, one for each language/region variant including a self-referencing tag. This is straightforward for small sites but becomes unwieldy when you have dozens of language variants.

HTTP headers are used for non-HTML resources (PDFs, for example) and can be useful when you cannot modify the HTML head. They work identically to the HTML method but are specified in the server response headers.

XML sitemaps are the best approach for large sites with many language variants. You specify hreflang annotations in your sitemap using the xhtml:link element within each URL entry. This keeps the hreflang logic centralized, makes it easier to audit, and does not add weight to your HTML pages. For sites with 5+ language variants, we strongly recommend the sitemap approach.

Here is how the three methods compare at a glance:

Mistake 1: Missing Return Links

The most common hreflang error is missing return links. Hreflang annotations must be bidirectional: if Page A declares Page B as its French variant, Page B must also declare Page A as its English variant. If either direction is missing, Google ignores both annotations.

This sounds simple but becomes complex at scale. If you have 10 language variants, every page needs 10 hreflang tags (including self-referencing), and all 10 pages must have matching annotations. That is 100 annotations that must be perfectly synchronized across 10 separate pages. One missing or mismatched annotation can break the entire chain.

The solution is to generate hreflang annotations programmatically from a single source of truth, typically a database or CMS that knows which pages are translations of each other. Never manually maintain hreflang tags across localized pages.

Mistakes 2-3: Wrong Language Codes and Missing x-default

Mistake 2: Wrong language and region codes. Hreflang uses ISO 639-1 language codes and optionally ISO 3166-1 Alpha 2 region codes. Common errors include using "uk" for Ukrainian (it should be "uk" for the language, not "ua" for the country), confusing "zh-Hans" (simplified Chinese) with "zh-CN" (Chinese for China), and using three-letter language codes (which are not supported).

For European implementations, pay attention to regional variants: "pt" (Portuguese) is different from "pt-BR" (Brazilian Portuguese). "en-GB" and "en-US" are distinct variants. If you serve different content to Austrian ("de-AT") and German ("de-DE") users, you need separate hreflang annotations for each.

Mistake 3: Missing x-default tag. The x-default hreflang value tells search engines which page to show when no other hreflang variant matches the user's language or region. Without it, Google makes its own choice, which may not be what you want. Always include an x-default that points to your language selector page or your English-language version as a fallback.

Mistakes 4-5: Canonical Conflicts and Non-200 Pages

Mistake 4: Canonical and hreflang conflicts. If a page has a canonical tag pointing to a different URL than what the hreflang annotation specifies, Google will follow the canonical and ignore the hreflang. Every page referenced in your hreflang annotations must have a self-referencing canonical tag. If your French page at /fr/product/ has a canonical pointing to /en/product/, your hreflang annotation for the French page will be silently ignored.

Mistake 5: Hreflang pointing to non-200 pages. Every URL in your hreflang annotations must return a 200 HTTP status code. If any URL returns a 301 redirect, a 404, or a 500 error, Google will ignore the hreflang annotation for that entire page set. This commonly happens during site migrations or URL structure changes when old URLs are redirected but hreflang annotations are not updated simultaneously.

To catch these issues, implement automated monitoring. Google Search Console reports hreflang errors, but with a delay. Tools like Screaming Frog, Sitebulb, or Ahrefs can crawl your site and validate hreflang annotations in real-time, catching errors before they impact your rankings.

Un Esempio Concreto: un URL, tre Lingue

La teoria è più facile da assorbire con un caso concreto. Supponi di gestire un sito e-commerce con pagine prodotto in inglese (internazionale), italiano e spagnolo. La struttura degli URL è la seguente:

• https://example.com/products/widget/ (en, x-default)
• https://example.com/it/products/widget/ (it)
• https://example.com/es/products/widget/ (es)

Ognuno di questi tre URL deve contenere un insieme completo e reciproco di annotazioni hreflang. Ecco cosa deve contenere l’head della pagina inglese:

<link rel="alternate" hreflang="en"
      href="https://example.com/products/widget/" />
<link rel="alternate" hreflang="it"
      href="https://example.com/it/products/widget/" />
<link rel="alternate" hreflang="es"
      href="https://example.com/es/products/widget/" />
<link rel="alternate" hreflang="x-default"
      href="https://example.com/products/widget/" />

La pagina italiana (/it/products/widget/) deve contenere gli stessi quattro tag, con gli stessi quattro URL, invariati. Lo stesso vale per la pagina spagnola. Tutte e tre le pagine portano l’insieme completo; l’unica cosa che cambia tra loro è il proprio canonical, che ciascuna pagina punta a se stessa. Se si omette anche un solo tag su una sola pagina, Google scarta silenziosamente l’intero cluster di annotazioni per quel prodotto.

Alcuni aspetti da tenere a mente in questo esempio. Il tag x-default e la pagina inglese condividono lo stesso URL, il pattern più comune per i siti senza una pagina dedicata alla selezione della lingua. Se hai una pagina selettore a /products/, punta l’x-default là. I codici lingua sono valori ISO 639-1 puri (en, it, es), senza qualificatori di regione. Aggiungere un qualificatore di regione (en-GB, es-MX) è giustificato solo quando servi contenuti genuinamente diversi a utenti in Paesi diversi che parlano la stessa lingua.

Come Validare l’Implementazione Hreflang

Inserire i tag nella pagina è solo metà del lavoro. Occorre verificare che Google li legga correttamente e che non si siano introdotte rotture silenziose. Ci sono tre modi pratici per farlo.

Report International Targeting di Search Console. In Search Console, vai su Strumenti e report precedenti, poi International Targeting. La scheda Lingua mostra i valori hreflang rilevati nel sito e segnala i codici lingua che Search Console non riesce ad analizzare. Il report ha un ritardo di diversi giorni, quindi usalo come audit periodico piuttosto che come verifica post-deploy. Nota importante: l’assenza di errori non conferma che Google stia agendo sui tag, solo che riesce a leggerli.

Un crawler dedicato per hreflang. Tool come Screaming Frog (Configurazione > Spider > Crawl linked XML sitemaps and hreflang), Sitebulb e JetOctopus riescono a seguire le relazioni hreflang sull’intero insieme di varianti locale in un’unica scansione. Mostrano link reciproci rotti, URL non corrispondenti tra pagine collegate e tag che puntano a redirect o 404, tutto in un unico export. Per qualsiasi sito con più di due o tre varianti locale, una scansione è l’unico modo realistico per individuare errori sistematici.

Una verifica curl rapida per un URL specifico. Quando si vuole verificare una singola pagina subito dopo il deploy, è possibile ispezionare i response header e l’head HTML senza una scansione completa:

curl -s "https://example.com/products/widget/" | grep -i hreflang

Il comando stampa tutti gli elementi link hreflang nel sorgente della pagina. Verifica che il numero corrisponda alle varianti locale attese (incluso l’x-default) e che ogni URL sia assoluto piuttosto che relativo. Gli URL relativi nelle annotazioni hreflang non sono supportati e causano l’ignoramento silenzioso del tag.

Domande Frequenti su Hreflang

Come si implementano i tag hreflang correttamente?

Dichiara hreflang in un solo posto per pagina (elementi link nell’head, header HTTP o voci nella sitemap XML) e mantieni quel metodo coerente. Ogni variante fa riferimento a tutte le altre, inclusa se stessa, e ogni riferimento deve essere reciproco. Mischiare metodi su un URL e omettere il self-reference sono le due rotture più frequenti.

Dove vanno i tag hreflang: head HTML, header HTTP o sitemap?

L’head HTML è la scelta giusta per la maggior parte dei siti con meno di una dozzina di varianti locale. Gli header HTTP sono adatti ai file non HTML come i PDF o quando non si può modificare l’head. Il metodo sitemap vince su larga scala, dove si hanno centinaia di pagine per locale e si vuole mantenere leggero il peso delle pagine. Non dichiarare mai l’hreflang della stessa URL in due posizioni diverse.

Cosa significa x-default?

x-default è il valore di fallback di hreflang. Dice ai motori di ricerca quale pagina servire quando nessuna lingua o regione corrisponde all’utente, e di solito punta a un selettore di lingua o alla versione inglese principale. Se lo si omette, Google fa una stima, il che spesso significa che la locale sbagliata appare nelle regioni non mappate.

Perché il mio hreflang non funziona?

Cinque sospetti abituali: un link non reciproco, un codice ISO sbagliato (en-UK invece di en-GB), un self-reference mancante, due metodi di dichiarazione su un URL, oppure hreflang che punta a un URL che risponde con 404 o redirect. Controlla il report International Targeting in Search Console e usa un crawler come Screaming Frog prima di concludere che Google stia ignorando i tag.

Hreflang aiuta con i contenuti duplicati tra siti di Paesi diversi?

Sì, ma in modo specifico. Hreflang non sopprime i segnali di contenuto duplicato come fa un canonical. Dice a Google che due pagine simili sono destinate a pubblici diversi e devono essere trattate come risultati separati e mirati piuttosto che come copie in competizione. Se il contenuto è sostanzialmente identico tra le varianti locale con solo piccole differenze come valuta o formati di data, le annotazioni aiutano comunque, ma una localizzazione reale produrrà sempre segnali più forti.

Quanti tag hreflang può avere una pagina?

Non esiste un limite massimo documentato da Google. I siti con 50 o più varianti locale attive usano tipicamente le sitemap XML piuttosto che gli elementi link nell’head, perché inserire così tanti link tag nell’head di ogni pagina aggiunge un peso misurabile alle risposte HTML. Se il numero di tag con il metodo head si avvicina a 20 o più, considera la migrazione al metodo sitemap, che scala a diverse centinaia di varianti locale senza nessun overhead per pagina.

Serve hreflang se le pagine sono nella stessa lingua ma per Paesi diversi?

Sì. Se servi contenuti significativamente diversi a, ad esempio, utenti britannici e australiani di lingua inglese (prezzi diversi, disponibilità prodotto, condizioni legali), hreflang con qualificatori di regione (en-GB e en-AU) dice a Google di mostrare ciascuna variante al pubblico giusto. Senza di esso, Google sceglierà la versione che considera più autorevole e la mostrerà globalmente. Le pagine che differiscono solo nell’ortografia probabilmente non giustificano il lavoro aggiuntivo; quelle con prezzi, opzioni di spedizione o note legali diverse sì.