L’annotazione di lingua alternativa indica ai motori che una stessa pagina esiste in più versioni linguistiche e quale servire a chi. È semplice nel principio e temibilmente facile da rompere: un errore su un solo elemento invalida spesso l’intero gruppo.
Ecco dieci errori, verificabili in una ventina di minuti sul vostro sito.
1. Il collegamento di ritorno mancante
L’errore più frequente e il più distruttivo.
La dichiarazione deve essere reciproca. Se la vostra pagina italiana dichiara una versione tedesca, la pagina tedesca deve dichiarare l’italiana di ritorno. Senza questa reciprocità, la dichiarazione viene ignorata.
Il caso tipico: una traduzione aggiunta senza rigenerare il template di pagina, o una pagina depubblicata da un lato solo.
Verifica: aprite una pagina tedesca, guardate le sue annotazioni e controllate che punti all’italiana.
2. L’autoriferimento assente
Ogni pagina deve dichiarare se stessa nell’elenco, oltre alle sue alternative.
Una pagina italiana che dichiara tedesco, spagnolo e francese ma non italiano è incompleta. L’autoriferimento fa parte del gruppo.
Verifica: contate le annotazioni su una pagina. Con cinque lingue dovete vederne cinque, non quattro.
3. La confusione con il tag canonico
L’errore più dannoso per il traffico internazionale.
Le versioni linguistiche non sono duplicati. Ogni pagina deve portare un canonico verso se stessa, non verso la versione d’origine.
Far puntare le traduzioni alla pagina originale equivale a chiederne la deindicizzazione. Il sito appare correttamente tradotto e non riceve alcun traffico estero.
Verifica: su una pagina tedesca, il canonico deve essere l’indirizzo tedesco.
4. I codici di lingua e di regione mescolati
Il codice può designare una lingua da sola, o una lingua in un paese. Entrambi sono validi e non significano la stessa cosa.
Un codice di lingua da solo si rivolge a tutti i parlanti di quella lingua. Un codice di lingua e regione si rivolge a quella lingua in quel paese preciso.
Tre errori classici: usare un codice di paese da solo, che non è valido; inventare un codice di regione inesistente; oppure mescolare le due forme in modo incoerente all’interno dello stesso gruppo.
Punto importante: il primo elemento è sempre la lingua, il secondo la regione. Il contrario non è valido.
Verifica: raccogliete tutti i vostri codici e confrontateli con le norme corrispondenti.
5. Il targeting per paese senza contenuti differenziati
Errore di progettazione più che di sintassi.
Dichiarare una versione per l’Italia e una per la Svizzera italiana ha senso solo se i contenuti differiscono davvero: prezzi, valuta, condizioni di consegna, note legali.
Se le due pagine sono identiche, create duplicazione senza beneficio, e i motori sceglieranno da soli quale servire.
Verifica: per ogni coppia di versioni della stessa lingua, individuate almeno una differenza sostanziale. Altrimenti unitele.
Modulo Hreflang PrestaShop 8 — Tag Alternate SEO Multilingua | DataFireflyTag hreflang corretti su tutte le tue pagine PrestaShop 8: URL native tradotte, x-default, gruppi multishop e 70+ codici hreflang.€29.00
6. Le annotazioni su pagine non tradotte
Situazione frequente sui cataloghi tradotti parzialmente.
Dichiarare una versione tedesca di una scheda prodotto la cui descrizione è rimasta in italiano produce due problemi: il visitatore tedesco arriva su contenuti che non capisce, e il motore constata che la pagina annunciata come tedesca non lo è.
La regola: dichiarate solo le versioni realmente tradotte. Un gruppo a tre lingue su un prodotto e a cinque su un altro è perfettamente valido.
Verifica: prendete tre prodotti a caso e leggete le loro versioni straniere. Se vi trovate la lingua d’origine, correggete.
7. Il valore generico usato male
Un valore particolare permette di designare una versione predefinita, servita ai visitatori la cui lingua non corrisponde a nessuna versione dichiarata.
Due errori. Trattarlo come una lingua, credendo che punti all’inglese: non punta a nessuna lingua in particolare. E dimenticarlo: senza di esso, un visitatore giapponese su un sito a cinque lingue europee non ha una versione designata.
Questo valore è facoltativo. Se lo usate, deve designare una sola pagina, e quella pagina deve stare nel gruppo come le altre.
8. Gli indirizzi relativi o incoerenti
Quattro problemi di indirizzo che invalidano le dichiarazioni.
Gli indirizzi relativi. Devono essere assoluti, con protocollo e dominio.
La mescolanza di protocolli, una versione dichiarata sicura e l’altra no.
Gli indirizzi con redirect. Una dichiarazione che punta a un indirizzo che reindirizza aggiunge un passaggio e confonde il segnale.
L’incoerenza con il canonico. Se la dichiarazione punta a un indirizzo e il canonico della pagina di destinazione a un altro, il gruppo è rotto.
Verifica: un controllo automatizzato su un campione di pagine individua questi quattro casi in pochi minuti.
9. Le pagine in errore o non indicizzabili
Una dichiarazione che punta a una pagina che non esiste più, che reindirizza o che porta una direttiva di non indicizzazione è inutilizzabile.
Il caso si verifica tipicamente dopo un restyling o l’eliminazione di un prodotto in una sola lingua.
Conseguenza pratica: quando ritirate una pagina in una lingua, dovete aggiornare le annotazioni di tutte le altre versioni del gruppo. È quello che si dimentica più spesso.
Verifica: una scansione del sito con rilevazione dei codici di risposta sugli indirizzi dichiarati.
10. La sitemap e le intestazioni dimenticate
Le annotazioni possono essere poste in tre modi: nell’intestazione della pagina, nelle intestazioni di risposta o nella sitemap.
Due errori opposti.
Dichiararle in più punti con valori diversi, il che produce un conflitto.
Non dichiararle affatto per i documenti non HTML, come i PDF, per i quali è possibile solo la via delle intestazioni di risposta.
Su un catalogo importante, la dichiarazione nella sitemap presenta un vantaggio: centralizza l’informazione e alleggerisce le pagine. Richiede invece una sitemap generata correttamente e aggiornata.
Il metodo di verifica in venti minuti
Cinque passaggi.
1. Aprite una pagina in ogni lingua e confrontate le loro annotazioni. Devono elencare esattamente gli stessi indirizzi.
2. Verificate il canonico di ciascuna: deve puntare a se stessa.
3. Raccogliete i codici usati e validatene il formato.
4. Leggete il contenuto di due o tre pagine straniere per confermare che siano davvero tradotte.
5. Consultate il rapporto di targeting internazionale di Search Console, che segnala i collegamenti di ritorno mancanti e i codici non validi su scala di sito.
Quest’ultimo punto è il più efficace per il monitoraggio continuo: rileva le regressioni dopo una messa in produzione senza che dobbiate ricontrollare a mano.
Cosa queste annotazioni non fanno
Tre chiarimenti utili.
Non modificano il posizionamento. Indicano quale versione servire, non quale posizionare meglio.
Non sostituiscono la traduzione. Una pagina tradotta male resta una pagina scadente, correttamente annotata.
Non reindirizzano nessuno. Un visitatore che arriva sulla versione sbagliata deve poter cambiare, il che presuppone un selettore di lingua visibile.
Su quest’ultimo punto, una pratica da evitare: il reindirizzamento automatico secondo la lingua del browser. Impedisce a un visitatore di consultare un’altra versione e ostacola la scansione dei motori. Proponete, non forzate.
Il modulo Hreflang per PrestaShop gestisce queste annotazioni su PrestaShop 8 e 9: generazione automatica con reciprocità e autoriferimento, esclusione dal gruppo delle pagine non tradotte, coerenza con i canonici autoriferiti e controllo degli indirizzi dichiarati in errore o con redirect.
