Tradurre il tuo sito web: URL, hreflang e revisione
Un sito web tradotto ha bisogno di più del testo tradotto: un indirizzo per lingua, hreflang, l’attributo lang, un glossario e una revisione prima della pubblicazione.
Un indirizzo per lingua
Dai a ogni versione linguistica di una pagina un URL proprio, per esempio example.com/de/ ed example.com/pl/. Google consiglia URL separati invece di cambiare la lingua sullo stesso indirizzo con cookie o impostazioni del browser. Sottocartelle, sottodomini o domini nazionali funzionano tutti; i parametri URL come ?lang=de non sono consigliati. Google ricava la lingua di una pagina dal suo contenuto visibile, quindi tieni il testo e la navigazione di una pagina in una sola lingua.
hreflang: collegare le versioni
Con hreflang dici ai motori di ricerca quali pagine vanno insieme: con elementi link nell’head della pagina, un’intestazione HTTP o la sitemap. Per Google i tre modi sono equivalenti, quindi ne basta uno. Un esempio per una pagina in inglese, tedesco e polacco:
<link rel="alternate" hreflang="en" href="https://example.com/en/prices/" />
<link rel="alternate" hreflang="de" href="https://example.com/de/preise/" />
<link rel="alternate" hreflang="pl" href="https://example.com/pl/ceny/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/prices/" />- Lo stesso blocco va su tutte e tre le pagine. Ogni versione elenca sé stessa e tutte le altre; se B non rimanda ad A, Google ignora i tag.
- Usa indirizzi completi con https://, non solo /de/preise/.
- Il codice della lingua segue ISO 639-1 (de, pl), se vuoi con una regione in ISO 3166-1 Alpha 2, come de-AT. Un codice paese da solo non è valido.
- x-default indica la pagina per i visitatori la cui lingua non corrisponde a nessuna delle tue versioni. Google l’ha pensato per le pagine di scelta della lingua; molti siti usano la loro versione principale.
L’attributo lang
Imposta la lingua della pagina sull’elemento html, per esempio lang="en". Un passaggio in un’altra lingua riceve un proprio attributo lang sull’elemento che lo contiene. Secondo il W3C, sintesi vocale, traduzione in braille, correttori ortografici, scelta dei font e sillabazione usano questa informazione. Google invece scrive che non usa hreflang né l’attributo lang per riconoscere la lingua di una pagina. L’attributo serve quindi a browser e tecnologie assistive, e il testo visibile deve essere nella lingua giusta.
Cosa non va tradotto
- Tag e attributi HTML: un nome di classe o un href tradotto rompe il layout o il link.
- Segnaposto come {name}, {{count}}, %s o %1$d. Restano esattamente come sono e compaiono esattamente una volta.
- URL, nomi di file, indirizzi email, codice e shortcode come [contact-form].
- Chiavi nei file di lingua, come checkout.button.pay. Si traducono solo i valori.
- Nomi di marchi e prodotti, a meno che tu non abbia scelto di proposito un nome locale.
File di lingua: .po, JSON e XLIFF
App, temi e plugin tengono i loro testi in file di lingua. Nei file gettext .po ogni voce ha un msgid (il testo di partenza) e un msgstr (la traduzione); l’intestazione Plural-Forms dice quante forme plurali ha la lingua. Il polacco ne ha bisogno di tre, l’inglese di due. Nei file JSON i18n le chiavi restano e cambiano solo i valori. XLIFF tiene affiancati testo di partenza e di arrivo, con id e note che devono restare.
Un glossario per i termini di marchio e prodotto
Prima della prima traduzione decidi quali termini restano come sono (nomi di marchi, prodotti e piani) e quali ricevono sempre la stessa traduzione. Aggiungi la forma di cortesia: du o Sie in tedesco, ty o Pan/Pani in polacco. Così pulsanti, pagine prodotto ed email restano coerenti.
Traduzione automatica: una bozza, poi un madrelingua
La traduzione automatica ti dà una prima bozza veloce, non un testo finito. Le norme contro lo spam di Google citano i contenuti copiati trasformati in molte pagine con la traduzione automatica, con poco valore per gli utenti, come esempio di abuso di contenuti su larga scala. Il problema lì sono le pagine prodotte in massa senza valore, non la traduzione in sé. Google scrive anche che tradurre solo menu e footer mentre il contenuto principale resta in una lingua crea una brutta esperienza. Prevedi una revisione da parte di un madrelingua:
- 1Leggi il testo sulla pagina, non solo in una tabella. Il contesto cambia il significato.
- 2Controlla numeri, date, prezzi, unità e dati di contatto.
- 3Controlla i termini del glossario e la forma di cortesia.
- 4Controlla i testi brevi: pulsanti, voci di menu e messaggi di errore diventano spesso più lunghi o ambigui.
Non reindirizzare i visitatori automaticamente
Google sconsiglia i reindirizzamenti automatici basati sulla lingua o sulla posizione presunta di un visitatore, come l’indirizzo IP o la lingua del browser: possono impedire a persone e motori di ricerca di vedere tutte le versioni. Metti su ogni pagina un selettore della lingua visibile che rimanda alla stessa pagina nelle altre lingue, e lascia scegliere alle persone.
Lavorare con Do4U
Traduci HTML lascia invariati tag, link, attributi e segnaposto e poi controlla la struttura; il glossario del tuo account mantiene i nomi di marchi e prodotti come li vuoi. Lo strumento File di lingua fa lo stesso per i file .po, JSON e XLIFF e crea le forme plurali della lingua di arrivo. Lo strumento Traduci gestisce il testo semplice ed elenca come note i passaggi poco chiari.
Do4U crea la bozza, tu controlli e decidi. Falla leggere a un madrelingua prima di pubblicare. Una traduzione non è una promessa di più visitatori.
Fonti
- Google Search Central: comunicare a Google le versioni localizzate della tua pagina (pagina aggiornata il 21 settembre 2026) (developers.google.com)
- Google Search Central: gestire siti multiregionali e multilingue (pagina aggiornata il 10 dicembre 2025) (developers.google.com)
- W3C Internationalization: Why use the language attribute? (aggiornato il 5 settembre 2025, in inglese) (www.w3.org)
- Google Search Central: norme di Google relative allo spam per la ricerca web (pagina aggiornata il 28 agosto 2026) (developers.google.com)