Guida Completa all’implementazione degli Hreflang: ottimizza il tuo sito multilingua

Lavorando con grandi Brand internazionali, mi scontro spesso con problemi linguistici causati da una gestione errata dei tag hreflang.

Per questo motivo ho cercato di raggruppare i “pattern” di errore più ricorsivi e creare questa guida che vi aiuterà a riconoscere, gestire ed eliminare fino a 15 errori che causano la mancata visibilità sulle SERP delle diverse geografie.

Cos’è hreflang e perché è così importante? Breve ripasso per chi fosse alle “prime armi”.

Se gestisci un sito web multilingue, probabilmente ti sei già trovato di fronte alla sfida di far comprendere ai motori di ricerca quale versione linguistica mostrare agli utenti.

Partiamo dalle basi. Google e gli altri motori di ricerca, infatti, non riescono automaticamente a capire che URL come example.com/it/scarpe e example.com/en/shoes sono versioni della stessa pagina, ma in lingue diverse.

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

• L’attributo rel=”alternate” indica che la pagina in questione è una versione alternativa all’originale.
• L’attributo hreflang=”it-IT” (tassativamente in formato ISO 639-1) e, opzionalmente, il Paese di destinazione (in formato ISO 3166-1 Alpha 2). Nell’esempio sopra riportato, quindi stiamo indicando “italiano, Italia”.
• L’attributo href è la URL esatta della versione in lingua.

L‘hreflang è un hint, non una direttiva. Google lo usa insieme ad altri segnali (lingua del contenuto, ccTLD, link, comportamento utenti) per decidere quale URL mostrare. Implementarlo correttamente non aumenta magicamente il traffico: serve a far vedere la pagina giusta all’utente giusto, riducendo bounce rate, contenuti duplicati cross-lingua e dispersione di segnali.

Se l’hreflang è un suggerimento per i motori di ricerca, mi serve davvero?

La risposta in breve: “Assolutamente sì” – altrimenti perché starei scrivendo una guida, non trovi?

Ecco perché ti serve (davvero!)

1. Eviti il consolidamento errato dei duplicati: due pagine in inglese quasi identiche (en-GB ed en-US) senza hreflang rischiano di essere “filtrate”: Google ne sceglie una come rappresentativa e la mostra ovunque, anche nel mercato sbagliato. Nota bene: non è una penalizzazione – termine spesso abusato da moltissimi consulenti – ma un consolidamento/canonicalizzazione che ti fa perdere visibilità locale.
2. Migliori l’esperienza utente: un utente spagnolo che atterra sulla versione tedesca abbandona in pochi secondi.
3. Proteggi il brand: per le ricerche branded, l’hreflang assicura che ogni Paese veda la propria homepage localizzata.

Vuoi un esempio “dal vivo”? Apri il sorgente della homepage di Apple.com: nella sezione HTML <head> troverai una lista lunghissima di tag hreflang, uno per ogni combinazione lingua-Paese servita. Se lo fa Apple su scala globale, un motivo c’è.

Cosa cambia con le risposte generative fornite grazie ad AI Overview e AI Mode?

In pratica, nel 2026 l’hreflang lavora su due fronti:

1. SERP classica: mostra la versione giusta al Paese giusto (funzione storica).
2. Visibilità generativa: assicura che la versione localizzata sia quella indicizzata e “citabile” dai sistemi AI di quel mercato. Contenuti realmente localizzati (non tradotti automaticamente) hanno più probabilità di essere ripresi, perché rispondono agli intenti e al lessico locale.

Questo rende ancora più centrale la differenza tra tradurre e localizzare (ne parlo nelle FAQ).

Hreflang vs Canonical: fratelli, non gemelli

Questa è la confusione numero uno che incontro nelle consulenze, quindi merita una sezione dedicata.

• Il rel=canonical dice a Google: “tra queste pagine simili nella stessa lingua, indicizza questa”.
• L’hreflang dice a Google: “queste pagine sono versioni legittime dello stesso contenuto per lingue/mercati diversi: non sono duplicati, mostrale ciascuna al suo pubblico”.

I due segnali convivono e devono essere coerenti:

<!-- Pagina: https://example.com/it/scarpe -->
<link rel="canonical" href="https://example.com/it/scarpe" />  <!-- canonical autoreferenziale -->
<link rel="alternate" hreflang="it-IT" href="https://example.com/it/scarpe" />
<link rel="alternate" hreflang="en-GB" href="https://example.com/en-gb/shoes" />

