Hreflang in WordPress: configurazione e verifica con WPML e Polylang

WPML e Polylang possono generare automaticamente i tag hreflang, ma la loro presenza nel codice non prova che Google riesca a usare correttamente le versioni tradotte. Un URL in redirect, un canonical verso la lingua sbagliata o una traduzione non collegata possono rendere inutili annotazioni apparentemente corrette.

Per verificare hreflang WordPress serve quindi un controllo su più livelli: markup HTML, reciprocità tra le pagine, stato degli URL, canonical, sitemap e indicizzazione. Search Console non dispone più di un report hreflang dedicato: la verifica va fatta combinando gli strumenti disponibili.

Hreflang in WordPress: quando usarlo e cosa deve essere corretto

hreflang aiuta Google a identificare le versioni linguistiche o regionali alternative di una pagina e a proporre quella più adatta all’utente. Non obbliga Google a indicizzare un URL, non garantisce il posizionamento e non sostituisce un contenuto realmente tradotto.

Usalo quando esistono URL distinti per contenuti in lingue diverse o per varianti regionali con differenze effettive, per esempio offerte, spedizioni, valuta, aspetti legali o riferimenti commerciali locali. Le versioni non dovrebbero dipendere solo da cookie, IP o intestazione Accept-Language: ogni variante deve avere un URL raggiungibile direttamente.

Le sottocartelle, come example.com/en/, i sottodomini e i domini distinti sono tutte strutture possibili. Dal punto di vista dell’implementazione, conta soprattutto che gli URL siano stabili, accessibili e coerenti.

Le regole di un set hreflang valido

Ogni pagina inclusa nel set deve dichiarare sé stessa e le traduzioni pertinenti. Inoltre, se la pagina A indica la pagina B, B deve indicare A: questa reciprocità permette a Google di confermare la relazione.

Per una coppia italiano/inglese, entrambe le pagine dovrebbero contenere un set equivalente nel tag :

Gli URL devono essere assoluti, completi di protocollo HTTPS e dominio. Evita URL relativi, pagine di staging, slug precedenti e tag inseriti nel body. In WordPress, WPML e Polylang normalmente producono queste annotazioni nel frontend: non aggiungere un secondo plugin hreflang senza prima verificare l’output esistente, altrimenti potresti duplicare o contraddire i tag.

Locale WordPress, lang e hreflang non sono la stessa cosa

Il locale di WordPress identifica file di traduzione e impostazioni locali; l’attributo HTML lang descrive la lingua del documento; hreflang identifica la lingua o il mercato della variante collegata. Sono concetti correlati, ma usano notazioni diverse.

Usa codici lingua ISO 639-1, come it, en e fr, e aggiungi una regione ISO 3166-1 Alpha-2 solo se esiste un targeting concreto. en-UK non è corretto: per il Regno Unito si usa en-GB. Anche un Paese da solo, come IT o US, non è un valore hreflang valido.

Prima dei tag: canonical, indicizzazione e URL devono essere coerenti

Hreflang funziona bene solo se gli URL dichiarati sono pagine autonome e indicizzabili. Per traduzioni effettive, la configurazione ordinaria è un canonical autoreferenziale: la pagina italiana canonica verso sé stessa e la pagina inglese verso sé stessa.

Una pagina inglese con canonical verso quella italiana comunica invece che l’URL inglese è una copia da consolidare. Il segnale entra in conflitto con l’annotazione che la presenta come variante linguistica indipendente. Google considera canonical e redirect segnali più forti della presenza in sitemap.

Controlla in particolare questi casi:

• un URL presente in hreflang restituisce un redirect, un 404 o un errore 5xx;
• la pagina alternativa ha un meta robots noindex;
• canonical, link interni e sitemap puntano a URL diversi dalla variante dichiarata;
• un redirect basato su browser o IP forza sistematicamente l’utente verso un’altra lingua.

Non usare noindex per risolvere presunti duplicati tra traduzioni: una traduzione autonoma deve poter essere indicizzata. I redirect per lingua del browser possono migliorare l’esperienza utente in casi limitati, ma non devono impedire l’accesso diretto a ogni URL. Un selettore lingua/Paese chiaro è spesso una scelta più sicura.

Le annotazioni possono essere pubblicate nell’HTML, nell’header HTTP o nella sitemap XML. Non è necessario usare tutti i metodi insieme. In un sito WordPress, l’HTML nel head è in genere la soluzione più semplice; la sitemap deve comunque elencare URL finali e indicizzabili. Se anche la sitemap contiene annotazioni hreflang, deve riportare lo stesso set dell’HTML.

Configurare e controllare hreflang con WPML

WPML inserisce automaticamente gli hreflang nel head delle pagine tradotte. Prima di intervenire manualmente, verifica che ogni contenuto abbia una traduzione effettivamente associata: il plugin può generare relazioni corrette solo se le pagine sono collegate nel sistema di traduzione.

Il valore del targeting linguistico o regionale si controlla in WPML → Settings → Languages → Edit language → hreflang. Verifica che corrisponda al pubblico della variante: non trasformare una pagina inglese generica in en-US soltanto per ragioni SEO.

