WordPress multilingua nel 2026: plugin, multisite, AI e hreflang

Questo articolo è stato pubblicato per la prima volta nel 2009 e completamente riscritto a ottobre 2026: i commenti più vecchi si riferiscono alla versione originale.

Nel febbraio del 2009 avevo messo in fila cinque plugin per rendere WordPress multilingua, con tanto di numero di versione e data dell’ultimo aggiornamento, convinto di aver fatto un servizio prezioso alla comunità: c’erano xLanguage e qTranslate, che infilavano tutte le lingue nello stesso campo separandole con dei marcatori, c’erano ZdMultiLang e Gengo, che salvavano le traduzioni in tabelle aggiuntive, e c’era WP Multilingual, che si appoggiava ai postmeta e che, lo ammettevo già allora, non funzionava nemmeno con WordPress 2.7. Rileggerlo oggi fa lo stesso effetto di ritrovare il proprio cellulare a conchiglia in un cassetto: tenerezza, un filo di imbarazzo e la certezza che nessuno di quei nomi ti aiuterà a lanciare un sito in tre lingue nel 2026.

Nel frattempo è cambiato quasi tutto: i plugin sopravvissuti alla selezione naturale sono maturati, la traduzione automatica è passata dai risultati comici a quelli quasi pubblicabili grazie all’intelligenza artificiale, Google ha messo nero su bianco regole molto precise su URL e hreflang e WordPress stesso ha inserito il multilingua nella propria roadmap ufficiale. In questo articolo provo a rimettere ordine, raccontandoti quali strade hai davanti, come gestire la SEO internazionale senza farti male e che cosa aspettarti, realisticamente, dal core.

Tre modi di fare WordPress multilingua oggi

Oggi un sito WordPress multilingua si costruisce in tre modi: con un plugin che gestisce più lingue dentro la stessa installazione, con una rete multisite in cui ogni lingua è un sito separato, oppure combinando uno dei due approcci con un flusso di traduzione assistito dall’AI. L’idea del 2009 di mettere tutte le lingue nello stesso campo, separate da marcatori, è invece tramontata, e per ottime ragioni: rendeva fragile il database, complicava le ricerche e produceva pagine in cui la lingua non era mai davvero una sola.

Un plugin sullo stesso sito

È la strada più battuta, e i due nomi che incontrerai più spesso sono Polylang e WPML. Polylang è disponibile gratuitamente su wordpress.org, dove oggi dichiara oltre 900.000 installazioni attive: ogni traduzione è un articolo, una pagina o un termine a sé stante, collegato agli altri della stessa «famiglia», e la lingua può essere indicata con un codice nell’URL, con un sottodominio o con un dominio diverso per ciascuna lingua. WPML è invece un plugin commerciale, distribuito dal proprio sito e non dalla directory ufficiale, molto diffuso soprattutto nei progetti che includono un e-commerce e molte stringhe di tema e plugin da tradurre.

Il vantaggio di questo approccio è che resti dentro una sola installazione, con un solo pannello, un solo set di plugin e un solo aggiornamento da fare; lo svantaggio è che tutto il sito dipende da un componente esterno molto invasivo, che tocca query, URL e menu, e da cui, una volta entrato, è piuttosto faticoso uscire.

Una rete multisite

Con il multisite ogni lingua diventa un sito della rete, con i propri contenuti, i propri utenti e, se serve, anche un tema configurato in modo diverso, mentre il collegamento fra le traduzioni viene affidato a un plugin dedicato. È la scelta che preferisco quando le versioni linguistiche non sono semplici traduzioni ma veri e propri siti locali, con redazioni diverse, prodotti diversi e calendari editoriali che non coincidono, perché ogni team lavora nel proprio spazio senza pestare i piedi agli altri. Il prezzo da pagare è una gestione tecnica più impegnativa e la necessità di verificare con attenzione che tutti i plugin che ti servono siano compatibili con il multisite.

Tradurre con l’AI, ma con una persona che rilegge

La traduzione automatica con l’intelligenza artificiale è oggi uno strumento serio, a patto che il risultato venga riletto da qualcuno che conosce la lingua e il settore prima della pubblicazione. Gli stessi plugin la stanno integrando: WPML offre un proprio motore di traduzione automatica basato sull’AI, mentre Polylang Pro propone la traduzione automatica con DeepL. Con WordPress 7.0 e la sua AI nativa, inoltre, chi sviluppa ha a disposizione un client indipendente dal fornitore con cui costruire flussi di traduzione su misura, magari con un glossario aziendale e uno stato di revisione obbligatorio prima della pubblicazione.

Dal punto di vista di Google tradurre automaticamente non è un peccato in sé: a giugno 2025 è stato rimosso dalla documentazione sui siti multilingua il vecchio consiglio di bloccare con robots.txt le pagine tradotte in automatico, per allinearla alle spam policy. Le stesse spam policy, però, considerano scaled content abuse la produzione di molte pagine con lo scopo principale di manipolare il ranking, citando espressamente la traduzione automatica di contenuti altrui fra le tecniche di offuscamento. Il confine, insomma, non è lo strumento ma il valore che aggiungi.

L’AI traduce le parole, ma è una persona che sa se quella frase funziona davvero per un cliente tedesco: valuta, unità di misura, riferimenti normativi e tono di voce non si correggono da soli.

Nella pratica il flusso che consiglio è semplice: traduzione automatica come prima bozza, glossario dei termini che non devono mai cambiare (nomi di prodotto, claim, termini legali), revisione umana obbligatoria per le pagine che vendono o che hanno valore legale e controlli a campione sul resto. Chi vuole spingersi oltre può automatizzare anche i passaggi intermedi con gli strumenti di cui parlo nella categoria intelligenza artificiale, purché l’ultima parola resti a una persona.