Regola d’oro: ogni versione linguistica deve avere il canonical verso sé stessa. Se la pagina IT ha un canonical verso la pagina EN, stai dicendo ai Google di “indicizzare solo la versione EN”; a quel punto l’hreflang viene ignorato, perché la versione IT per Google “non esiste” più.

Un caso reale che vedo spessissimo: implementazione hreflang perfetta, ma Google in Search Console segnala “Google ha scelto un canonical diverso” e indicizza la versione /en/ per tutti i Paesi. Nel 90% dei casi la causa è contenuto troppo simile tra le versioni (traduzioni automatiche non revisionate) o segnali interni incoerenti (link interni, sitemap, redirect geolocalizzati) che spingono verso una sola versione.

Come implementare i tag Hreflang: la strategia SEO vincente

La domanda sorge spontanea: come faccio ad implementare i tag hreflang? È meglio implementarli nel codice HTML delle pagine o nella sitemap XML? Esistono altri metodi?

Implementazione HTML nel tag <head> della Pagina

PRO:

• Scansione immediata: Googlebot (e gli altri bot dei motori di ricerca) legge questi tag immediatamente durante la fase di crawling della pagina.
• Relazioni precise: garantisce maggiore precisione nella definizione delle relazioni tra le diverse versioni linguistiche.
• Gestione semplificata: risulta più pratico da gestire per siti con un numero limitato di lingue o pagine.

CONTRO:

• Manutenzione complessa oltre le 100 pagine o con più di 10 lingue (ogni tag aggiunto va replicato su tutte le versioni).
• Deve essere presente su ogni singola pagina per tutto il sito, appesantendone il codice e influenzando così il tempo di caricamento.

Esempio concreto di come implementare correttamente i tag hreflang nel <head> delle tue pagine, che potete trovare sulla guida di Google Developer relativa agli hreflang

<head>
  <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>

Implementazione nella Sitemap XML

PRO:

• Ideale per siti complessi: particolarmente consigliato per portali con numerose pagine e multiple varianti linguistiche. È l’unico metodo davvero scalabile.
• Comprensione rapida: facilita ai motori di ricerca la comprensione dell’intera struttura multilingua.
• Gestione centralizzata: Permette un controllo centralizzato quando si ha a che fare con grandi volumi di contenuti, in quanto si avrebbe un solo file (o set di file) da mantenere.
• Tempo di caricamento: non appesantisce l’HTML delle pagine.

CONTRO:

• Richiede sitemap XML ben strutturata e rigenerata a ogni pubblicazione/traduzione.
• Il debugging è meno immediato rispetto al tag on-page.

Esempio concreto di come implementare correttamente i tag hreflang nella sitemap xml, che potete trovare sulla guida di Google Developer relativa agli hreflang

<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>

Nota per i siti a copertura linguistica parziale (domanda che mi fanno spessissimo sia i clienti che le agenzie di sviluppo): se una pagina esiste solo in 3 lingue su 8 come bisogna procere? In questo caso, il cluster hreflang di quella pagina deve includere solo le 3 versioni esistenti. Mai inserire URL di pagine non tradotte, inesistenti o in 404: è uno dei modi più rapidi per far ignorare l’intero cluster.

Implementazione attraverso HTTP Header (solo per file non-HTML)

Questo metodo va usato solamente per PDF, documenti e altri file non-HTML che non possono “beneficiare” del tag <head>.

Esempio concreto di come implementare correttamente i tag hreflang usando gli header HTTP con chiamate in GET, che potete trovare sulla guida di Google Developer relativa agli hreflang

Link: <https://example.com/it/doc.pdf>; rel="alternate"; hreflang="it-IT", <https://example.com/en/doc.pdf>; rel="alternate"; hreflang="en-GB", <https://example.com/de/doc.pdf>; rel="alternate"; hreflang="de-DE"

Tutto molto bello, fino a qui ho capito le differenze, ma quale metodo devo scegliere?

