Come implementare i tag hreflang per WordPress multilingue
Hai tradotto l'intero tuo sito WordPress in sei lingue. I file .po sono puliti, i file .mo sono compilati, ogni stringa viene renderizzata perfettamente in francese, tedesco e giapponese. Eppure, settimane dopo il lancio, controlli la Google Search Console e trovi qualcosa di sconcertante: la tua pagina francese si classifica per query tedesche, la tua pagina spagnola-messicana viene mostrata ai cercatori in Spagna, e due delle tue versioni linguistiche si stanno tranquillamente cannibalizzando a vicenda nelle classifiche. Il contenuto va bene. Il problema è che Google non ha idea di quale versione appartenga a quale pubblico.
Questo è esattamente ciò che i tag hreflang WordPress sono progettati per risolvere. Hreflang è il segnale che indica ai motori di ricerca quale versione linguistica e regionale di una pagina servire a quale utente. Se sbagli, subirai la diluizione di contenuti duplicati, risultati in lingua errata e uno spreco di budget di crawl. Se lo fai correttamente, ogni pagina tradotta raggiungerà il pubblico per cui è stata scritta. Questa guida copre la sintassi, la differenza tra codici lingua e codici lingua-regione, l'x-default obbligatorio, la reciprocità dei tag di ritorno e tre modi pratici per implementarlo in WordPress.
Cosa fa realmente hreflang
Hreflang non traduce nulla. È una mappa di relazioni. Quando hai la stessa pagina in più lingue, le annotazioni hreflang dicono a Google "questo URL è la versione inglese, questo è la versione tedesca, questo è per i parlanti spagnoli in Messico". Google utilizza quella mappa per servire la versione corretta nei risultati di ricerca in base alle impostazioni della lingua e alla posizione dell'utente.
L'annotazione si trova nell'<head> del tuo HTML come un insieme di elementi <link>. Ogni elemento nomina una pagina di destinazione e la lingua (e opzionalmente la regione) che serve. Ecco un set corretto di tag hreflang per una pagina disponibile in inglese americano, inglese britannico e spagnolo messicano, con un fallback predefinito:
<link rel="alternate" hreflang="en-US" href="https://example.com/en-us/pricing/" />
<link rel="alternate" hreflang="en-GB" href="https://example.com/en-gb/pricing/" />
<link rel="alternate" hreflang="es-MX" href="https://example.com/es-mx/pricing/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/pricing/" />
Ogni pagina del set dovrebbe produrre questo stesso blocco, elencando ogni alternativa, inclusa se stessa. Quest'ultimo punto confonde la maggior parte delle persone, e ci torneremo.
Perché questo è importante per la SEO
Senza hreflang, Google tratta le tue pagine tradotte come quasi-duplicati che competono per le stesse parole chiave. Il risultato è una diluizione: i segnali di ranking si dividono tra le versioni invece di consolidarsi. Con hreflang corretto, ogni versione eredita l'autorità del set nel suo complesso e si mostra ai giusti cercatori. Questa è una delle mosse SEO con il più alto potenziale che un sito multilingue può fare, e completa piuttosto che sostituire l'effettiva traduzione del contenuto nei tuoi file .po. Copriamo il lato dei contenuti in profondità nella nostra guida su come la traduzione dei file PO influisce sui ranking di Google.
Codici lingua vs. lingua-regione
Quale dovresti usare, en o en-GB? Usa il codice più semplice e veritiero. Se il tuo contenuto inglese è generico e non mantieni versioni separate britanniche e americane, usa solo en. Aggiungi un sottotag di regione solo quando servi realmente contenuti diversi a paesi diversi.
I valori hreflang seguono il formato lingua o lingua-regione. La parte della lingua è un codice ISO 639-1 (en, es, de, pt). La regione opzionale è un codice paese ISO 3166-1 Alpha 2 (US, GB, MX, BR). Quindi:
enmira a tutti i parlanti inglesi indipendentemente dal paese.en-GBmira ai parlanti inglesi nel Regno Unito.esmira a tutti i parlanti spagnoli.es-MXmira specificamente ai parlanti spagnoli in Messico.
Un dettaglio critico: il sottotag della regione è un paese, non una variante linguistica. es-MX non significa "dialetto spagnolo messicano", significa "spagnolo, mostrato agli utenti in Messico". Google lo serve comunque in base alla posizione dell'utente. Se mantieni dialetti regionali nelle tue traduzioni, il codice regione è il modo in cui li indirizzi. Approfondiamo l'aspetto linguistico di questo nella nostra guida sulle varianti regionali spagnole e portoghesi.
Un esempio errato comune
Ecco un blocco hreflang errato che vediamo costantemente:
<link rel="alternate" hreflang="en-uk" href="https://example.com/uk/" />
<link rel="alternate" hreflang="sp" href="https://example.com/es/" />
<link rel="alternate" hreflang="pt-PT_BR" href="https://example.com/pt/" />
Tre errori. en-uk non è valido perché il codice paese per il Regno Unito è GB, non UK. sp non è affatto un codice lingua; lo spagnolo è es. E pt-PT_BR mescola due regioni con un underscore che non ha alcun significato in hreflang. I motori di ricerca ignorano silenziosamente i valori malformati, quindi non ricevi alcun errore e nessun beneficio, solo ore di debug chiedendoti perché nulla sia cambiato.
Nota che hreflang usa un trattino (en-GB), mentre i file di localizzazione di WordPress usano un underscore (en_GB). Non copiare i codici dei nomi dei file .po direttamente nei tag hreflang.
L'x-default e la reciprocità dei tag di ritorno
Due regole causano più fallimenti silenziosi di hreflang di qualsiasi altra cosa: l'x-default mancante e la reciprocità interrotta.
Il valore x-default indica a Google quale pagina servire quando nessun'altra lingua corrisponde all'utente. È il tuo fallback, tipicamente il tuo selettore di lingua o la tua homepage per il mercato primario. Non è strettamente obbligatorio per specifica, ma in pratica dovresti sempre includerlo. Senza di esso, un visitatore di lingua portoghese per il quale non hai una versione portoghese riceve una scelta casuale invece di un default intenzionale.
La reciprocità dei tag di ritorno non è negoziabile. Ogni pagina in un set hreflang deve puntare a ogni altra pagina, inclusa se stessa. Se la tua pagina inglese elenca il tedesco come alternativa, la tua pagina tedesca deve elencare l'inglese come alternativa. Se la pagina tedesca omette il riferimento di ritorno, Google diffida dell'intera relazione e ignora le annotazioni.
<!-- On the German page, the set must still list ALL versions -->
<link rel="alternate" hreflang="de" href="https://example.com/de/about/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/about/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/about/" />
Il riferimento a se stesso (de che punta alla pagina tedesca mentre si visualizza la pagina tedesca) è richiesto, non opzionale. Un set di cinque versioni linguistiche significa che ciascuna delle cinque pagine produce tutti e cinque i tag <link> più x-default.
Tre modi per implementare hreflang in WordPress
Hai tre opzioni pratiche, che vanno dal controllo manuale completo all'automazione totale.
Metodo 1: Manuale tramite wp_head
Per un piccolo set statico di pagine, puoi iniettare i tag hreflang direttamente tramite l'azione wp_head nel file functions.php del tuo tema:
add_action( 'wp_head', function () {
if ( ! is_page( 'pricing' ) ) {
return;
}
$alternates = array(
'en-US' => 'https://example.com/en-us/pricing/',
'es-MX' => 'https://example.com/es-mx/pricing/',
'x-default' => 'https://example.com/pricing/',
);
foreach ( $alternates as $lang => $url ) {
printf(
'<link rel="alternate" hreflang="%s" href="%s" />' . "\n",
esc_attr( $lang ),
esc_url( $url )
);
}
} );
Questo ti offre un controllo preciso ma non è scalabile. Mantenere la reciprocità manualmente su centinaia di post è una trappola di manutenzione.
Metodo 2: Un plugin multilingue
Se utilizzi Polylang, WPML o TranslatePress, hreflang viene generato automaticamente in base alle tue relazioni di traduzione. Questa è la soluzione giusta per la maggior parte dei siti perché il plugin sa già quale post è la traduzione di quale, quindi la reciprocità e l'x-default sono gestiti per te. Il costo è l'overhead di runtime che questi plugin aggiungono, che è il compromesso che esaminiamo nel nostro confronto tra approcci di traduzione manuale e AI.
Metodo 3: Sitemap XML con xhtml:link
Invece di inserire hreflang nell'<head> di ogni pagina, puoi dichiarare le relazioni nella tua sitemap XML utilizzando lo spazio dei nomi xhtml:link. Ogni voce <url> elenca tutte le sue alternative linguistiche:
<url>
<loc>https://example.com/en/about/</loc>
<xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/about/" />
<xhtml:link rel="alternate" hreflang="de" href="https://example.com/de/about/" />
<xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/about/" />
</url>
Questo mantiene l'HTML della tua pagina snello e centralizza la mappa delle lingue in un unico file indicizzabile, che Google legge felicemente. La maggior parte dei plugin SEO può generarlo automaticamente.
hreflang completa la traduzione, non la sostituisce
Ecco il punto che tutti dimenticano: hreflang è inutile se le pagine sottostanti non sono effettivamente tradotte. Il tag dice a Google "questa è la versione tedesca", ma se l'URL tedesco mostra ancora stringhe di plugin in inglese, etichette di checkout non tradotte o file .po a metà, hai semplicemente detto a Google di servire contenuti rotti agli utenti tedeschi con piena fiducia.
La vera SEO multilingue è composta da due livelli. Il livello del contenuto sono i tuoi file .po, .pot, .json e .xliff tradotti che spingono ogni stringa del tema e del plugin nella lingua di destinazione. Il livello del segnale è hreflang che instrada ogni versione finita al suo pubblico. Entrambi devono essere solidi. Un set hreflang immacolato su un sito tradotto al 40% garantisce solo un'esperienza peggiore più rapidamente.
È qui che mantenere pulito lo strato di traduzione è più importante. Quando traduci i tuoi file di interfaccia, i placeholder come %s, %1$s e {name} devono rimanere intatti, altrimenti la tua pagina tedesca "tradotta" verrà renderizzata con token %s letterali che sembreranno rotti sia agli utenti che ai motori di ricerca. Una pipeline di traduzione consapevole di gettext con Syntax Locking protegge automaticamente quei token, in modo che ogni pagina alternativa a cui punti hreflang sia veramente pronta per la produzione. Poiché funziona nel cloud con Smart Batching, puoi far passare un intero sito multi-locale senza installare plugin di traduzione che appesantiscono il runtime che serve proprio quelle pagine.
Prepara bene il contenuto per primo, poi lascia che hreflang faccia il suo lavoro. I due insieme consolidano i segnali di ranking, eliminano i risultati in lingua sbagliata e mettono ogni pagina tradotta di fronte alle persone che possono leggerla.
Pronto a correggere i risultati di ricerca in lingua sbagliata alla fonte? Prova SimplePoTranslate gratuitamente — nessuna carta di credito richiesta. Traduci i tuoi file
.po,.pote.jsonnel piano gratuito, quindi punta i tuoi tag hreflang a pagine che sono effettivamente pronte per ogni mercato.