Guida: Hreflang SEO nell’architettura internazionale

Home » Guide » Guida: Hreflang SEO nell’architettura internazionale

La Guida Tecnica che Decide se il tuo sito Esiste all’estero

Se hai letto il mio articolo su perché tradurre il sito non basta per espandere un’azienda in Spagna, saprai già che la localizzazione semantica è solo metà del lavoro. L’altra metà — quella invisibile, ma spesso decisiva — è l’architettura tecnica internazionale. E al centro di questa architettura c’è un attributo che, se implementato male, può far sparire la tua versione per l’estero dall’indice di Google: hreflang.

Come ho scritto nell’articolo, il 75% dei siti multilingua presenta configurazioni errate di tag hreflang, un dato che frammenta l’autorità di posizionamento tra le versioni linguistiche e vanifica mesi di lavoro editoriale. In questo articolo entriamo nel dettaglio tecnico: cosa è hreflang nella SEO, come implementarlo correttamente e quali errori evitare per non sabotare, silenziosamente, la tua espansione nei mercati esteri.

Cos’è Hreflang e Perché non è un Dettaglio Tecnico Secondario

Hreflang è un attributo che indica a Google quale versione linguistica e geografica di una pagina mostrare a un determinato utente, in base alla lingua del browser e alla localizzazione geografica. Non è un fattore di ranking diretto, ma un segnale di indirizzamento: senza di esso, Google può decidere autonomamente quale URL mostrare in ciascun mercato, spesso sbagliando.

Per un’azienda italiana che pubblica contenuti sia in /it/ che in /es/, questo significa una cosa molto concreta: se Google.es continua a mostrare la pagina italiana a un utente spagnolo, la versione localizzata — per quanto ben scritta — resta invisibile.

La sintassi corretta richiede due componenti:

Codice lingua (ISO 639-1): es, it, fr, en.
Codice regione (ISO 3166-1, opzionale ma consigliato in B2B): ES, IT, MX, AR.

La differenza tra hreflang=”es” e hreflang=”es-ES” non è cosmetica: la prima indica “spagnolo generico”, la seconda “spagnolo di Spagna”, distinzione cruciale se l’azienda vuole distinguere il mercato spagnolo da quello latinoamericano.

Esistono casi in cui usare il codice regione è controproducente. Vediamo piú avanti quali.

I Tre Metodi di Implementazione Internazionale

Hreflang può essere implementato in tre modi su un sito web, e la scelta dipende dalla struttura del sito.

Tag nell’head HTML. Il metodo più comune per siti WordPress: ogni pagina localizzata riporta nel proprio <head> un link rel=”alternate” hreflang=”…” per ogni versione linguistica disponibile, incluso il riferimento a se stessa (self-referencing).

Esempio nel codice sul TAG HTML:

2.Sitemap XML. Preferibile su siti B2B di grandi dimensioni con centinaia di landing page di servizio, perché centralizza le relazioni tra URL senza appesantire il codice di ogni pagina.

3.Header HTTP. Indispensabile per risorse non-HTML come PDF, whitepaper o case study scaricabili, contenuti che sono un asset di trust fondamentale nel B2B spagnolo e che spesso vengono dimenticati nell’implementazione hreflang.

Le Tre Regole Che il 75% dei Siti Viola

Dall’analisi di decine di migrazioni internazionali, e dai progetti SEO che ho liderato, ho pututo constatare che gli errori si concentrano quasi sempre in tre punti.

Reciprocità obbligatoria. Se la pagina italiana punta alla versione spagnola con hreflang, la pagina spagnola deve puntare indietro a quella italiana. Un riferimento a senso unico viene ignorato da Google: l’intera implementazione diventa inefficace.
Autoreferenzialità. Ogni pagina deve includere un hreflang che punta a se stessa, oltre ai riferimenti alle altre versioni. È un dettaglio che molti plugin di traduzione automatica omettono, generando incongruenze silenziose.
Coerenza con il canonical. Questo è l’errore che causa il danno più grave: se la pagina spagnola ha un tag canonical che punta alla versione italiana, Google la tratta come contenuto duplicato ed esclude la variante spagnola dall’indice regionale. L’azienda crede di “essere online in Spagna”, ma per Google.es quella pagina, in lingua spagnola, semplicemente non esiste.

La regola tecnica è inderogabile: ogni pagina localizzata deve avere un canonical autoreferenziale abbinato a hreflang reciproci, mai un canonical che punta a un’altra lingua.