Spero ti stia chiedendo quale sia il giusto metodo per implementare questi tag (significherebbe che sei riuscito ad arrivare fino a qui vivo con la lettura). Ebbene, qui vi do un consiglio diverso da quello che leggerai altrove (e diverso da quello che davo anch’io in passato): scegli UN metodo principale e mantienilo coerente. Qualora il tuo sito lo permettesse potresti usarli anche tutti insieme, sempre che siano – come appena detto – coerenti fra loro. Google non ha mai dichiarato ufficialmente una priorità tra HTML e sitemap in caso di conflitto; quello che è certo è che segnali contrastanti tra i due metodi sono una delle cause più comuni di hreflang ignorati.

La mia regola pratica:

• Sito fino a 100 pagine / poche lingue → tag HTML nel <head>.
• E-commerce o portali grandi con più di 5 lingue → sitemap XML.
• File non-HTML → header HTTP (questo è da aggiungere sempre rispetto ai primi due, perché copre risorse diverse).

Se usi sia i metodi HTML e sitemap XML (alcuni CMS lo fanno di default), verifica con un crawl che i due set siano identici al 100%: in caso contrario, disattivane uno.

E l’implementazione via Google Tag Manager posso farla? (Spoiler: no)

Troverai guide che spiegano come iniettare gli hreflang via GTM o JavaScript. Sconsiglio fortemente questo approccio: i tag iniettati client-side sono visibili solo dopo il rendering, Google potrebbe processarli in ritardo o non processarli affatto, e altri motori/crawler (che non renderizzano JS, come Bing) non li vedranno mai. Se il tuo stack è headless/React/Vue, assicurati che gli hreflang siano presenti nell’HTML servito dal server (SSR o pre-rendering), non aggiunti dal browser. GTM va benissimo per il tracking; per i segnali SEO strutturali, no.

Quali sono le giuste coppie lingua-Paese? Codici Lingua-Regione (ISO 639-1 + ISO 3166-1)

Mercato	Codice	Best scenario URL
🇮🇹 Italiano (Italia)	it-IT	/it/
🇨🇭 Italiano (Svizzera)	it-CH	/it-ch/
🇬🇧 Inglese (UK)	en-GB	/en-gb/
🇺🇸 Inglese (USA)	en-US	/en-us/ o /us/
🇩🇪 Tedesco (Germania)	de-DE	/de/
🇦🇹 Tedesco (Austria)	de-AT	/de-at/ o /at/
🇫🇷 Francese (Francia)	fr-FR	/fr/
🇪🇸 Spagnolo (Spagna)	es-ES	/es/
🇲🇽 Spagnolo (Messico)	es-MX	/es-mx/ o /mx/
🌐 Globale (fallback)	x-default	/en/

Questa tabella è un’idea di come implementare al meglio gli hreflang, prima di cimentarvi con le versioni linguistiche, vi invito a salvarvi tra i preferiti l’elenco completo dei codici ISO Country Code.

Regole di sintassi da imparare a memoria:

• Lingua: sempre ISO 639-1 (due lettere: en, non eng).
• Regione: sempre ISO 3166-1 Alpha 2, ed è opzionale: en da solo è valido, GB da solo no.
• Separatore: trattino (en-GB), mai underscore.
• Macro-regioni: esiste un livello intermedio poco conosciuto, i codici regionali UN M49 come es-419 (spagnolo per l’intera America Latina). Utilissimo quando non vuoi/puoi creare una versione per ogni singolo Paese sudamericano.

Come Google sceglie la versione da mostrare (logica di fallback)?

Capire il matching ti evita metà degli errori strategici. Immaginaniamo questo caso, un utente con browser in en-AU (inglese, Australia):

1. Google cerca una corrispondenza esatta en-AU → se non esiste,
2. cerca la versione generica en → se non esiste,
3. cerca un’altra variante della stessa lingua (en-GB o en-US) → se non esiste,
4. serve l’x-default.

Morale: includi sempre una versione generica di lingua (en oltre a en-GB ed en-US) se servi più mercati con la stessa lingua. Cattura tutti gli utenti anglofoni dei Paesi che non hai targettizzato esplicitamente.

Cos’è il tag x-default?

Ti sei accorto che negli esempi sopra avevo inserito anche un’ultima istruzione X-default, vero? Spero di sì e spero che non sei tornato su apposta a controllare! Ebbene questa è un’istruzione molto utile, è il fallback universale, da usare quando:

• Nessuna lingua dell’utente corrisponde a quelle impostate come traduzione/localizzazione
• L’utente proviene da Paesi non targettizzati
• Google non riesce a determinare in automatico la lingua del contenuto

