Prima ancora di scrivere una riga di hreflang, un sito multilingua deve decidere dove vivono le diverse versioni. La scelta della struttura degli URL è difficile da cambiare dopo: ogni cambiamento successivo è una migrazione, con tutti i rischi che comporta. Conviene quindi ragionarci all'inizio, valutando costi, gestione e segnali che ciascuna opzione trasmette.
Le opzioni possibili
| Struttura | Esempio | Note principali |
|---|---|---|
| Sottocartelle | example.com/it/ |
un solo dominio, gestione semplice |
| Sottodomini | it.example.com |
separazione tecnica, configurazione più complessa |
| Domini nazionali (ccTLD) | example.it, example.de |
segnale geografico forte, costi elevati |
| Parametri | example.com/?lang=it |
sconsigliato |
Sottocartelle
È la scelta più diffusa per siti piccoli e medi. Tutte le lingue condividono lo stesso dominio, quindi i link ricevuti da una versione rafforzano l'intero sito. Un solo certificato, una sola configurazione DNS, una sola proprietà da monitorare, con la possibilità di filtrare i dati per cartella.
Lo svantaggio è che la separazione è solo logica: se si vuole ospitare una lingua su un'infrastruttura diversa, bisogna instradare le richieste a livello di proxy o CDN.
Sottodomini
Permettono di separare tecnicamente le versioni, per esempio quando ogni paese ha un team, un CMS o un fornitore diverso. In compenso ogni sottodominio va configurato, monitorato e protetto a parte, e i motori possono trattarlo con una certa autonomia rispetto al dominio principale.
Domini nazionali
Un dominio come .it o .de comunica in modo chiaro il paese di riferimento, e per alcuni mercati gli utenti si fidano di più di un'estensione locale. I costi però crescono: registrazione e rinnovo di più domini, eventuali requisiti di residenza per alcune estensioni, link e autorevolezza divisi fra siti distinti.
Va ricordato che un ccTLD indica un paese, non una lingua. Un sito .ch può avere versioni in italiano, francese e tedesco; un sito .it non è il posto giusto per servire il mercato svizzero.
Alcuni domini a due lettere, come .io o .co, vengono usati come estensioni generiche e i motori li trattano spesso come tali, senza associarli al paese originale.
Parametri
?lang=it funziona tecnicamente, ma è fragile: il parametro si perde facilmente nei link, viene confuso con parametri di tracciamento e rende difficile analizzare le versioni separatamente. Meglio evitarlo.
Lingua o paese?
Prima di scegliere la struttura, chiarisci cosa stai segmentando:
- solo lingua: stessi prodotti e stesse condizioni per tutti, cambia la traduzione. Bastano
/it/,/en/,/de/; - paese: prezzi, valute, disponibilità o normative diverse. Servono versioni come
/it-it/,/it-ch/,/de-ch/, oppure domini nazionali.
Mescolare i due livelli senza criterio produce strutture incoerenti, con /en/ accanto a /uk/ e /us/, difficili da mantenere e da annotare.
Il problema dei redirect automatici
Molti siti reindirizzano l'utente in base all'indirizzo IP o all'intestazione Accept-Language del browser. Sembra una cortesia, ma crea problemi seri:
- i crawler si presentano spesso da indirizzi di un solo paese e senza preferenze di lingua: se vengono sempre reindirizzati alla stessa versione, le altre rischiano di non essere mai scansionate;
- gli utenti in viaggio, gli expat o chi usa una VPN finiscono nella lingua sbagliata senza possibilità di uscirne;
- i link condivisi non portano più alla pagina che il mittente voleva mostrare.
La soluzione più solida è:
- ogni URL serve sempre la stessa lingua, indipendentemente da chi lo richiede;
- se la lingua dell'utente non corrisponde, si mostra un banner non invasivo che propone la versione adatta;
- la scelta dell'utente viene ricordata, per esempio con un cookie, e rispettata nelle visite successive;
- un eventuale redirect automatico si applica al massimo sulla radice del sito, con una risposta temporanea, e la radice è indicata come
x-default.
Contenuti da tradurre davvero
Una struttura perfetta non salva pagine tradotte a metà. Le parti che spesso restano nella lingua originale sono:
- titoli e meta description;
- testo alternativo delle immagini;
- etichette di navigazione, pulsanti e messaggi di errore;
- slug degli URL, che possono e di solito dovrebbero essere tradotti;
- dati strutturati, che devono riflettere il testo visibile nella lingua della pagina.
Nel mio lavoro, quando controllo un sito multilingua, cerco prima di tutto i template condivisi: è lì che si annidano le frasi non tradotte che finiscono in centinaia di pagine.
In sintesi
- Decidi la struttura all'inizio: cambiarla dopo è una migrazione.
- Le sottocartelle sono la scelta più semplice ed economica per la maggior parte dei siti.
- I domini nazionali segnalano un paese, non una lingua, e moltiplicano i costi.
- Evita redirect automatici per IP o browser; proponi la versione con un banner.
- Traduci anche titoli, slug, alt, interfaccia e dati strutturati.
