Aggiungere una seconda lingua a un sito WordPress non è semplicemente tradurre i testi. È una modifica strutturale che impatta l’architettura del sito, il SEO e le performance. Un sito web multilingua WordPress fatto bene apre mercati nuovi senza toccare il posizionamento esistente. Fatto male, compromette il traffico organico su tutte le lingue contemporaneamente. Le decisioni critiche sono due: la configurazione tecnica di WPML e la struttura degli URL. Tutto il resto dipende da queste.
Noi di Blurr gestiamo progetti multilingua per agenzie partner con clienti nei settori manifatturiero, turistico e dei servizi professionali. Il pattern che vediamo più spesso quando prendiamo in carico un sito multilingua già esistente è sempre lo stesso: la traduzione dei contenuti è stata fatta con cura, ma la parte tecnica, hreflang, struttura URL, sitemap multilingua, è stata configurata in modo approssimativo o del tutto ignorata. Il risultato è che Google non capisce quale versione della pagina mostrare a quale utente, e le versioni non italiane non ricevono traffico organico nonostante i contenuti siano tradotti correttamente.
Perché usiamo WPML su tutti i progetti multilingua
La scelta del plugin di traduzione non è una questione di preferenza. È una decisione tecnica con conseguenze a lungo termine sulla stabilità del sito, sulla compatibilità con il page builder e sulla gestione SEO.
Su tutti i progetti multilingua WordPress usiamo WPML senza eccezioni. La ragione principale è la compatibilità certificata con Bricks Builder, il page builder con cui sviluppiamo. WPML testa la compatibilità con ogni aggiornamento di Bricks in modo sistematico, cosa che altri plugin di traduzione non garantiscono. Su siti con template globali, componenti ripetuti e custom post type complessi, questa garanzia vale molto più del risparmio su una licenza alternativa.
WPML include: traduzione automatica integrata via DeepL, gestione automatica degli hreflang, compatibilità nativa con WooCommerce per ecommerce multilingua, traduzione degli slug degli URL per ogni lingua, e generazione automatica della sitemap multilingua. Per le agenzie che preventivano questo tipo di progetto, il costo della licenza WPML rientra come voce di produzione standard, esattamente come il costo dell’hosting o degli altri plugin premium.
| Tipo di progetto | Configurazione Blurr |
|---|---|
| Sito istituzionale 2-3 lingue | WPML Multilingual CMS |
| Ecommerce WooCommerce multilingua | WPML + WooCommerce Multilingual |
| Sito con Bricks Builder | WPML (compatibilità certificata) |
| Sito con custom post type multipli | WPML Multilingual CMS |
| Più di 4 lingue attive contemporaneamente | WPML con traduzione automatica DeepL |
La struttura URL: la decisione che non si può cambiare dopo
Prima ancora di installare WPML, la scelta più importante è la struttura degli URL per le versioni linguistiche. Ci sono tre opzioni e solo una è quella che consigliamo quasi sempre.
Sottodirectory (sito.it/en/, sito.it/de/): è la soluzione raccomandata da Google e quella che usiamo come impostazione predefinita. Mantiene tutto su un unico dominio, permette di condividere l’autorità del dominio tra tutte le lingue, ed è la più semplice da gestire tecnicamente. WPML la configura in pochi click durante il setup iniziale.
Sottodominio (en.sito.it, de.sito.it): tecnicamente possibile, ma Google tratta i sottodomini come siti separati. L’autorità SEO non si condivide automaticamente tra versioni linguistiche. Lo sconsigliamo per quasi tutti i casi.
Dominio separato (sito.de, sito.com): ha senso solo quando il cliente vuole presidiare un mercato estero con un’identità di brand separata e ha risorse per costruire autorità su ciascun dominio indipendentemente. Complessità di gestione molto alta, costi di manutenzione proporzionalmente maggiori.
La ragione per cui questa scelta è critica: cambiarla dopo la pubblicazione richiede redirect 301 su tutti gli URL, aggiornamento della Search Console e reindicizzazione completa. È un’operazione rischiosa che può causare perdite temporanee di posizionamento anche significative. Decidere bene prima costa zero.
Hreflang: l’errore tecnico più frequente e più costoso
L’attributo hreflang è il tag che dice a Google in quale lingua e per quale paese è pensata ogni versione di una pagina. Senza hreflang configurato correttamente, Google non sa quale versione mostrare a quale utente e tende a mostrare la versione italiana a tutti, indipendentemente dalla loro lingua. Risultato: traffico internazionale che non arriva, o che arriva sulla pagina sbagliata.
WPML genera gli hreflang automaticamente su tutte le pagine, incluse quelle con custom post type. È uno dei motivi principali per cui lo scegliamo: la configurazione manuale degli hreflang è soggetta a errori e richiede aggiornamento ogni volta che si aggiunge o modifica un URL.
Gli errori che troviamo più spesso quando prendiamo in carico siti multilingua configurati senza WPML o con WPML configurato male:
Problema: Hreflang presente solo su alcune pagine, assente sulle pagine di tipo custom Causa: Plugin configurato parzialmente o hreflang inseriti manualmente nel tema senza copertura completa Soluzione Blurr: Audit con Screaming Frog di tutte le pagine indicizzate per verificare che ogni URL abbia i tag hreflang corretti verso tutte le versioni linguistiche, poi migrazione a configurazione WPML automatica
Problema: Hreflang che puntano a URL inesistenti o con redirect 302 Causa: Ristrutturazione del sito o cambio tema senza aggiornamento dei tag; oppure migrazione da un sistema di traduzione a WPML senza pulizia degli URL precedenti Soluzione Blurr: Audit degli URL di destinazione negli hreflang, correzione dei redirect, sostituzione dei 302 con 301 permanenti dove necessario
Problema: Assenza del tag x-default Causa: Configurazione WPML incompleta, impostazione della lingua predefinita non salvata correttamente Soluzione Blurr: Aggiunta del tag x-default che indica a Google la versione predefinita del sito per utenti con lingua non mappata tra quelle disponibili
Il caso che ricordiamo bene su questo fronte: un’agenzia di Padova ci ha contattato perché il sito di un cliente nel settore macchinari industriali aveva una versione tedesca curata e aggiornata da due anni, ma riceveva pochissimo traffico organico dalla Germania. L’audit ha rivelato che gli hreflang erano stati configurati manualmente nello header del vecchio tema, senza essere aggiornati quando il sito era stato migrato a un nuovo tema diciotto mesi prima. I tag puntavano a URL che nel frattempo restituivano redirect 302 invece di 301. Google aveva smesso di fidarsi dei tag e gestiva le versioni linguistiche in modo autonomo, con risultati prevedibilmente scarsi. Abbiamo risolto in tre giorni: audit completo con Screaming Frog, migrazione della configurazione hreflang su WPML, correzione dei redirect, reindicizzazione richiesta via Search Console. Nel mese successivo il traffico organico dalla Germania era cresciuto del 60%.
La traduzione degli slug e gli altri dettagli che determinano il risultato
Un URL come sito.it/en/about-us è corretto per la versione inglese. Ma sito.it/de/about-us non lo è: per la versione tedesca lo slug dovrebbe essere uber-uns. WPML permette la traduzione degli slug URL per ogni lingua direttamente dall’interfaccia di amministrazione, senza interventi sul codice. È un dettaglio che molte agenzie saltano perché sembra secondario, ma un URL in lingua contribuisce alla pertinenza della pagina nelle ricerche locali in modo misurabile.
Altri elementi che vanno verificati sistematicamente prima di consegnare un sito multilingua:
Sitemap XML multilingua. WPML genera automaticamente una sitemap che include tutte le versioni linguistiche. Va verificato che sia sottomessa correttamente su Google Search Console. Per siti con più domini o sottodomini, ogni proprietà va configurata separatamente.
Metadati SEO per lingua. Meta title, meta description e tag Open Graph devono esistere in ogni lingua. Slim SEO, il plugin SEO che usiamo noi di Blurr, è pienamente compatibile con WPML: i campi SEO si traducono direttamente dall’interfaccia di traduzione di WPML senza configurazioni aggiuntive.
Traduzione delle email di sistema. Per siti con form di contatto o ecommerce, le email transazionali, conferma ordine, notifica di spedizione, risposta automatica al form, devono essere tradotte nella lingua dell’utente. WPML gestisce anche questo tramite l’integrazione con i principali plugin di form e con WooCommerce.
Per le agenzie che gestiscono clienti con mercati internazionali e stanno valutando come strutturare un progetto multilingua WordPress, blurr.it/contatti/ è il punto di partenza: valutiamo insieme la complessità del progetto e la configurazione più adatta. Blurr, studio WordPress white label con sede a Calliano (Trento), gestisce sviluppo multilingua per oltre 130 agenzie partner italiane usando WPML come standard su tutti i progetti.
FAQ
Conviene usare la traduzione automatica DeepL integrata in WPML o è meglio la traduzione umana? Dipende dal tipo di contenuto. Per testi tecnici o commerciali dove la precisione conta, la traduzione automatica va sempre revisionata da un madrelingua prima della pubblicazione. Per contenuti generici o descrizioni di prodotto standard può essere un punto di partenza accettabile da rifinire. Non usarla come soluzione definitiva senza revisione: i testi non revisionati si riconoscono e danneggiano la credibilità del sito nei mercati esteri.
Quante lingue può gestire un sito WordPress senza problemi di performance? Non esiste un limite tecnico, ma ogni lingua aggiunge contenuti al database e complessità alla gestione. Siti con cinque o più lingue attive richiedono attenzione all’ottimizzazione del database e al caching. Con SuperPageCache e Cloudflare come stack standard, le performance rimangono stabili anche con cataloghi multilingua estesi. Il vero limite è operativo: più lingue significano più contenuti da tradurre e aggiornare nel tempo.
Cosa succede al posizionamento SEO esistente quando si aggiunge una seconda lingua? Se la configurazione è corretta, sottodirectory, hreflang, sitemap aggiornata, il posizionamento sulla versione italiana non viene impattato. La nuova versione linguistica parte da zero come posizionamento organico e costruisce la propria autorità nel tempo. L’unico rischio reale è una configurazione errata degli hreflang che crea ambiguità per Google: per questo l’audit tecnico dopo l’attivazione di ogni nuova lingua è un passaggio che non saltiamo mai.
WPML rallenta il sito? WPML aggiunge query al database per gestire le traduzioni. Su siti con molti contenuti e molte lingue l’impatto è misurabile senza caching. Con caching configurato correttamente e hosting adeguato, l’impatto sui Core Web Vitals è trascurabile nella pratica. La soluzione non è evitare WPML, ma assicurarsi che il sito sia ottimizzato nel suo insieme.