Come scegliere la giusta lingua da inserire come x-default?

Esistono delle best practice che consiglio sempre, in generale l’x-default dovrebbe essere basato su:

• Lingua dominante del business (nel 90% dei casi: la versione inglese, o quella del mercato principale)
• Il selettore lingua (Language selector o Language Gate): se hai più di 10 lingue, l’x-default può puntare a una pagina di selezione lingua (come fanno molti brand globali con la “mappa del mondo” cliccabile).
• L’x-default può coincidere con una versione già dichiarata: è perfettamente lecito che en e x-default puntino allo stesso URL.

Best Practices per l’implementazione corretta dei tag hreflang

Per massimizzare l’efficacia dei tag hreflang, assicurati di seguire queste linee guida fondamentali:

1. Auto-riferimento: ogni pagina include anche il tag verso sé stessa.
2. Reciprocità: Verifica che i tag siano reciproci – ogni versione linguistica deve rimandare a tutte le altre versioni disponibili. Se IT linka EN ma EN non linka IT, il cluster è rotto.
3. Versione predefinita: Utilizza sempre l’attributo x-default per indicare quale versione del sito mostrare come fallback, quando nessuna delle lingue specificate corrisponde alle preferenze dell’utente.
4. Canonical autoreferenziale su ogni versione (vedi sezione dedicata sopra).
5. URL finali, assoluti, con status 200: niente redirect, niente URL relativi, niente pagine noindex o bloccate da robots.txt dentro i cluster hreflang.
6. Coerenza tra segnali: hreflang, canonical, sitemap, link interni e <html lang=""> devono raccontare la stessa storia.

Troubleshooting: 15 errori più comuni che devi evitare

Errore #1: Hreflang non reciproco

Sintomo: I tool di crawl (come Screaming Frog) segnalano “missing return tag / tag di ritorno mancante“.

Diagnosi:

Pagina IT → linka EN ✅
Pagina EN → NON linka IT ❌

Fix: Assicurati che TUTTE le pagine linkino TUTTE le altre versioni (e sé stesse).

Errore #2: URL canonicalizzato diverso da hreflang

Sintomo: Google ignora completamente gli hreflang e/o sceglie un canonical diverso da quello dichiarato.

Esempio SBAGLIATO:

<!-- Pagina: https://example.com/it/scarpe -->
<link rel="canonical" href="https://example.com/en/shoes" />  <!-- ❌ canonical verso altra lingua -->
<link rel="alternate" hreflang="it-IT" href="https://example.com/it/scarpe" />

Fix: Canonical deve puntare a se stessa, non a versione in altra lingua

<link rel="canonical" href="https://example.com/it/scarpe" />  <!-- ✅ -->

Errore #3: Codici lingua/regione errati

Esempi comuni sbagliati:

<!-- ❌ -->
<link rel="alternate" hreflang="eng" href="..." />  <!-- Bisogna usare "en" "eng" -->
<link rel="alternate" hreflang="UK" href="..." />  <!-- Doppio errore: la regione da sola è invalida, e "uk" come lingua significa ucraino! Il codice Paese del Regno Unito è GB -->
<link rel="alternate" hreflang="en-UK" href="..." />  <!-- Bisogna usare "en-GB" e non "en-UK" -->
<link rel="alternate" hreflang="en-ww" href="..." />  <!-- "ww" non esiste: per la versione internazionale usa "en" da solo -->
<link rel="alternate" hreflang="en_GB" href="..." />  <!-- Underscore invalido: usa il trattino -->

Riporto di seguito un errore sugli hreflang riscontrato durante un audit di un sito che ho gestito (ho dovuto oscurare il Brand per ovvi motivi).

Errore #4: Catena redirect nell’hreflang

Problema:

hreflang → https://example.com/it/scarpe (301→) https://example.com/it/scarpe/

Conseguenza: Google (a differenza di altri motori di ricerca) può seguire il redirect, ma il cluster risulta più debole e può essere ignorato.

Fix: Hreflang deve puntare alla URL finale in status 200 (dopo il redirect).

<!-- ✅ CORRETTO -->
<link rel="alternate" hreflang="it-IT" href="https://example.com/it/scarpe/" />

Errore #5: Hreflang su pagine 404, noindex o bloccate da robots.txt

