Errori comuni di hreflang in WordPress multilingue

Perché hreflang si rompe così spesso in WordPress

Hreflang dipende da un insieme completo di URL linguistici reciproci. In WordPress, questo insieme viene di solito costruito a partire dalle relazioni tra contenuti, dalle strutture dei permalink e da qualunque sistema memorizzi la mappatura delle lingue. Se una parte di questa catena cambia senza aggiornare le altre, le alternative smettono di descrivere lo stesso insieme di contenuti.

Ecco perché molti guasti non sono visibili come pagine rotte. La pagina si carica comunque, ma i motori di ricerca ricevono segnali contrastanti: un URL dice di essere la versione inglese, un altro punta a uno slug diverso e una terza versione potrebbe non essere più indicizzabile o potrebbe avere canonical altrove. Il risultato è un problema di relazione, non solo di markup.

Collegamenti di ritorno mancanti

Un insieme hreflang deve essere reciproco. Se la pagina francese punta alla pagina inglese, la pagina inglese deve puntare indietro alla pagina francese e a ogni altra alternativa valida nell’insieme.

In WordPress, i collegamenti di ritorno spesso falliscono quando una traduzione viene pubblicata più tardi, quando un template rende le alternative solo per alcuni tipi di contenuto, o quando una relazione linguistica esiste in una direzione ma non nell’altra. Questo crea un grafo incompleto: i motori di ricerca possono vedere che una pagina dichiara alternative, ma non possono verificare l’intero insieme da ogni membro.

La conseguenza operativa è che un solo collegamento reciproco mancante può indebolire l’intero cluster. Il problema è particolarmente facile da trascurare quando gli editor aggiornano solo una versione linguistica e presumono che la relazione sia ancora intatta.

Mappature errate di lingua o località

Un guasto comune è confondere codici lingua, varianti regionali o etichette del sito. Il valore hreflang deve descrivere la lingua reale o la destinazione lingua-regione, non l’etichetta del menu o la convenzione di denominazione interna del sito.

In WordPress, questo accade spesso quando un sito ha più varianti dell’inglese, oppure quando una traduzione viene assegnata alla relazione di località sbagliata dopo una migrazione dei contenuti. La pagina può essere completamente tradotta, ma se la mappatura indica la lingua o la regione sbagliata, il segnale diventa fuorviante.

Questo è importante perché hreflang serve a distinguere versioni molto simili. Se la mappatura è errata, i motori di ricerca possono trattare la pagina sbagliata come la corrispondenza migliore per la lingua o la regione di un utente, anche se il contenuto in sé è corretto.

Insiemi di URL incoerenti tra le versioni linguistiche

Ogni pagina in un cluster hreflang dovrebbe fare riferimento allo stesso insieme di alternative. Se la pagina inglese elenca inglese, francese e tedesco, ma la pagina tedesca elenca solo tedesco e inglese, l’insieme è incoerente.

Questo accade di solito quando le relazioni linguistiche vengono gestite manualmente, quando un template viene riutilizzato tra tipi di contenuto con copertura di traduzione diversa, o quando alcune pagine vengono escluse dall’output delle alternative perché non hanno una traduzione corrispondente. Il problema non è semplicemente la mancanza di un URL; è che il cluster non descrive più un insieme stabile e condiviso.

Per chi implementa WordPress, la domanda pratica è se l’elenco delle alternative derivi dalla relazione di contenuto corrente oppure sia codificato nel template. Gli elenchi codificati si discostano non appena una traduzione viene aggiunta, rimossa o non pubblicata.

Destinazioni non indicizzabili

Hreflang dovrebbe puntare a URL che i motori di ricerca possono indicizzare. Se una destinazione è bloccata, noindex, non disponibile o comunque non idonea all’indicizzazione, non può servire come alternativa affidabile.

In WordPress, questo può accadere quando una pagina tradotta è ancora in bozza, protetta, esclusa dalle impostazioni del sito o resa tramite un percorso che non dovrebbe essere indicizzato. Può accadere anche quando una traduzione esiste nel sistema dei contenuti ma l’URL pubblico non è realmente accessibile.

