Sito multilingua per l’export: hreflang, traduzioni vere e gli errori che costano clienti

C’è un momento preciso in cui un sito multilingua fatto male costa un cliente: il buyer tedesco arriva sul sito di un’oreficeria vicentina o di un’officina meccanica bresciana, clicca sulla bandierina, trova la homepage in inglese — e tutto il resto in italiano. Il preventivo che stava per chiedere non parte, e non lo saprai mai. Per un’azienda che esporta, il sito è il primo commerciale estero: lavora anche quando la fiera è finita. In questa guida vediamo come si costruisce un multilingua che vende: l’architettura degli URL, il tag hreflang spiegato con la documentazione di Google (non per sentito dire), cosa va localizzato oltre ai testi e — onestamente — quante lingue servono davvero.

Perché la lingua decide più del catalogo

Il dato più citato (e meno letto in originale) sul tema viene dallo studio “Can’t Read, Won’t Buy” di CSA Research (2020, 8.709 consumatori in 29 Paesi): il 76% degli acquirenti online preferisce comprare prodotti con informazioni nella propria lingua, e il 40% non compra mai da siti in un’altra lingua. In Germania — uno dei primi mercati di sbocco per la manifattura veneta e lombarda — la quota di chi compra solo in lingua locale è la più alta del campione: 57%.

“Ma io vendo B2B, mica ai consumatori.” Vero: lo studio riguarda acquirenti online. Ma il buyer di un’azienda tedesca è una persona che valuta fornitori leggendo pagine web, e un sito che gli parla a metà comunica una cosa precisa: per questa azienda il mio mercato è secondario. In un settore dove l’ordine vale decine di migliaia di euro e la relazione dura anni, è un pessimo primo messaggio.

I quattro errori che costano preventivi

Quando facciamo l’audit di un sito aziendale che esporta — dalle officine bresciane alla meccanica bergamasca, fino alla logistica che passa per Trieste — gli errori sono quasi sempre gli stessi quattro.

1. Traduzione automatica pubblicata senza revisione

Il traduttore automatico è un ottimo punto di partenza e un pessimo punto di arrivo. Sul lessico tecnico sbaglia proprio dove ti giochi la credibilità: le “minuterie metalliche” dell’oreficeria vicentina che diventano “metal trifles”, la “lavorazione conto terzi” resa parola per parola. Un buyer straniero non si accorge che il sito è tradotto male: si accorge che l’azienda sembra approssimativa, che è molto peggio. La regola pratica: la macchina traduce, un revisore madrelingua con un glossario tecnico di settore corregge, sempre, prima di pubblicare.

2. Solo la homepage tradotta

È l’errore più comune perché sembra un buon compromesso: “intanto traduciamo la home, poi si vedrà”. Il problema è che il buyer non entra dalla homepage: entra da Google, atterrando sulla scheda prodotto o sulla pagina delle lavorazioni. Se quelle sono in italiano, per lui il sito è in italiano. Una versione inglese fatta a metà, peraltro, produce esattamente gli errori hreflang che vediamo al punto seguente: pagine inglesi che puntano a equivalenti italiani inesistenti, o viceversa.

3. Hreflang assente, sbagliato o non reciproco

Hreflang è il tag che dice a Google quale versione linguistica mostrare a quale utente. Senza, capita che il potenziale cliente francese trovi in ricerca la versione italiana (o che Google tratti le versioni come contenuti in competizione tra loro). Ed è anche il tag che troviamo più spesso implementato male: lo vediamo assente, unidirezionale, o con codici inventati. Sotto lo spieghiamo per bene, con la fonte primaria.

4. Valute, contatti e form mai localizzati

Testi in inglese e tutto il resto in italiano: telefono senza prefisso internazionale (+39), form che chiede “Provincia”, prezzi solo in euro senza note su Incoterms o spedizioni, certificazioni citate con le sigle italiane. Sono dettagli, ma sono esattamente i dettagli che un ufficio acquisti straniero controlla prima di scriverti. La localizzazione finisce quando un buyer di Lione può chiedere un preventivo senza dover decifrare nulla.

Sottocartella, sottodominio o dominio locale?

Prima ancora dei tag viene l’architettura: dove vivono le versioni linguistiche? La documentazione di Google sui siti multiregionali mette a confronto le tre strutture possibili (e sconsiglia la quarta: i parametri URL tipo ?lang=de).

Per una PMI che esporta la risposta è quasi sempre la sottocartella: un solo dominio da mantenere, un solo profilo di autorità agli occhi di Google, costi contenuti. Il dominio locale ha senso quando un mercato pesa così tanto da giustificare una presenza (e un investimento SEO) separata — per la maggior parte delle aziende manifatturiere non è il caso. Due avvertenze dalla stessa documentazione: ogni lingua deve avere il suo URL (niente contenuti che cambiano via cookie sulla stessa pagina) e niente redirect automatici basati sull’IP dell’utente: impedirebbero a Google — e agli utenti — di raggiungere le altre versioni.