Diagnostica: crawla tutte le URL presenti nei cluster hreflang e verifica status code 200, assenza di noindex, robots.txt permissivo.

Tool: Screaming Frog SEO Spider → tab Hreflang

Errore #6: Stesso contenuto, lingue diverse, nessun hreflang né x-default

Problema: Google vede versioni quasi identiche → le consolida scegliendone una sola da mostrare ovunque.

Fix: Implementa hreflang per dire a Google “sono versioni legittime” e imposta correttamente l’x-default come fallback.

Errore #7: Mancanza del tag autorefenziale

<!-- ❌ SBAGLIATO: manca it-IT autoreferenziale -->
<link rel="alternate" hreflang="en-GB" href="https://example.com/en-gb/running-shoes" />
<link rel="alternate" hreflang="en-US" href="https://example.com/en-us/running-shoes" />

<!-- ✅ CORRETTO: includere sempre se stessa -->
<link rel="alternate" hreflang="it-IT" href="https://example.com/it/scarpe-running" />
<link rel="alternate" hreflang="en-GB" href="https://example.com/en-gb/running-shoes" />
<link rel="alternate" hreflang="en-US" href="https://example.com/en-us/running-shoes" />

Errori #8-15: Quick Error List

#Errore	Descrizione errore	Fix rapido
8	Hreflang iniettato via JavaScript/GTM	Servili nell’HTML statico (SSR/pre-rendering) o via header HTTP
9	Hreflang solo su homepage	Aggiungili su TUTTE le pagine con equivalenti localizzati
10	Conflitto fra Sitemap XML e tag HTML	Allinea i due set al 100% o usa un solo metodo
11	URL parametrici negli hreflang	Usa URL puliti e assoluti (no ?lang=it)
12	Versione mobile separata senza hreflang	Implementa anche su m.example.com (o meglio: passa al responsive)
13	Encoding UTF-8 mancante	Inserisci <meta charset="UTF-8"> nell’head
14	Attributo lang mancante o errato	Usa <html lang="it"> sul tag html e, per Bing, <meta http-equiv="content-language" content="it-it">
15	Hreflang dimenticati su PDF e risorse non-HTML	Usare gli headers HTTP per tutti i tipi di file non-HTML

Quali strumenti puoi utilizzare per il testing e la validazione degli hreflang?

⚠️ Prima un avviso importante: molte guide (anche recenti!) consigliano ancora il report “Targeting internazionale” di Google Search Console. Quel report non esiste più: Google lo ha deprecato nell’agosto 2022 e rimosso a settembre 2022, insieme alla funzione di country targeting (qui il comunicato ufficiale). Search Console oggi non offre più un report dedicato agli errori hreflang. Se una guida te lo consiglia, è un ottimo segnale che non è aggiornata!

Tool essenziali (aggiornati al 2026)

1. Screaming Frog SEO Spider (il mio punto di partenza)

• Crawl sito → tab Hreflang: verifica automatica di reciprocità, self-reference, codici invalidi, URL non indicizzabili nei cluster. (la foto sopra mostrava esattamente come vengono mostrati gli errori sugli hreflang in Screaming Frog).
• Export report errori

2. Hreflang Tags Testing Tool (Aleyda Solis)

• URL: https://www.aleydasolis.com/english/international-seo-tools/hreflang-tags-testing-tool/
• Input: URL della pagina
• Output: Errori specifici + fix suggeriti. Perfetto per spot-check veloci.
• PS: se non sai chi sia Aleyda Solis, ti consiglio di rimediare SUBITO!

3. Site Audit di Semrush / Ahrefs

Entrambi i tool includono check hreflang ricorrenti: utili per il monitoraggio continuo su progetti grandi.

Semrush

Ahrefs

4. Google Search Console (uso indiretto)

Anche senza il vecchio report, GSC resta preziosa per misurare gli effetti:

• Rendimento → filtro per Paese: la versione IT riceve impression/click dalla Germania? Segnale di cluster rotto.
• Indicizzazione pagine: “Google ha scelto un canonical diverso” sulle versioni localizzate = quasi sempre un problema hreflang/canonical/contenuto troppo simile.
• Controllo URL: verifica come Google vede la singola pagina renderizzata (fondamentale per stack JavaScript).
• ⚠️ Nota: i dati monitorati spesso sono ritardati di 2-7 giorni.

