Ha lanciato una versione tedesca del suo sito. O una francese. Ha investito nella traduzione, aggiornato la navigazione, magari ha anche fatto revisionare i testi.
Sei mesi dopo, il traffico organico dalla Germania è fermo. I visitatori francesi sono ancora una percentuale trascurabile. Aprendo Google Search Console, le pagine tedesche non risultano indicizzate. O peggio: sono indicizzate, ma Google mostra i contenuti in inglese agli utenti tedeschi.
Questo è il modo silenzioso in cui fallisce la maggior parte dei siti multilingua. Dalla dashboard tutto sembra a posto. In realtà niente funziona.
Perché la Maggior Parte dei Siti Multilingua Non Performa
I problemi rientrano in tre categorie: struttura URL sbagliata, implementazione di hreflang non corretta e qualità delle traduzioni rilevabile sia dai motori di ricerca sia dagli utenti.
Errore tecnico 1: traduzione automatica senza revisione
DeepL e Google Translate hanno raggiunto risultati notevoli. Ma una traduzione automatica non revisionata si legge esattamente come tale. Un madrelingua se ne accorge entro due frasi. I motori di ricerca misurano i segnali di engagement, bounce rate, tempo di permanenza e profondità di scorrimento, e testi di bassa qualità penalizzano tutti e tre.
Errore tecnico 2: hreflang non corretto
Hreflang è l'attributo HTML che indica a Google quale versione di una pagina mostrare a quale utente. È anche l'elemento SEO configurato in modo errato più frequentemente sui siti multilingua. Tag auto-referenziali mancanti, URL non corrispondenti, set incompleti: basta uno di questi problemi per compromettere l'intero sistema.
Errore tecnico 3: cambio lingua gestito via JavaScript
Alcuni siti rilevano la lingua del browser in JavaScript e sostituiscono i contenuti lato client. Googlebot in molti casi vede solo la lingua predefinita. I contenuti francesi risultano invisibili ai crawler francesi di Google: si costruisce un sito multilingua che Google indicizza come solo in inglese.
Struttura URL: La Base che Non Si Può Cambiare in Seguito
Prima di toccare qualsiasi traduzione, occorre decidere come strutturare gli URL multilingua. Questa scelta è difficile da invertire: un errore richiede in futuro una migrazione completa con redirect.
| Struttura | Esempio | Ideale per |
|---|---|---|
| Sottodirectory | example.com/de/ | La maggior parte delle aziende: migliore consolidamento SEO, un solo dominio da gestire |
| Sottodominio | de.example.com | Grandi organizzazioni con team separati per regione |
| TLD nazionale | example.de | Aziende con forte identità di brand locale, budget per più domini |
| Parametro query | example.com?lang=de | Da evitare: Google sconsiglia questa soluzione, scarsa crawlability |
Per la maggior parte delle aziende la scelta giusta è la struttura a sottodirectory. L'autorità del dominio rimane consolidata. Si gestisce un solo dominio. Hreflang è più semplice da implementare. I costi di hosting restano prevedibili.
L'unico motivo per scegliere TLD nazionali (example.de, example.fr) è quando la fiducia nel mercato locale è un fattore critico di conversione, come avviene spesso nei servizi finanziari o sanitari, dove gli utenti cercano attivamente segnali di registrazione locale.
Hreflang: L'Attributo che Rompe Tutto Quando È Sbagliato
I tag hreflang comunicano ai motori di ricerca: "questa pagina in tedesco è l'equivalente di quella in inglese". Senza di essi, Google indovina. Di solito indovina male.
I quattro errori hreflang più comuni
- Tag auto-referenziale mancante: ogni pagina deve fare riferimento a se stessa nel proprio set hreflang. Omettere questo tag può portare Google a ignorare l'intero set.
- URL non corrispondenti: se hreflang punta a example.com/de/pagina/ ma l'URL reale è example.com/de/pagina (senza slash finale), il tag è non valido.
- Set incompleti: se la pagina inglese fa riferimento alla versione tedesca, quella tedesca deve a sua volta fare riferimento alla versione inglese. I tag unidirezionali vengono trattati come errori.
- Codici lingua errati: `de` indica il tedesco a livello globale. `de-DE` indica il tedesco specifico per la Germania. `de-AT` indica il tedesco per l'Austria. Usare il codice sbagliato può far mostrare a utenti austriaci di lingua tedesca la pagina pensata per la Germania.
Un'implementazione hreflang corretta per un sito in tre lingue ha questa forma: ogni pagina in ogni lingua contiene un set completo di tag che puntano a tutte e tre le versioni, inclusa se stessa. Tre tag per pagina per lingua: per 50 pagine in tre lingue si arriva a 450 dichiarazioni hreflang, tutte coerenti tra loro.
La gestione manuale a questa scala è la fonte principale degli errori. L'automazione a livello di framework è il modo per evitarli.
Qualità della Traduzione: Cosa Fa Davvero la Differenza
Non tutte le traduzioni sono equivalenti. L'approccio corretto dipende dal tipo di pagina, dal mercato e dal budget disponibile.
| Approccio | Qualità | Costo | Ideale per |
|---|---|---|---|
| Traduzione automatica grezza | Funzionale, rilevabile | Quasi zero | Documenti interni, pagine d'archivio a basso traffico |
| Automatica con revisione umana | Buona per la maggior parte dei contesti | Basso-medio | Blog, descrizioni prodotto, pagine secondarie |
| Traduzione professionale | Alta, accurata | Medio-alto | Pagine legali, case study, pagine di servizio principali |
| Copywriting nativo | Massima, culturalmente efficace | Alto | Homepage, landing page, pagine ad alta conversione |
L'errore più frequente delle aziende è applicare la traduzione automatica grezza in modo uniforme su tutto il sito, e poi chiedersi perché la homepage tedesca non converte. Una homepage è un documento di vendita: richiede copywriting nativo.
Un articolo di blog in posizione 8 per una keyword di nicchia può permettersi la traduzione automatica con revisione. La pagina principale di servizio no.
Adattamento Culturale: Ciò che gli Strumenti di Traduzione Non Sanno Fare
Una frase può essere corretta in tedesco e non convertire ugualmente. Register culturale, stile argomentativo e segnali di fiducia variano in modo significativo tra i mercati europei.
DACH (Germania, Austria, Svizzera)
I mercati di lingua tedesca si aspettano un registro formale (Sie, non du, salvo startup che si rivolgono a un segmento molto specifico), profondità tecnica e specificità. Affermazioni vaghe come "la migliore soluzione" risultano controproducenti: ogni claim va supportato con dati concreti. La privacy dei dati (DSGVO) è sia un obbligo legale sia un segnale di fiducia: va mostrata in modo prominente.
Francia
Il pubblico francese si aspetta formalità e una dimostrazione di competenza prima di accordare fiducia. Case study e credenziali contano. Il vouvoiement è d'obbligo in ogni testo. Testi troppo informali risultano poco professionali.
Spagna e America Latina
I mercati di lingua spagnola tendono a essere più caldi e orientati alla relazione. La fiducia si costruisce tanto attraverso il tono quanto attraverso le credenziali. Spagna e America Latina restano però mercati distinti: vocabolario, modi di dire e norme di formalità differiscono in modo rilevante. Una singola traduzione in spagnolo non servirà entrambi allo stesso modo.
Paesi Bassi
Il pubblico olandese è notoriamente diretto e trasparente sui prezzi. Detesta il linguaggio aziendale vuoto. Testi che suonano come comunicati stampa sottoperformano. Conviene essere specifici su costi e benefici: il concreto batte l'astratto.
Polonia
Gli acquirenti B2B polacchi sono orientati al valore: gli argomenti basati sul ROI funzionano bene. Il mercato è sensibile al prezzo rispetto all'Europa occidentale, ma i segnali di qualità contano. Con la maturazione del mercato, gli acquirenti polacchi sono diventati più selettivi. Contenuti che trasmettono l'impressione di essere una traduzione secondaria penalizzano la credibilità.
Il Problema del Multilingua su WordPress
La maggior parte delle aziende che tenta di rendere multilingua un sito WordPress ricorre a WPML o Polylang. Entrambi sono plugin maturi. Entrambi presentano problemi reali su larga scala.
Overhead sulle prestazioni
WPML aggiunge query al database a ogni caricamento di pagina per determinare e servire la versione linguistica corretta. Su un sito con 10.000 articoli in 5 lingue, questo overhead diventa misurabile e si somma a un'architettura già vincolata nelle prestazioni.
Complessità nella gestione delle traduzioni
Gestire le traduzioni in WordPress significa mantenere sincronizzate gerarchie di post parallele. Aggiornare una pagina di servizio in inglese richiede di segnalare manualmente e ri-tradurre ogni versione linguistica. Dimenticarne una significa avere contenuti obsoleti in produzione.
Errori hreflang
WPML e Polylang generano hreflang automaticamente, ma la qualità dell'output dipende dalla completezza delle traduzioni. Se manca una traduzione tedesca, il set hreflang di ogni pagina inglese che vi fa riferimento è incompleto. L'hreflang generato da plugin richiede una copertura traduttiva altrettanto perfetta.
Rischio di dipendenza dai plugin
L'intera infrastruttura multilingua dipende da un plugin di terze parti che deve restare compatibile con il core di WordPress, il tema e gli altri plugin. Gli aggiornamenti di WPML hanno causato regressioni in passato. Un malfunzionamento può colpire tutte le varianti linguistiche contemporaneamente, amplificando l'impatto di ogni aggiornamento problematico.
L'Approccio Next.js al Multilingua
Next.js gestisce l'internazionalizzazione a livello di framework, non di plugin. La differenza è architetturale.
Routing a livello di framework
In Next.js, `/de/services` e `/en/services` sono route di prima classe. Il framework le conosce al momento del build. Non esiste cambio lingua lato client né rilevamento runtime: Google indicizza ogni URL come una pagina completamente indipendente con il proprio contenuto.
Generazione automatica degli hreflang
Con una configurazione i18n corretta in Next.js, i tag hreflang vengono generati dalla configurazione delle route. Aggiungendo una nuova lingua, ogni pagina ottiene automaticamente i tag corretti. Rimuovendo una lingua, i riferimenti orfani vengono eliminati. Nessuna gestione manuale, nessun errore silenzioso.
Prestazioni costanti su tutte le lingue
Aggiungere versioni in tedesco e francese a un sito Next.js non introduce query al database, overhead di plugin o complessità PHP. Ogni lingua corrisponde a un insieme di file statici serviti dall'edge di un CDN. Un utente a Monaco riceve tipicamente la pagina da un nodo edge vicino in meno di 100ms (con variazioni legate alla copertura e al routing CDN), indipendentemente dal numero di varianti linguistiche.
Contenuto strutturato, nessun rischio plugin
I contenuti tradotti risiedono in file JSON o in un headless CMS. Nessun plugin da aggiornare, da rompere o da pagare. Nessuna modifica allo schema del database all'aggiunta di una lingua. Il contenuto è versionato insieme al codice.
Checklist Pre-lancio per Siti Multilingua
Prima di andare live con qualsiasi nuova versione linguistica, conviene verificare questa lista.
- Testare sul Google del paese target: usare una VPN o lo strumento di ispezione URL di Google Search Console per verificare che la versione linguistica corretta venga restituita per le ricerche da quel paese.
- Validare hreflang con uno strumento dedicato: Screaming Frog o Ahrefs Site Audit segnalano tag hreflang errati o mancanti sull'intero set di URL.
- Eseguire PageSpeed su ogni lingua separatamente: una pagina tedesca con un font stack più pesante o un set di immagini diverso può ottenere un punteggio diverso rispetto alla baseline inglese.
- Revisione da madrelingua prima del lancio: verificare errori tipografici, tono, registro e se il testo convertirebbe davvero un cliente locale.
- Localizzazione legale e dell'Impressum: i mercati DACH richiedono un Impressum in tedesco e una privacy policy conforme al DSGVO. La Francia richiede specifiche note legali. Si tratta di requisiti normativi, non di optional.
- Verificare il rilevamento della lingua all'accesso diretto all'URL: se un utente naviga direttamente a /de/services, deve ricevere la versione tedesca, non un redirect alla versione inglese basato sulle impostazioni del browser.
Come Si Presenta un Sito che Funziona Davvero
Un sito multilingua che funziona ha ranking organici diversi in ciascun mercato target. Google Search Console mostra impressioni e click provenienti dai paesi corretti sulle pagine nella lingua corretta. I bounce rate sono comparabili tra le lingue e non significativamente più alti nelle versioni tradotte. Quando un utente tedesco digita la keyword target su Google.de, trova la pagina tedesca, non quella inglese.
Questo risultato richiede di definire la struttura URL fin dall'inizio, implementare hreflang senza errori, calibrare la qualità della traduzione sull'importanza della pagina e adottare uno stack tecnico che mantenga tutto ciò in modo automatico.
La maggior parte delle aziende non ottiene tutte queste dimensioni al primo tentativo: l'iterazione è normale. Lo schema ricorrente è: lancio del sito tradotto, assenza di risultati, conclusione che il mercato non vuole il prodotto, abbandono dell'espansione internazionale.
Il mercato di solito vuole il prodotto. Il sito non era semplicemente costruito per raggiungerlo.
Riceva un Report Gratuito sulla Salute del Suo Sito
Se il sito multilingua non sta performando, o si sta pianificando di crearne uno e si vuole impostare l'architettura correttamente prima di iniziare, webvise può analizzare la configurazione attuale gratuitamente.
Il report gratuito sulla salute del sito copre l'implementazione hreflang, la struttura URL, PageSpeed per lingua e i segnali di qualità delle traduzioni. Fornisce un'analisi specifica e operativa di cosa non funziona e da dove iniziare.
Richieda il report gratuito su webvise.io/wp-health-report. Nessuna chiamata commerciale richiesta.