Cannibalizzazione Internazionale: il Costo Nascosto di un Hreflang Mancante

Quando .it e .es competono per la stessa query senza un geotargeting corretto, non vince nessuna delle due: entrambe perdono posizioni, perché Google percepisce ambiguità sul contenuto “autorevole” da mostrare. È un errore tecnico molto comune, che ho osservato in vari progetti multilingua: le pagine non ottimizzate, o senza etichetta hreflang corretta possono essere scansionate ma non indicizzate — un segnale che Google ha “deciso” di non considerarle rilevanti per la loro lingua.

Hreflang e x-default: la Rete di Sicurezza per gli Utenti non Mappati

Oltre ai codici lingua/regione, esiste un valore speciale: hreflang=”x-default”. Serve a indicare quale versione mostrare a utenti la cui lingua o area geografica non corrisponde a nessuna delle varianti disponibili — tipicamente una landing page di selezione lingua o la versione internazionale in inglese. Per un’azienda B2B che si espande progressivamente (prima Spagna, poi magari Francia o LATAM), x-default evita che nuovi mercati non ancora localizzati vengano indirizzati in modo casuale. Se per esempio, vogliamo raggiungere tutto il pubblico che parla inglese nativo, ma non è geolocalizzato in una nazione specifica, useremo “x-default” nella versione inglese. Per esempio:

Checklist di Validazione internazionale dei Tag hreflang

Prima di considerare chiusa l’implementazione, verifica sempre:

Sitemap aggiornata ogni volta che si pubblica una nuova pagina localizzata, se si usa questo metodo di implementazione.
Crawler tecnici (Screaming Frog o equivalenti) per mappare automaticamente tutte le relazioni hreflang del sito.
Coerenza canonical/hreflang su un campione di URL di ogni versione linguistica, non solo sulla homepage.

Hreflang Checker: Strumenti Online per Validarlo

Oltre a Google Search Console e crawler avanzati come Screaming Frog, esistono diversi strumenti online gratuiti pensati per validare hreflang senza competenze tecniche avanzate:

SISTRIX Hreflang Validator — fino a 25 verifiche gratuite al giorno, controlla che Google interpreti correttamente l’orientamento geografico delle pagine.
Aleyda’s Hreflang Tags Generator (hreflang.pro) — riferimento storico per generare e validare rapidamente il markup su singole pagine, molto usato dalla community SEO internazionale .
Merkle/DEG Hreflang Tags Testing Tool e Swetrix Hreflang Checker — analisi più completa: autoreferenzialità, reciprocità, presenza di x-default, codici lingua validi secondo lo standard BCP 47 e conflitti con il tag canonical .
seo·matrix — verifica automatica degli stessi errori comuni descritti in questa guida, con report immediato .
Hreflang Checker Pro (estensione Chrome) — legge il DOM della pagina in tempo reale senza inviare dati a server esterni, utile per controlli spot durante il lavoro su singoli progetti client .
Controllo manuale rapido — da Chrome DevTools, cercando “hreflang” nel codice sorgente della pagina, oppure in Search Console nella sezione Pagine → Escluse, dove Google segnala errori come “Pagina alternativa senza lingua corrispondente

Language targeting: Scegliere la Strategia Corretta

L’implementazione corretta dell’etichettatura internazionale dipende dagli obiettivi del progetto, o meglio da dove si trova il nostro target, non da uno schema fisso da applicare a prescindere. Ci sono casi specifici su cui ho lavorato come consulente SEO Internazionale, che richiedono un’attenzione particolare a come si configura hreflang. Per esempio, se l’obiettivo è raggiungere un pubblico straniero che cerca un determinato servizio pur trovandosi fisicamente in un altro paese, la scelta giusta è il language targeting: mostrare il contenuto in una determinata lingua, indipendentemente dal contesto geografico dell’utente.

Un esempio pratico di come aplicare l’etichetta corretta.

Ho lavorato al progetto di una professionista che offre servizi sanitari alla comunità italiana residente a Barcellona. In questo caso la versione italiana del sito deve usare solo il codice lingua it, senza il codice paese IT — quindi hreflang=”it” e non hreflang=”it-IT”. Google interpreta it-IT come “italiano per utenti in Italia”, un segnale di geotargeting che rischia di escludere proprio gli utenti italiani che cercano dalla Spagna, che è invece il pubblico reale del sito.