5. Validatore custom (da buon Nerd vi riporto uno script in Python che ho creato e che potete usare)

# Script base per validare reciprocità e self-reference hreflang
import requests
from bs4 import BeautifulSoup

def validate_hreflang(url):
    headers = {"User-Agent": "Mozilla/5.0 (hreflang-validator)"}
    response = requests.get(url, headers=headers, timeout=10)
    soup = BeautifulSoup(response.text, 'html.parser')
    hreflangs = soup.find_all('link', {'rel': 'alternate'})

    # Check 1: Self-reference
    self_ref = any(h.get('href') == url for h in hreflangs)
    if not self_ref:
        print(f"⚠️  {url} non ha il tag autoreferenziale")

    # Check 2: Reciprocità
    for h in hreflangs:
        alt_url = h.get('href')
        if not alt_url or alt_url == url:
            continue
        alt_response = requests.get(alt_url, headers=headers, timeout=10)
        if alt_response.status_code != 200:
            print(f"❌ {alt_url} risponde {alt_response.status_code} (deve essere 200)")
            continue
        alt_soup = BeautifulSoup(alt_response.text, 'html.parser')
        reciprocal = any(link.get('href') == url
                         for link in alt_soup.find_all('link', {'rel': 'alternate'}))
        if not reciprocal:
            print(f"❌ {alt_url} non linka reciprocamente a {url}")

    return True

validate_hreflang("https://example.com/it/scarpe")

Come misurare se l’hreflang sta funzionando (monitoraggio post-implementazione)

Implementare non basta: bisogna verificare l’effetto.

Ecco Iìil mio processo standard, da avviare 2-4 settimane dopo il rilascio:

1. GSC Rendimento, segmentato per Paese: per ogni versione linguistica, controlla da quali Paesi arrivano impression e click. Red flag: la versione /it/ che riceve impression significative da UK o Germania.
2. Query branded per geografia: cerca il tuo brand dai vari mercati (VPN o strumenti di SERP localizzata, come l’estensione di Google Chrome “Nightwatch”): ogni Paese deve vedere la propria homepage.
3. “Wrong-country impressions” nel tempo: costruisci un piccolo report che traccia la % di impression di ogni versione provenienti dal Paese sbagliato: se l’hreflang funziona, questa metrica scende progressivamente.
4. Report indicizzazione: cala il numero di pagine in “Duplicato, Google ha scelto un canonical diverso”? Ottimo segnale.

Hreflang e gli altri motori di ricerca: la tabella che nessun’altro ti dà

L’hreflang non è uno standard universale. Ecco il quadro reale nel 2026:

Motore	Supporta hreflang	Cosa usare?
Google	✅ Pieno	hreflang (HTML, sitemap o header HTTP)
Yandex	✅ Supportato	hreflang, incluso x-default. Enfasi sulla segmentazione geografica CIS.
Bing	⚠️ Segnale molto debole*	<meta http-equiv="content-language"> + geo-targeting in Bing Webmaster Tools
Yahoo	⚠️ Segue Bing	Come Bing
Baidu	❌ Non supportato	content-language (targeting solo su lingua cinese) + meta tag baidu-site-verification.
Naver	❌ Non supportato	Usa meta language tag.

*Precisazione importante su Bing: non è corretto dire che “non supporta” l’hreflang. L’ex Principal Product Manager di Bing Fabrice Canal ha chiarito che l’hreflang è un segnale molto più debole rispetto al content-language. Quindi tienilo pure, ma affianca sempre il meta tag content-language e configura il geo-targeting in Bing Webmaster Tools. Non sai come fare? Ecco una fantastica guida su come funziona Bing Webmaster Tool.

Cosa mi chiedono più spesso i colleghi SEO o i clienti?

L’hreflang serve ancora nell’era delle AI Overviews?

Risposta breve: sì, più di prima. Le AI Overviews e l’AI Mode di Google sono localizzate per mercato e lingua: attingono dall’indice di Google della specifica geografia. Se i tuoi segnali di localizzazione sono rotti e Google consolida tutto sulla versione inglese, le risposte generative nei mercati locali citeranno i competitor localizzati, non te.

I tag Hreflang influiscono sul ranking?

