Sito multilingue: hreflang, slug locali, traduzione
Come hreflang, URL tradotti e un processo di traduzione continuo lavorano insieme per rendere affidabile un sito multilingue in entrambi i mercati.
Team rabbitclipPubblicato: 6 min di lettura
In breve
Hreflang è un tag HTML che indica ai motori di ricerca per quale lingua e regione è scritta una pagina; impostato male, Google può scambiare versioni linguistiche diverse dello stesso contenuto per duplicati e mostrare una pagina nella lingua sbagliata a un utente del paese sbagliato. Costruire un sito multilingue non significa solo tradurre il testo; significa pianificare insieme la struttura degli URL, i tag hreflang e il processo di traduzione nel tempo.
Per un'agenzia che lavora tra Istanbul e Londra, non è un tema astratto; il sito di un produttore con una versione inglese e una turca può, senza hreflang, mostrare una pagina in turco a un acquirente a Londra e una pagina in inglese a un cliente a Istanbul.
Questo articolo spiega cosa fa hreflang, come dovrebbe essere costruita la struttura degli URL, e come si gestisce il processo di traduzione.
Cosa fa davvero hreflang
Hreflang è un tag nel codice sorgente di una pagina che indica per quale lingua, ed eventualmente quale regione, quella pagina è scritta, e che rimanda in entrambe le direzioni alle altre versioni linguistiche dello stesso contenuto.
Quando Google vede che la versione turca rimanda a quella inglese e quella inglese rimanda indietro a quella turca, capisce che sono due versioni linguistiche diverse dello stesso contenuto, non contenuto duplicato.
Se questo tag manca, o funziona solo in un senso (la pagina turca rimanda a quella inglese ma non viceversa), Google si confonde; la pagina nella lingua sbagliata può finire mostrata al visitatore sbagliato, oppure le due pagine vengono trattate come copie l'una dell'altra.
Come dovrebbe essere costruita la struttura degli URL
Esistono tre strutture comuni per un sito multilingue: domini separati (sito.com.tr, sito.co.uk), sottodomini (tr.sito.com, en.sito.com), o sottocartelle (sito.com/tr/, sito.com/en/). Secondo le indicazioni stesse di Google, tutte e tre funzionano tecnicamente; la scelta dipende dalla preferenza di marca e marketing dell'azienda.
Una struttura a sottocartelle richiede di solito meno manutenzione, perché tutte le versioni linguistiche condividono l'autorità di un unico dominio. I domini separati si adattano a un'azienda che vuole un'immagine di marca distinta per mercato, ma ogni dominio deve poi guadagnarsi la propria autorità SEO separatamente.
Se il sito in inglese di una catena di centri benessere vive su un dominio separato mentre il sito in turco vive in una sottocartella, questa struttura incoerente crea confusione per i motori di ricerca; la struttura andrebbe fissata su un unico modello all'inizio del progetto.
Nel prendere questa decisione conviene anche considerare se in futuro potrebbe aggiungersi una terza lingua; una struttura pensata solo per due lingue può richiedere una revisione completa il giorno in cui se ne aggiunge una terza.
Cosa significa uno slug locale, e perché conta
Uno slug locale significa che anche le parole nell'URL di una pagina vengono tradotte in quella lingua; la versione inglese di una pagina 'servizi', ad esempio, dovrebbe stare su '/services', non sul turco '/hizmetlerimiz'.
Lasciare l'URL non tradotto indebolisce sia l'esperienza utente sia la SEO; un visitatore britannico che vede una parola turca nella barra degli indirizzi ha l'impressione che il sito non sia mai stato pensato per lui.
Impostare slug locali aggiunge un passaggio al processo di traduzione: non solo il testo della pagina, ma anche l'URL, il titolo della pagina e la meta description vanno pensati separatamente in ogni lingua.
Come costruire il processo di aggiornamento delle traduzioni
Il problema più comune su un sito multilingue è che la lingua di origine (qui di solito il turco) viene aggiornata mentre l'altra lingua (l'inglese) resta indietro. Se il prezzo di un prodotto o una descrizione di servizio cambia lato turco e resta datato lato inglese, un cliente britannico legge un'informazione superata.
La soluzione qui è di processo, non tecnica: una checklist che segnala l'altra lingua a ogni modifica dei contenuti, oppure il modulo di contenuto multilingue di un CMS headless, funzionano entrambi.
- Ogni aggiornamento di contenuto attiva un controllo dell'altra lingua, come processo continuo
- La traduzione segue il contesto invece della parola per parola; una traduzione letterale può suonare strana
- Le specificità locali (un metodo di pagamento, un riferimento legale) vengono adattate al mercato di destinazione invece di essere tradotte alla lettera
Quale azienda ha davvero bisogno di un sito multilingue
Un sito multilingue si giustifica per un'azienda che vende a clienti in più di un paese, riceve richieste dall'estero, o lavora con partner internazionali. Per un'azienda che serve solo il mercato locale, una seconda lingua diventa di solito manutenzione superflua.
La domanda che decide: c'è una domanda reale dall'estero, oppure la seconda lingua serve solo a 'sembrare più professionale'? Nel primo caso l'investimento si ripaga da sé; nel secondo, la manutenzione continua diventa un peso per l'azienda.
Perché la qualità della traduzione non è solo una questione di grammatica
Una buona traduzione va oltre la correttezza grammaticale; deve avvicinarsi al modo in cui il lettore di destinazione parla davvero ogni giorno. Una frase che suona naturale in turco può risultare rigida o strana tradotta parola per parola in inglese; è un problema di approccio alla traduzione, non un errore del traduttore.
L'espressione turca per un ordine all'ingrosso di un produttore di abbigliamento da lavoro si traduce direttamente come 'wholesale order', ma affiancarle un termine più cercato nel mercato britannico, 'bulk order' o 'trade account', si adatta meglio al comportamento di ricerca reale.
Per questo il processo di traduzione ha bisogno di qualcuno che conosca il mercato di destinazione, non solo di un traduttore; i due ruoli non devono coincidere nella stessa persona, ma uno dovrebbe controllare il lavoro dell'altro.
Una volta che piccoli aggiustamenti come questo vengono pensati una volta per tutte e messi per iscritto in una guida di stile all'inizio del processo, non serve ridiscuterli per ogni nuova pagina in seguito.
Un sito multilingue, costruito con hreflang corretto, URL tradotti e un processo regolare di aggiornamento delle traduzioni, appare affidabile in entrambi i mercati; costruito a metà, confonde sia il motore di ricerca sia il visitatore. In una prima chiamata conoscitiva con rabbitclip, la struttura multilingue esistente, dove ce n'è una, viene rivista insieme. Una volta che la struttura è impostata correttamente, aggiungere nuovi contenuti richiede solo lavoro di traduzione, non una ricostruzione tecnica.
Domande frequenti
Cosa succede se manca hreflang?
Google può mostrare la pagina nella lingua sbagliata al visitatore sbagliato, oppure trattare le due versioni linguistiche come contenuto duplicato.
Le sottocartelle sono meglio dei domini separati?
Entrambi funzionano tecnicamente; le sottocartelle richiedono di solito meno manutenzione, i domini separati si adattano quando si cerca un'immagine di marca distinta per mercato.
Gli URL vanno tradotti in ogni lingua?
Sì, slug tradotti rafforzano sia la fiducia del visitatore sia la SEO.
Ogni quanto vanno aggiornate le traduzioni?
Idealmente ogni volta che cambia il contenuto nella lingua di origine; è un processo continuo, non un lavoro una tantum.
Bastano strumenti di traduzione automatica come Google Translate?
No, la traduzione automatica può dare un punto di partenza rapido ma perde il contesto e il comportamento di ricerca locale; come minimo, una persona deve rivederla.
