Impostare bene un sito multilingue: hreflang, indirizzi, insidie
Una seconda lingua è il modo più economico di guadagnare portata, dato che la sostanza c'è già. È anche il punto in cui nascono la maggior parte degli errori tecnici, perché quattro cose devono funzionare insieme e tre di esse sono invisibili.
In breve
- Le sottocartelle (
/it/) sono la scelta giusta per la maggior parte delle aziende: più semplici dei domini dedicati, più efficaci dei parametri. - hreflang deve essere reciproco: ogni versione rimanda a tutte le altre, a se stessa e a una versione predefinita.
- Gli indirizzi vanno tradotti. Un testo inglese sotto un indirizzo italiano è una traduzione a metà.
- Il reindirizzamento automatico in base alla lingua del browser è l'errore grave più frequente: esclude crawler e utenti.
La parte tecnica di un sito multilingue è contenuta, se la si imposta bene una volta, ed è faticosa se la si corregge dopo. Per questo la mezz'ora spesa prima conviene.
La struttura degli indirizzi
| Variante | Esempio | Adatta a |
|---|---|---|
| Sottocartella | esempio.ch/it/ | quasi tutti: un dominio, una forza |
| Sottodominio | it.esempio.ch | sistemi o gestori separati |
| Dominio nazionale proprio | esempio.it | presenze di mercato autonome con team dedicato |
| Parametro | esempio.ch/?lang=it | niente: da evitare |
Le sottocartelle vincono quasi sempre, perché tutte le versioni linguistiche beneficiano della forza dello stesso dominio. I domini nazionali richiedono che ciascuno venga costruito da solo, e questo conviene solo con un team per mercato.
Impostare hreflang correttamente
Quattro regole che devono valere insieme. Se una è violata, spesso l'intero gruppo viene ignorato.
- Reciproco. Se la versione italiana rimanda a quella inglese, anche l'inglese deve rimandare all'italiana. Le indicazioni unidirezionali vengono scartate.
- Autoriferimento. Ogni pagina rimanda anche a se stessa. Viene dimenticato spesso e non è facoltativo.
- Indicare la versione predefinita. Un
x-defaultper tutte le lingue non coperte. - Indirizzi assoluti. Completi di protocollo e dominio, nessun percorso relativo.
it per l'italiano in generale, it-CH per l'italiano in Svizzera. Chi ha una sola versione italiana usa it, non it-CH. Altrimenti i visitatori italiani non vedono assegnata quella versione.
Sei errori che rendono invisibile un sito multilingue
1. Reindirizzamento automatico in base alla lingua del browser
L'errore più grave. I crawler arrivano per lo più con impostazione linguistica statunitense e non vedono mai le altre versioni. Anche gli utenti non arrivano più dove volevano andare.
Corretto: mostrare un avviso con una proposta, senza reindirizzare. Ricordare la scelta.
2. Indirizzi non tradotti
/it/impressum/ invece di /it/note-legali/. Sembra una versione fatta a metà e spreca il termine di ricerca nell'indirizzo.
Corretto: tradurre i segmenti dell'indirizzo per ogni lingua, fissarli in modo stabile e non cambiarli più.
3. Il canonical punta alla lingua principale
Se la pagina inglese indica come indirizzo canonico quello italiano, state dicendo: questa pagina è un duplicato, prendi l'altra. Sparisce dall'indice.
Corretto: ogni versione linguistica è il proprio indirizzo canonico.
4. Attributo lang mancante
<html lang="it"> manca o è uguale in tutte le versioni. Non riguarda solo i motori di ricerca ma anche i lettori di schermo, dove porta a una pronuncia incomprensibile.
Corretto: il codice adatto per ogni versione, impostato in automatico.
5. Un unico sitemap per tutto, senza indicazioni di lingua
Senza indicazioni hreflang nel sitemap manca il collegamento tra le versioni proprio dove sarebbe più facile riconoscerlo.
Corretto: hreflang o nel sitemap o nel <head>, in modo coerente in un solo posto.
6. Pagine tradotte a metà
Titoli tradotti, testo corrente in un'altra lingua. Per i motori di ricerca è una pagina senza una lingua chiara, e per i visitatori un problema di fiducia.
Corretto: meglio poche pagine complete che tutte a metà.
Lo sapevi?
Tradurre da solo non basta: quattro cose vanno adattate al Paese e non solo alla lingua — importi nella valuta locale, il quadro giuridico pertinente, esempi d'uso locale e formati di data.
Una versione inglese che nomina franchi svizzeri e la legge svizzera riveduta sulla protezione dei dati non è una versione per il mercato britannico, è una traduzione della pagina svizzera. Può essere una scelta voluta, ma deve essere una decisione e non una svista.
La manutenzione è il vero problema
La costruzione è un impegno una tantum. La manutenzione è permanente, ed è lì che i siti multilingue falliscono più spesso che sulla tecnica.
Dopo un anno il quadro tipico è questo: la lingua principale ha 40 pagine, la seconda 31, la terza 22. Le modifiche sono state fatte nella lingua principale e dimenticate nelle altre, e nessuno sa più quale versione sia aggiornata.
Contro questo aiuta solo una decisione strutturale: una modifica vale come conclusa solo quando è stata riportata in tutte le lingue. Chi non riesce a tenere quel ritmo dovrebbe offrire meno lingue: tre curate battono nettamente otto superate.
Lista di controllo prima dell'avvio
- Ogni pagina rimanda via hreflang a tutte le versioni, a se stessa e a x-default
- Ogni versione è il proprio indirizzo canonico
<html lang>è impostato correttamente per ogni versione- I segmenti degli indirizzi sono tradotti e fissati in modo stabile
- Nessun reindirizzamento automatico in base alla lingua del browser
- La scelta della lingua è visibile e funziona senza JavaScript
- Importi, riferimenti normativi ed esempi sono adattati, non solo tradotti
- Esiste un processo fisso che riporta le modifiche in tutte le lingue
Verifica l'impostazione multilingue del mio sito. Dati: - Dominio: [indirizzo] - Lingue: [elenco con i codici] - Struttura degli indirizzi: [sottocartella / sottodominio / dominio proprio] - Blocco hreflang di una pagina d'esempio: [inserire blocco] - Indicazione canonical della stessa pagina: [inserire] - Attributo lang della stessa pagina: [inserire] - Esiste un reindirizzamento automatico in base alla lingua del browser? [sì / no] - I segmenti degli indirizzi sono tradotti? [esempio per lingua] Compiti: 1. Verifica le quattro regole hreflang: reciproco, autoriferimento, x-default presente, indirizzi assoluti. Indica ogni violazione separatamente. 2. Verifica se i codici lingua siano scelti bene, in particolare se un'indicazione di regione sia troppo restrittiva. 3. Verifica canonical e attributo lang cercando contraddizioni con la versione linguistica. 4. Indica i punti dei miei dati che possono rendere invisibile una versione linguistica, ordinati per gravità. 5. Restituiscimi per intero il blocco hreflang corretto. Non inventare indirizzi: segna ciò che manca come [da integrare].
Conclusione
Sul piano tecnico un sito multilingue si decide in quattro punti: struttura degli indirizzi, hreflang reciproco, indirizzo canonico proprio per ogni versione, nessun reindirizzamento automatico. Se questi quattro sono corretti, il resto funziona.
La domanda vera arriva dopo ed è organizzativa: riuscite a riportare ogni modifica in tutte le lingue? Se no, meno lingue è la decisione migliore.
Domande frequenti
Quale struttura di indirizzi è migliore per i siti multilingue?
Le sottocartelle come /it/ per quasi tutte le aziende: tutte le versioni linguistiche beneficiano della forza dello stesso dominio e la gestione resta semplice. I domini nazionali propri convengono solo con presenze di mercato autonome e un team dedicato; i parametri di lingua nell'indirizzo andrebbero evitati.
Che cosa va osservato con hreflang?
Quattro regole insieme: le indicazioni devono essere reciproche, ogni pagina deve rimandare anche a se stessa, serve un x-default per le lingue non coperte, e tutti gli indirizzi devono essere assoluti. Se una regola è violata, spesso viene ignorato l'intero gruppo.
Conviene reindirizzare i visitatori automaticamente alla loro lingua?
No. I crawler arrivano per lo più con impostazione linguistica statunitense e non vedono mai le altre versioni; gli utenti non arrivano dove volevano. Corretto è un avviso con una proposta che ricorda la scelta fatta, senza reindirizzamento automatico.
Gli indirizzi vanno tradotti?
Sì. Un testo inglese sotto un indirizzo italiano sembra fatto a metà e spreca il termine di ricerca nell'indirizzo. I segmenti dell'indirizzo andrebbero tradotti per ogni lingua e poi fissati in modo stabile: le modifiche successive costano la visibilità costruita.
Quante lingue hanno senso?
Tante quante se ne possono mantenere in modo duraturo. Lo stato più frequente dopo un anno sono versioni di completezza diversa in cui nessuno sa più quale sia aggiornata. Tre lingue curate funzionano nettamente meglio di otto superate: decisivo è un processo fisso che riporti ogni modifica in tutte le versioni.
Un marketing che si configura da solo
La beta di Studio Engine è aperta. Prenota il tuo posto e contribuisci fin dall’inizio.
Partecipa alla beta →