La modalità di guasto è sottile: la relazione sembra completa nel CMS, ma la destinazione non può partecipare all’indicizzazione di ricerca. Ciò significa che il segnale hreflang punta a una pagina che non può svolgere il proprio ruolo nel cluster.

Reindirizzamenti all’interno dell’insieme hreflang

Hreflang dovrebbe fare riferimento all’URL di destinazione finale e canonico, non a un URL che reindirizza immediatamente. I reindirizzamenti aggiungono un ulteriore livello di interpretazione e possono oscurare quale URL debba rappresentare la versione linguistica.

In WordPress, i reindirizzamenti compaiono spesso dopo modifiche ai permalink, aggiornamenti degli slug o aggiustamenti del routing specifici per lingua. Se l’output hreflang usa ancora il vecchio URL, la relazione punta a un bersaglio mobile. Se la catena di reindirizzamento cambia in seguito, l’insieme hreflang può degradarsi silenziosamente.

Il compromesso ingegneristico è chiaro: i reindirizzamenti sono utili per preservare i vecchi link, ma hreflang dovrebbe essere mantenuto sugli URL di destinazione stabili. Altrimenti il grafo linguistico e il livello di routing si allontanano tra loro.

Conflitti di canonical

Un URL hreflang e il suo segnale canonical devono concordare su quale pagina rappresenti il contenuto. Se una pagina tradotta canonicalizza verso una versione in un’altra lingua, i segnali entrano in conflitto.

Questo può accadere quando la logica canonical viene ereditata da un template, quando un livello dati gestito da un plugin produce alternative ma il tema o il livello SEO produce un canonical diverso, oppure quando una relazione di contenuto viene copiata da una lingua all’altra senza adattare la destinazione canonical. Il risultato è che un sistema dice: “questa è la pagina francese”, mentre un altro dice: “la pagina inglese è la versione preferita”.

Quel conflitto può rendere hreflang meno affidabile perché i motori di ricerca ricevono due istruzioni concorrenti sullo stesso URL. Il modello più sicuro è la coerenza: ogni pagina linguistica indicizzabile dovrebbe avere canonical verso se stessa, salvo un motivo deliberato e documentato per non farlo.

Relazioni obsolete dopo modifiche ai contenuti

Le modifiche ai contenuti in WordPress non preservano sempre automaticamente le relazioni linguistiche. Un cambio di slug, l’eliminazione di una traduzione, la duplicazione di un articolo o una fusione di contenuti possono lasciare riferimenti obsoleti nei meta dell’articolo, nei campi personalizzati o nei dati di relazione gestiti dal plugin.

Questo è uno dei guasti a lungo termine più comuni perché il sito potrebbe essere stato corretto al lancio. Col tempo, gli editor aggiornano una lingua, spostano una pagina o ritirano una traduzione, ma l’insieme delle alternative non viene ricostruito. L’output hreflang pubblica quindi URL che non appartengono più insieme.

Il rischio operativo è cumulativo. Più spesso cambiano i contenuti, più è probabile che il grafo linguistico diventi parzialmente obsoleto, a meno che il sistema non rigeneri le relazioni a partire dalla fonte di verità corrente.

Come si presentano di solito questi guasti in WordPress

La maggior parte dei problemi hreflang in WordPress deriva da una discrepanza tra stato dei contenuti e stato dell’output. Il CMS può sapere quali articoli sono traduzioni, ma la pagina renderizzata, il tag canonical, il livello di reindirizzamento o la struttura dei permalink potrebbero non riflettere più quella relazione.

Ecco perché chi implementa dovrebbe ragionare in termini di dipendenze: la relazione di traduzione, l’URL pubblico, l’indicizzabilità della destinazione e la destinazione canonical devono tutti concordare. Se un livello cambia senza gli altri, il cluster hreflang diventa incoerente anche se il markup in sé è sintatticamente valido.