Omettendo il codice paese, il sito comunica a Google: “questa pagina è per chiunque cerchi in italiano, ovunque si trovi” — la configurazione corretta per raggiungere una comunità expa, turisti, o un pubblico che vive stabilmente fuori dal proprio paese d’origine.

In sintesi: usa lingua-PAESE (es. es-ES, it-IT) quando il contenuto è specifico per un mercato geografico definito; usa solo lingua (es. es, it) quando l’obiettivo è raggiungere tutti i parlanti di quella lingua, a prescindere da dove si trovino — come nel caso di servizi pensati per una comunità di expat o di connazionali all’estero.

Nessuno sforzo editoriale compensa un’architettura tecnica scorretta — ma è vero anche il contrario: un hreflang perfetto su contenuti tradotti senza localizzazione semantica non genera comunque lead qualificati. Sono due pilastri della stessa strategia di SEO internazionale.

Se stai pianificando l’espansione della tua azienda all’estero e vuoi verificare che l’infrastruttura tecnica del tuo sito non stia già sabotando i risultati, scopri come la mia consulenza puó aiutarti.

Contattami

FAQ: Hreflang

Devo mettere hreflang su una pagina che non ha traduzione in altre lingue?

No. Se non esiste una versione alternativa reale di quella pagina, non va inserito nessun tag hreflang, né sulla pagina stessa né come riferimento dalle altre versioni linguistiche. Aggiungere hreflang “per abitudine” verso una lingua che non esiste in quella sezione del sito è un errore tecnico.

Cosa succede se il mio hreflang punta a una pagina che non esiste o restituisce un 404?

Google ignora quel riferimento e, se l’errore è sistematico, il report di validazione segnalerà annotazioni non corrispondenti. È comune in siti B2B che traducono solo le pagine di prodotto principali ma lasciano hreflang “fantasma” verso URL mai create. La soluzione è sempre rimuovere il tag, non forzare un collegamento verso un contenuto inesistente.

Come gestisco gli utenti la cui lingua non corrisponde a nessuna versione disponibile del sito?

Si usa hreflang="x-default", un valore che indica a Google quale pagina mostrare quando nessuna delle varianti linguistiche esistenti corrisponde alle preferenze dell’utente .

Se pubblico una pagina non ancora tradotta dentro la cartella /es/, che codice hreflang devo usare?

In teoria, l’hreflang deve sempre descrivere la lingua reale del testo (it), non la cartella dell’URL (/es/). Tuttavia, pubblicare contenuto non tradotto in una cartella estera è fortemente sconsigliato nella pratica SEO: genera contenuto duplicato rispetto alla versione italiana originale e rischia di creare conflitti con il tag canonical (se il canonical punta alla versione /it/, Google ignora gli hreflang della pagina /es/; se punta a se stessa, invii segnali ambigui). La best practice è non pubblicare l’URL nella cartella /es/ finché la traduzione non è pronta, oppure mantenerlo temporaneamente escluso dall’indicizzazione e dai cluster hreflang.

Come posso convalidare l’implementazione hreflang in Google Search Console?

Dal 2022 non esiste più un report hreflang dedicato in Search Console: la convalida si effettua pagina per pagina con lo strumento Controllo URL, cliccando su “Test live” e poi su “Dettagli avanzati”, dove Google elenca i tag hreflang effettivamente rilevati nel codice. Per un audit tecnico su scala globale su tutto il sito, è necessario affidarsi a crawler SEO esterni come Screaming Frog, Sitebulb, SISTRIX, Ahrefs o Semrush, incrociandone i dati con lo stato di indicizzazione delle pagine.

Come gestisco l’hreflang in WordPress?

Con un plugin (soluzione standard): Utilizza strumenti come WPML, Polylang o TranslatePress. Collegano automaticamente le versioni tradotte e generano tag hreflang bidirezionali corretti (incluso x-default), evitando conflitti con i tag canonical dei plugin SEO.
Metodo manuale (per siti custom o Multisite): Puoi iniettare i tag <link rel="alternate"> nel codice tramite l’hook PHP wp_head (nel file functions.php o con un Code Snippet), accertandoti che appaiano solo sulle pagine con traduzioni reali. In alternativa, per non appesantire l’HTML, puoi dichiarare gli attributi xhtml:link direttamente nella Sitemap XML.