No, direttamente no: l’hreflang non è un fattore di ranking. Ma indirettamente sì: serve il contenuto giusto da mostrare sulle SERP giuste, perché riduce il bounce rate; di conseguenza migliora la UX e a sua volta incrementa le performance del sito, e quindi viene aumentato il ranking (“che al mercato mio padre comprò” [cit. spero non per pochi]).

Quanto tempo deve passare prima che Google riconosca i tag hreflang?

In media 2-4 settimane, in funzione della frequenza di crawl del sito. Per accelerare vi consiglio di implementare i tag in sitemap XML e richiedere l’indicizzazione via Search Console della stessa, poi usa Controllo URL sulle pagine principali.

Posso usare l’implementazione HTML e quella via Sitemap XML?

Sì, anzi è consigliato, ma solo se i due set sono perfettamente identici. Google non ha mai dichiarato una priorità ufficiale in caso di conflitto, e segnali contrastanti sono una causa frequente di hreflang ignorati. Il mio consiglio aggiornato: un solo metodo principale, mantenuto in modo impeccabile.

Serve hreflang tra versione .it e versione .com?

Dipende dal contesto: se il contenuto è equivalente ma su domini diversi, sì (l’hreflang funziona tranquillamente cross-domain). Se il contenuto è totalmente diverso, no: in quel caso lavora sui canonical e sull’architettura.

Hreflang funziona su Bing?

Sni, vedi la sezione sopra.

Cosa devo fare se ho più di 50 lingue?

E chi sei Amazon?!. In tal caso comunque utilizza il metodo via sitemap XML in quanto è l’unico modo scalabile. Prima di lavorare sugli hreflang, ti consiglio fortemente di prioritizzare le versioni linguistice per mercati che davvero ti portano traffico e revenue.

Gli errori hreflang rilevati su Screaming Frog/ Semrush e altri tool simili impattano negativamente la SEO?

Generalmente no in senso “punitivo” (i tag invalidi vengono semplicemente ignorati), ma perdi l’opportunità di intercettare traffico internazionale: che poi è il motivo per cui li hai implementati.

Come gestisco le varianti della stessa lingua? (es: es-ES vs es-MX)

Se il contenuto differisce davvero (lessico, valuta, disponibilità prodotti: pensa a “coger” in Spagna vs Messico…), crea versioni separate con i rispettivi codici. Se non hai risorse per versioni per-Paese, valuta il livello intermedio es-419 per l’intera America Latina, oppure un solo es generico.

Non ho una versione in una lingua su cui voglio espandere la mia visibilità, devo tradurre i contenuti attuali?

No! Devi localizzare: creare contenuti basati su keyword research locale, lessico, usi e intenti di quel Paese. La traduzione pura (soprattutto quella automatica non revisionata) produce contenuti “thin” che Google riconosce e che difficilmente si posizionano, e che i sistemi AI difficilmente citano.

Serve sempre l’Hreflang?

No. Non serve se il sito è monolingua (in quel caso imposta comunque <html lang=""> corretto e, volendo, un x-default autoreferenziale). Non serve tra contenuti completamente diversi (lì lavora sui canonical). Non serve, ovviamente, se hai una sola versione per lingua senza varianti geografiche: basta il codice lingua semplice.

Nel caso di domini con estensioni diverse (esempio .it, .de, .fr, .co.uk, ecc), ma con gli stessi contenuti come mi comporto?

L’hreflang funziona perfettamente cross-domain: inseriscilo su TUTTE le pagine equivalenti tra i vari ccTLD. Anzi, con i ccTLD è ancora più importante, perché ogni dominio compete “da solo” senza il supporto degli altri.

Come devo implementare i tag hreflang nel mio CMS?

Ci sono diversi metodi, provo a darti un quadro generale:

• WordPress: WPML e Polylang collegano automaticamente le traduzioni e generano i tag hreflang; in alternativa Yoast SEO e Rank Math offrono campi dedicati per gli URL alternativi. Se sei uno “smanettone” come il sottoscritto, lavori nel PHP del file functions.
• Shopify: con Shopify Markets gli hreflang vengono generati nativamente per i mercati configurati; app come Weglot o Langify li gestiscono per setup più complessi;
• Magento / Adobe Commerce: lcontrariamente a quanto si legge in giro, non genera hreflang out-of-the-box: servono estensioni dedicate (es. Amasty, Mageworx) o sviluppo custom sulle store view.