Dopo modifiche a domini, slug, struttura URL o plugin SEO, aggiorna WPML e le sue integrazioni, quindi ricontrolla sorgente e sitemap. WPML supporta sottodirectory, domini distinti e parametri URL; questi ultimi sono in genere meno puliti e meno adatti a una gestione SEO ordinata.

Controlla soprattutto che non rimangano URL precedenti nel markup. Un cambio di dominio o di struttura può lasciare riferimenti a vecchie destinazioni in sitemap, canonical o collegamenti interni. La documentazione di WPML sugli hreflang e quella sulle strutture URL sono utili per verificare le impostazioni del plugin.

Configurare e controllare hreflang con Polylang

Polylang genera automaticamente gli attributi hreflang nel head quando le pagine sono riconosciute come traduzioni collegate. Nella configurazione della lingua, non confondere nome visualizzato, locale, codice lingua e direzione del testo: incidono su aspetti diversi del sito.

Il plugin può convertire nell’output la notazione del locale con underscore, per esempio en_ZA, nella forma hreflang con trattino en-ZA. Il controllo da fare rimane lo stesso: apri il sorgente della pagina pubblicata e verifica il valore effettivamente emesso.

Presta particolare attenzione al cambio del codice lingua negli URL. Modificare una struttura come /fr/ in /fr-ca/ può produrre pagine non trovate se non viene accompagnato da una mappa degli URL e da redirect 301. Dopo il cambio, controlla canonical, sitemap, link interni e annotazioni hreflang.

x-default è un fallback facoltativo per utenti che non corrispondono alle varianti dichiarate. Ha senso per un selettore neutro lingua/Paese o per una home internazionale scelta deliberatamente. Non va aggiunto in automatico a ogni pagina, né deve puntare a una traduzione casuale. Per approfondire i campi lingua e l’output, consulta la documentazione Polylang sulla configurazione delle lingue e sugli attributi hreflang.

Verifica hreflang passo per passo: dal sorgente a Search Console

1. Controlla il sorgente HTML. Scegli una pagina campione per ogni lingua e cerca hreflang. Devono esserci una riga per ogni traduzione reale, l’autoreferenziazione, URL assoluti aggiornati e nessun set duplicato. Un valore come en-UK, un URL relativo o un tag nel body richiedono correzione.
2. Apri tutti gli URL dichiarati. Ogni destinazione dovrebbe rispondere con HTTP 200, mostrare il contenuto nella lingua promessa, non avere noindex e non effettuare redirect inattesi. Verifica anche il canonical autoreferenziale e il return link: se A indica B ma B non indica A, Google può ignorare la relazione.
3. Confronta sitemap, canonical e link interni. La sitemap deve contenere gli URL finali desiderati, non pagine di staging, vecchi slug o domini dismessi. Se usa elementi xhtml:link per hreflang, confrontali con il markup HTML. Anche i link interni dovrebbero condurre alla variante corretta, senza passaggi intermedi evitabili.
4. Usa Search Console per l’indicizzazione. Il report International Targeting/hreflang non è più disponibile. In Controllo URL verifica stato di indicizzazione, canonical dichiarato dall’utente e canonical scelto da Google. Usa Visualizza pagina sottoposta a scansione, quando disponibile, per controllare ciò che Google ha ricevuto; consulta poi i report Indicizzazione delle pagine e Sitemap per esclusioni, errori e lettura dei file XML. Il test live non conferma definitivamente quale canonical verrà scelto durante l’indicizzazione.
5. Esegui un crawl per siti estesi. Un crawler esterno aiuta a individuare su centinaia di URL return link mancanti, tag duplicati, codici errati, destinazioni in redirect, errori 4xx/5xx, noindex e canonical discordanti. È uno strumento di audit, non una fonte gestita da Google.

Le indicazioni di Google sulle versioni localizzate, sulla canonicalizzazione e su Controllo URL sono il riferimento per interpretare questi segnali.

Gli errori che indeboliscono gli hreflang

I problemi più frequenti non dipendono dal tag in sé, ma dalla relazione incoerente tra le pagine. I più prioritari sono traduzioni non collegate, return link assenti, codici non validi, URL relativi, output duplicato da plugin diversi e tag pubblicati fuori dal head.

Sul piano SEO, correggi prima gli URL che restituiscono redirect o errori, poi canonical verso un’altra lingua, noindex impropri e redirect automatici aggressivi. Solo dopo conviene rifinire codici regionali, duplicazioni e sitemap obsolete. Una regione dovrebbe essere aggiunta esclusivamente quando esiste una reale variante locale, non come etichetta generica.

Il modo più affidabile per procedere è testare prima una coppia di pagine tradotte, risolvere ogni conflitto fra URL, canonical e reciprocità, quindi estendere il controllo con un crawl. WPML e Polylang automatizzano l’output; la qualità dell’implementazione dipende comunque dalla coerenza delle relazioni tra contenuti e segnali SEO. Per scegliere o confrontare i due strumenti, rimanda all’articolo interno dedicato a WordPress multilingua: Polylang vs WPML.