Hreflang: come funziona, dalla fonte

Il tag esiste da dicembre 2011 e la guida di SEOZoom lo descrive come uno dei tag più spesso mal interpretati e usati male. Ecco le regole essenziali, prese direttamente dalla documentazione ufficiale di Google sulle versioni localizzate:

• Tre metodi, uno solo basta. Tag nell’<head> della pagina, intestazioni HTTP o sitemap XML: Google li considera equivalenti e usarne più di uno contemporaneamente non porta vantaggi. Scegli il più pratico per il tuo sito e tienilo coerente.
• URL completi. Gli URL alternativi devono includere protocollo e dominio (https://azienda.it/en/prodotti), non percorsi relativi.
• Ogni pagina cita anche sé stessa. Il set di annotazioni va ripetuto identico su tutte le versioni, inclusa quella corrente.
• Codici standard. Lingua in formato ISO 639-1, regione in ISO 3166-1 Alpha-2. Il classico errore italiano: scrivere “UK” per il Regno Unito — il codice corretto è GB, e “UK” (come “EU”) non ha alcun effetto sulla Ricerca.
• x-default per chi non rientra in nessuna lingua. Puoi designare una sola versione come x-default: è la pagina di riserva mostrata quando nessuna lingua corrisponde alle impostazioni dell’utente — tipicamente la versione inglese o la pagina con il selettore di lingua.

Localizzare non è tradurre

Un sito export che funziona non è il sito italiano con le parole in inglese: è un sito pensato per chi lo legge da fuori. In pratica significa rivedere, mercato per mercato, almeno queste cose:

• I contenuti che contano per quel buyer. Il cliente tedesco cerca certificazioni, tolleranze e tempi di consegna; quello americano vuole capire subito capacità produttiva e minimi d’ordine. La pagina “chi siamo” commossa sulla terza generazione va bene ovunque, ma non basta da nessuna parte.
• Contatti utilizzabili dall’estero. Prefisso internazionale, e-mail presidiata in inglese, orari con fuso, form senza campi incomprensibili fuori dall’Italia.
• Unità, valute e condizioni. Se pubblichi prezzi o listini, chiarisci valuta e resa (Incoterms); se non li pubblichi, rendi la richiesta di preventivo banale da compilare.
• Le prove. Referenze e casi studio scelti per il mercato di destinazione: un cliente svizzero pesa più di dieci italiani, agli occhi di un buyer di Zurigo.

È lo stesso principio che applichiamo ai siti per l’artigianato e la manifattura: il sito non deve raccontare l’azienda, deve far partire la richiesta. In un’altra lingua, a maggior ragione.

Quante lingue servono davvero? Spesso due

Qui le guide tacciono, perché la risposta onesta fa vendere meno lingue: per la maggior parte delle PMI esportatrici bastano italiano e un inglese fatto davvero bene. L’inglese “en” generico, senza regione, copre buyer britannici, americani, scandinavi, olandesi e tutti i mercati dove l’inglese è la lingua di lavoro. Le versioni separate en-GB / en-US hanno senso solo se i contenuti differiscono sul serio (valute, unità di misura, listini): duplicarle uguali è manutenzione in più senza beneficio.

La terza lingua si aggiunge quando un mercato la giustifica coi numeri: se la Germania vale una quota importante del fatturato o delle fiere a cui esponi, il tedesco non è un lusso — ricordando il 57% di cui sopra. E vale anche il contrario: John Mueller di Google ha chiarito (lo riporta la guida di SEOZoom) che hreflang non è sempre necessario se Google mostra già le versioni corrette agli utenti giusti. Con due sole lingue ben separate spesso funziona tutto anche senza; il tag diventa importante quando le lingue crescono o quando vedi utenti atterrare sulla versione sbagliata. Farlo bene da subito costa poco; sistemarlo dopo, molto di più.

La nostra esperienza (e da dove partire)

Il progetto multilingua più grande che abbiamo costruito è una piattaforma per l’ospitalità in più lingue, con centinaia di pagine complessive: a quella scala nessun tag si scrive a mano — hreflang, sitemap e URL alternativi li genera il CMS, per ogni pagina, in automatico. La lezione vale anche per un sito da trenta pagine in due lingue: il multilingua è un moltiplicatore. Ogni scelta giusta si moltiplica per il numero di lingue; ogni errore anche. Per questo l’architettura si decide prima di tradurre la prima riga.

Se la tua azienda esporta e il sito parla solo italiano — o un inglese che si ferma alla homepage — il primo passo non è un preventivo di traduzione: è capire quali mercati servono, quali pagine contano e che struttura dare agli URL. È esattamente il tipo di ragionamento che facciamo nella consulenza gratuita: mezz’ora, senza impegno, con qualche numero in mano alla fine.