Hreflang

Hreflang è un’annotazione di targeting per lingua e regione utilizzata su pagine equivalenti in diversi mercati. Il suo compito è semplice: dire a Google che en-us, en-gb e fr-ca sono alternative, non duplicati accidentali, così possa posizionarsi l’URL giusto per l’utente giusto.

Perché è importante è ancora più semplice. Il traffico proveniente dal Paese sbagliato converte male. Se la tua pagina prodotto USA si posiziona in Canada o la tua pagina generica in inglese supera la versione tedesca locale, perdi entrate, non solo posizionamenti.

Cosa fa davvero hreflang

Hreflang è un segnale di selezione, non un potenziamento del ranking. Non fa aumentare automaticamente il posizionamento delle pagine. Aiuta Google a scegliere tra URL molto simili quando esistono più versioni.

Google lo ribadisce da anni e John Mueller di Google ha detto più volte che hreflang riguarda l’erogazione della variante corretta, non la consolidazione di tutto il valore SEO in una sola pagina. Questa distinzione conta. I team spesso propongono hreflang come soluzione al problema dei contenuti duplicati. Non lo è.

Regole di implementazione che fanno saltare la maggior parte dei setup

• Usa codici validi: en-GB, non en-UK. Prima la lingua, poi l’eventuale Paese.
• Servono le tag di ritorno: se la pagina A fa riferimento alla pagina B, la pagina B deve a sua volta fare riferimento alla pagina A.
• Fai un’auto-riferimento per ogni URL: ogni pagina deve includere la propria voce hreflang.
• Mantieni i canonicals allineati: ogni pagina regionale di solito usa come canonical se stessa, non un “master” globale.
• Includi x-default quando è utile: soprattutto per i selettori di lingua o per pagine di fallback.

Puoi implementare hreflang in HTML, nelle sitemap XML o tramite header HTTP. Nella pratica, l’opzione meno “disordinata” a livello di scala è spesso l’hreflang nelle sitemap XML. Superati i 10-20 locale, i tag nei head diventano rapidamente fragili, specialmente con template molto basati su JavaScript.

Come fare un audit fatto bene

Usa Screaming Frog per la validazione della scansione, i controlli reciproci e la verifica delle self-reference mancanti. Usa Google Search Console per monitorare variazioni a livello di Paese su query e pagine di atterraggio dopo il deployment. Usa Ahrefs o Semrush per verificare se l’URL regionale previsto sta davvero posizionandosi in ciascun mercato. Se vuoi una seconda vista tramite crawler, Moz e strumenti enterprise come Lumar possono aiutare, ma Screaming Frog di solito trova più velocemente gli errori reali dell’implementazione.

Per i team di contenuto, Surfer SEO non è uno strumento per hreflang. È utile per l’on-page, sì. Non per validare annotazioni internazionali.

Dove hreflang si inceppa

Premessa onesta: hreflang non è una soluzione magica se le tue pagine localizzate sono sottili, tradotte automaticamente o poco differenziate. Se le tue pagine en-au e en-us hanno prezzi, spedizioni, valuta e testi identici, Google potrebbe comunque ignorare la tua intenzione. Un altro problema comune: i team pubblicano hreflang perfetto su pagine che Google scansiona appena o che non indicizza. A quel punto non cambia nulla.

Inoltre, il vecchio reporting di hreflang in GSC è molto meno utile di quanto lo fosse in passato. Ti servono dati da crawler, log del server e controlli live della SERP. Non basta una spunta verde.

Lo standard pratico: mappa ogni URL equivalente, mantieni coerenti i canonicals, valida settimanalmente dopo i rilasci e monitora le sostituzioni delle landing page per mercato per 4-8 settimane. È questo che separa un setup internazionale pulito da un’implementazione “da slide”.