SEO multilingua: un URL per lingua e hreflang

Per la SEO multilingua la regola d’oro è una sola: ogni versione linguistica deve avere un proprio URL, e le versioni equivalenti devono dichiararsi a vicenda con l’attributo hreflang. Google sconsiglia esplicitamente di cambiare la lingua del contenuto con cookie o impostazioni del browser sullo stesso indirizzo, e ricorda che la lingua di una pagina viene riconosciuta dal contenuto visibile, non dall’attributo lang né dall’URL: meglio quindi una sola lingua per pagina, testo e navigazione compresi, ed evitare le traduzioni affiancate.

Per la struttura degli URL hai tre opzioni valide: le sottocartelle (example.com/de/), facili da configurare e da mantenere; i sottodomini (de.example.com); i domini nazionali (example.de), che danno un segnale geografico chiaro ma costano di più e valgono per un solo paese. Fra sottocartelle e sottodomini Google dichiara di non avere preferenze, mentre sconsiglia i parametri del tipo ?lang=de.

Le regole di hreflang sono poche ma rigide: ogni versione deve elencare se stessa e tutte le altre, con URL assoluti comprensivi di protocollo; i collegamenti devono essere reciproci, altrimenti vengono ignorati; i codici seguono lo standard ISO 639-1 per la lingua e, facoltativamente, ISO 3166-1 alpha-2 per il paese, per cui si scrive en-GB e non en-UK; il valore x-default indica la pagina da mostrare a chi parla una lingua che non hai previsto, tipicamente il selettore della lingua.

<!-- Lo stesso blocco va nel <head> di tutte e tre le versioni -->
<link rel="alternate" hreflang="it" href="https://example.com/chi-siamo/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/about-us/" />
<link rel="alternate" hreflang="de" href="https://example.com/de/uber-uns/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/about-us/" />

I tag si possono dichiarare nel <head>, negli header HTTP o nella sitemap XML, e i tre metodi sono equivalenti, per cui non serve usarli tutti. I plugin multilingua più diffusi generano questi tag in automatico, ma il mio consiglio è di verificarli comunque nel sorgente di qualche pagina, perché basta una traduzione in bozza o una pagina in noindex per rompere la reciprocità. Infine, niente redirect automatici in base all’IP o alla lingua del browser: Googlebot scansiona soprattutto dagli Stati Uniti e senza indicare una lingua preferita, e rischierebbe di non vedere mai le altre versioni. Molto meglio un banner discreto che suggerisce la lingua e lascia scegliere all’utente.

E il multilingua nel core di WordPress?

Il multilingua nativo è la fase 4 del progetto Gutenberg, ma a oggi non ha una data di rilascio. La roadmap ufficiale di WordPress descrive le quattro fasi (editing, personalizzazione, collaborazione e multilingua) e indica la quarta semplicemente come implementazione nel core per i siti multilingua, senza calendario; la prossima release in programma, la 7.2, è indicata per il 10 dicembre 2026 con la consueta avvertenza che le date sono soltanto orientative.

WordPress 7.0, come avevo raccontato nell’articolo dedicato, ha portato l’AI nel core ma non il multilingua, che resta un obiettivo dichiarato senza un calendario. Il mio consiglio, quindi, è di non rimandare un progetto in attesa del core: scegli oggi la soluzione più adatta, tieni i contenuti ordinati e ben strutturati, e quando la fase 4 arriverà davvero valuterai con calma un’eventuale migrazione, che sarà tanto più semplice quanto più pulito sarà il tuo sito.

Come scegliere, in pratica

La scelta giusta dipende meno dalla tecnologia e più dall’organizzazione: prima di installare qualsiasi cosa conviene rispondere ad alcune domande molto concrete, che di solito pongo anche ai clienti nella prima call.

1. Quante lingue ti servono oggi e quante fra due anni? Con due o tre lingue un plugin basta e avanza, con mercati molto diversi il multisite comincia ad avere senso.
2. Le versioni sono traduzioni o siti diversi? Se i contenuti divergono, separarli fin dall’inizio ti eviterà molti compromessi.
3. Chi traduce e chi rilegge? Definisci un responsabile per lingua, anche se la prima bozza la scrive l’AI.
4. C’è un e-commerce? Prezzi, valute, spedizioni e testi legali richiedono verifiche di compatibilità molto più accurate, e se il negozio è su WooCommerce ne parlo nella pagina sulla consulenza WooCommerce.
5. Come misurerai i risultati? Ogni lingua dovrebbe avere obiettivi e report separati, come spiego nell’articolo su come misurare un sito oggi.

Tirando le somme

In diciassette anni il multilingua su WordPress è passato dai separatori infilati nei campi a soluzioni mature, la traduzione automatica è diventata uno strumento di lavoro credibile e la SEO internazionale ha regole chiare, che premiano chi organizza bene URL e hreflang e penalizzano chi produce pagine in serie senza valore. Il core, prima o poi, arriverà; nel frattempo un plugin solido o una rete multisite ben progettata, insieme a una revisione umana delle traduzioni, restano la combinazione vincente.

Se vuoi approfondire ti consiglio di partire dalla documentazione di Google sulle versioni localizzate delle pagine e di dare un’occhiata agli altri articoli della categoria WordPress. E se hai una storia di siti multilingua da raccontare, magari con qualche disastro di traduzione automatica degno di nota, scrivila nei commenti e condividi l’articolo con chi sta per avventurarsi nella stessa impresa. Se invece vuoi una mano a progettare il tuo, puoi prenotare una call conoscitiva gratuita o passare dai contatti.