WPML: guida completa per creare un sito WordPress multilingua

WPML è un plugin premium per trasformare WordPress in un sistema multilingua, gestendo da un’unica installazione pagine, articoli, tassonomie, menu, stringhe di temi e plugin e, con i moduli appropriati, anche WooCommerce, Elementor e contenuti dinamici.

Il suo punto di forza non è semplicemente “tradurre WordPress”. WPML costruisce una relazione tra il contenuto originale e le relative versioni linguistiche e permette di decidere come organizzare le lingue, chi può tradurre, quali contenuti automatizzare e quali revisionare manualmente.

Questo lo rende particolarmente interessante quando il progetto supera il classico sito con poche pagine e due lingue. Su un sito aziendale, un ecommerce o un portale con molti contenuti, infatti, il problema non è soltanto produrre una traduzione: bisogna mantenere sincronizzati template, URL, menu, prodotti, metadati SEO e modifiche successive.

WPML affronta questo flusso attraverso un plugin principale e una serie di componenti aggiuntivi. La configurazione effettiva dipende quindi dal piano scelto e dal tipo di sito.

In questa guida vediamo come funziona WPML nella pratica, come configurarlo, come gestisce la traduzione automatica, cosa cambia con WooCommerce ed Elementor, quali sono i costi e soprattutto quali aspetti devi controllare prima di adottarlo su un progetto WordPress complesso.

WPML: cos’è, come funziona e quando conviene usarlo

WPML è una soluzione multilingua per WordPress sviluppata da OnTheGoSystems. Il componente centrale è WPML Multilingual CMS, al quale possono affiancarsi moduli dedicati alla traduzione delle stringhe, all’ecommerce, ai campi personalizzati e ad altre integrazioni.

La logica è diversa da quella di un semplice traduttore automatico inserito sopra il sito. Ogni lingua viene gestita come parte della struttura WordPress: i contenuti tradotti restano collegati agli originali e possono avere URL, titoli, metadati e testi specifici.

Questo permette, ad esempio, di avere una pagina italiana e la relativa versione inglese mantenendo la relazione tra le due. Quando intervieni sul contenuto originale, il sistema può inoltre segnalare che la traduzione deve essere aggiornata.

La stessa logica si estende a post, custom post type, tassonomie e, a seconda dei moduli installati, stringhe di temi e plugin, prodotti WooCommerce e contenuti creati con page builder.

Quando WPML ha senso e quando può essere eccessivo

La suite dà il meglio nei progetti in cui la gestione delle traduzioni è parte del workflow editoriale, non una funzione occasionale.

Un sito aziendale con molte pagine, un ecommerce con catalogo internazionale, un progetto costruito con Elementor o ACF oppure un sito gestito da più persone beneficia maggiormente di un sistema centralizzato per stabilire cosa tradurre e con quale metodo.

Per un piccolo sito con poche pagine e traduzioni gestite interamente a mano, invece, una struttura così articolata può essere superiore alle necessità reali. WPML non dispone inoltre di una normale versione gratuita equivalente ai piani CMS o Agency: bisogna quindi mettere nel conto sia il costo della licenza sia il tempo necessario per configurare correttamente il progetto.

Qui sta la distinzione importante: più funzioni non significano automaticamente una scelta migliore. La soluzione corretta dipende da numero di lingue, complessità dei contenuti, integrazioni WordPress e modo in cui le traduzioni dovranno essere mantenute nel tempo.

WPML, Polylang e TranslatePress: le differenze essenziali

WPML non è l’unico approccio possibile a un sito WordPress multilingua. Polylang e TranslatePress, per esempio, affrontano lo stesso problema con workflow differenti.

Più che stabilire quale plugin sia “il migliore” in assoluto, conviene guardare al modo in cui vuoi lavorare. WPML è particolarmente orientato alla gestione strutturata di traduzioni, traduttori, automazione e integrazioni con altri componenti WordPress. Altre soluzioni possono risultare più immediate quando il progetto è piccolo o quando si preferisce intervenire direttamente sul frontend.

Per questa ragione eviterei di scegliere in base a una semplice tabella di stelline. Il criterio decisivo è quanto il modello di traduzione del plugin coincide con l’architettura del sito e con il workflow di chi lo deve mantenere.

Come installare e configurare WPML

L’installazione non consiste più soltanto nel caricare uno ZIP e attivare il plugin. La procedura ufficiale di configurazione utilizza OTGS Installer per registrare il sito e installare i componenti necessari alla configurazione scelta.

Prima di partire conviene però verificare l’ambiente WordPress. Un sito multilingua aggiunge contenuti, relazioni e operazioni al progetto esistente: eventuali problemi di memoria, plugin incompatibili o personalizzazioni fragili diventano più difficili da diagnosticare dopo aver introdotto una seconda o terza lingua.

Requisiti tecnici, compatibilità e staging

Secondo i requisiti tecnici ufficiali di WPML, la configurazione corrente richiede WordPress 6.0 o superiore, PHP da 7.4 a 8.5 e almeno 128 MB di memoria WordPress; il vendor raccomanda 256 MB.

Sono inoltre richiesti MySQL 5.6 o MariaDB 10.1 come minimo, REST API WordPress funzionante e alcune estensioni PHP utilizzate dal plugin.

Questi sono requisiti minimi, non una garanzia che qualsiasi combinazione di tema, plugin e codice personalizzato funzioni senza verifiche. Se il sito utilizza WooCommerce, un page builder, sistemi di cache, custom post type o integrazioni sviluppate ad hoc, lo staging rimane la scelta più prudente per installazioni e aggiornamenti importanti.

Prima di intervenire su un sito in produzione conviene quindi eseguire un backup completo e verificare sia la compatibilità dichiarata sia gli eventuali known issues dei componenti più critici.

Guida passo-passo all’installazione su WordPress

1. Accedi al tuo account WPML e scarica OTGS Installer dalla sezione Download.
2. In WordPress vai su Plugin → Aggiungi nuovo plugin, carica il file ZIP e attiva OTGS Installer.
3. Registra il sito utilizzando la site key associata al dominio. La registrazione è necessaria per ricevere i componenti e gli aggiornamenti previsti dal tuo account.
4. Installa i componenti necessari al progetto. Non tutti i siti richiedono necessariamente ogni add-on disponibile.
5. Avvia il wizard WPML e verifica con attenzione la lingua originale del sito prima di aggiungere quelle secondarie.
6. Scegli la struttura degli URL e il metodo con cui vuoi gestire le traduzioni.
7. Prima di tradurre in massa, prova il workflow su alcune pagine rappresentative e verifica frontend, menu, template, form, dati dinamici e metadati SEO.

Questa ultima verifica è particolarmente importante. Automatizzare migliaia di stringhe prima di avere stabilizzato la configurazione può moltiplicare un errore che sarebbe stato semplice correggere su un campione limitato.

Lingue, struttura URL e selettore della lingua

WPML permette di organizzare le lingue in directory, utilizzare domini o sottodomini differenti oppure aggiungere la lingua come parametro nell’URL.

Una struttura potrebbe quindi assumere forme come example.com/en/, en.example.com oppure un dominio specifico per il mercato.

Il formato corretto va deciso in base al progetto, non scegliendo automaticamente quello che “fa più SEO”. Come vedremo più avanti, Google raccomanda URL distinti per le diverse versioni linguistiche; il modo esatto con cui organizzarli deve però tenere conto anche di infrastruttura, gestione dei domini e strategia internazionale.

Il selettore della lingua può essere collocato in menu, footer, aree widget, contenuti e template. Dal punto di vista dell’utente è un dettaglio apparentemente semplice, ma diventa parte dell’architettura di navigazione: deve permettere di passare dalla pagina corrente alla sua reale versione tradotta, non semplicemente riportare ogni volta alla homepage.

Traduzione automatica con WPML: motori, PTC e crediti

La traduzione automatica è uno dei settori in cui WPML è cambiato maggiormente.

La piattaforma permette di combinare traduzione manuale, traduttori assegnati al progetto e motori automatici. Attualmente integra Private Translation Cloud (PTC), DeepL, Google Translate e Microsoft Translator.

PTC è il motore che WPML propone come predefinito, mentre gli altri possono essere selezionati modificando le preferenze della traduzione automatica.

La scelta non cambia soltanto il motore linguistico: cambia anche il consumo dei crediti.

Come funzionano realmente i crediti

I crediti non corrispondono direttamente a un numero fisso di parole. WPML li usa come unità di calcolo e ogni motore applica un consumo differente.

Motore	Crediti per parola
PTC	4
DeepL	2
Google Translate	2
Microsoft Translator	1

Questo significa che 90.000 crediti non equivalgono automaticamente a 90.000 parole tradotte. Il numero effettivo dipende dal motore utilizzato e anche dal numero di lingue verso cui traduci lo stesso contenuto.

WPML mette a disposizione sia crediti prepagati sia un sistema Pay-As-You-Go. La pagina ufficiale sui costi della traduzione automatica permette di verificare quantità e prezzi correnti prima di avviare lavori di grandi dimensioni.

Questa distinzione è importante nei progetti editoriali ed ecommerce. Tradurre automaticamente tutto il sito senza prima stimare contenuti, lingue e motore può produrre costi molto differenti da quelli intuitivamente suggeriti dal semplice conteggio delle parole.

Traduzione automatica, manuale e workflow ibrido

L’automazione è utile soprattutto quando devi processare un volume elevato di contenuti, ma non elimina la necessità di una strategia di revisione.

Pagine istituzionali, articoli informativi standard o cataloghi molto strutturati possono essere buoni candidati per una prima traduzione automatica. Landing page, messaggi commerciali, documentazione tecnica delicata e testi con forte componente culturale meritano invece un controllo più attento.

Il punto non è stabilire che una tecnologia automatica sia sempre sufficiente o sempre insufficiente. Dipende dal rischio dell’errore.

Un refuso in una descrizione secondaria ha un impatto diverso da una traduzione sbagliata in termini contrattuali, istruzioni di sicurezza, condizioni commerciali o documenti con implicazioni legali.

In un workflow professionale la soluzione più efficace può quindi essere ibrida: automazione dove riduce il lavoro ripetitivo e revisione umana nei contenuti in cui terminologia, tono o precisione possono cambiare il significato.

Cosa cambia con WPML 5.0 e cosa è ancora in beta

La generazione stabile corrente appartiene ancora alla linea 4.9, mentre WPML 5.0 è disponibile in beta. È importante tenere separate le due cose.

La beta riorganizza in modo significativo l’esperienza di traduzione e rende Translate Everything Automatically il metodo predefinito per i nuovi siti. Introduce inoltre controlli più chiari sui contenuti da includere nell’automazione e sulla stima del costo prima di avviare il processo.

Sono sviluppi rilevanti, ma finché la release resta beta non li userei come base per un sito di produzione senza una verifica specifica.

Le istruzioni operative di questa guida fanno quindi riferimento al comportamento stabile corrente; le novità della 5.0 servono a capire la direzione del prodotto, non a presentare funzioni in beta come già consolidate per tutti gli utenti.

WPML e WooCommerce: multilingua per ecommerce

Un negozio WooCommerce complica sensibilmente il problema della traduzione. Non ci sono soltanto pagine e articoli, ma prodotti, variazioni, categorie, attributi, checkout, email, valute e sistemi di pagamento.

Per questi progetti WPML utilizza WPML Multilingual & Multicurrency for WooCommerce, spesso indicato anche come WCML.

Il modulo collega le traduzioni dei prodotti alla struttura WooCommerce e consente di gestire contenuti come categorie, attributi, cart e checkout, email e recensioni. Il catalogo resta quindi parte dello stesso negozio, mentre le versioni linguistiche vengono mantenute in relazione fra loro.

Se vuoi approfondire il funzionamento della piattaforma ecommerce prima di aggiungere il livello multilingua, trovi una guida dedicata a WooCommerce e alla sua architettura.

Prodotti, varianti, checkout ed email

Quando invii un prodotto alla traduzione, il lavoro non riguarda soltanto titolo e descrizione. Possono entrare nel processo anche variazioni, termini degli attributi, categorie, tag e testi associati alle immagini.

Questo è uno dei motivi per cui un ecommerce multilingua va progettato prima di lanciare la traduzione massiva.

Se la tassonomia del catalogo è incoerente nella lingua originale, la traduzione non risolve il problema: lo replica nelle altre lingue. Lo stesso accade con attributi duplicati, categorie poco chiare e contenuti di prodotto non standardizzati.

Prima di tradurre centinaia di prodotti conviene quindi stabilizzare il catalogo originale e testare almeno un prodotto semplice, uno variabile e un percorso completo fino al checkout.

Multicurrency, prezzi e gateway: cosa gestisce realmente il modulo

WCML può aggiungere più valute, applicare tassi di cambio automatici o manuali, configurare prezzi differenti per valuta e controllare la disponibilità di alcuni metodi di pagamento in base alla valuta o alla localizzazione.

Lingua, valuta e fiscalità non sono però la stessa cosa.

Mostrare euro a un utente italiano e sterline a uno britannico è una funzione di multicurrency; determinare correttamente IVA, tassazione, obblighi documentali e condizioni di vendita dipende invece dalla configurazione WooCommerce, dagli altri strumenti installati e dalle norme applicabili all’attività.

WPML non deve quindi essere interpretato come un sistema che rende automaticamente conforme un ecommerce alle regole fiscali o legali di tutti i mercati.

WPML con Elementor, Gutenberg e page builder

I page builder hanno reso la gestione multilingua più delicata perché il testo non vive sempre nel normale editor di WordPress. Può essere memorizzato dentro widget, template, sezioni globali e campi dinamici.

WPML dispone di integrazioni dedicate per diversi builder. Nel caso di Elementor, il workflow permette di tradurre pagine, post e altri contenuti mantenendo la struttura progettata nel builder.

La documentazione WPML per Elementor descrive un processo basato sulla Translation Dashboard: selezioni il contenuto, scegli il metodo di traduzione e lavori sulle parti testuali senza dover ricostruire manualmente il layout per ogni lingua.

Elementor, template e contenuti dinamici

Con i piani CMS e Agency il supporto si estende a funzioni più articolate di Elementor, comprese traduzione automatica e gestione di template, header e footer.

Qui è utile distinguere il contenuto dalla struttura.

Se un template deve avere lo stesso layout in tutte le lingue, conviene mantenere quella relazione e tradurre soltanto gli elementi necessari. Se invece una determinata lingua richiede una composizione realmente diversa, Elementor Pro e WPML consentono anche workflow specifici per collegare template differenti.

Non trasformerei però questa possibilità in una regola. Mantenere un design diverso per ogni mercato aumenta anche il lavoro di manutenzione: quando cambi il template principale, devi ricordarti che esistono varianti linguistiche che potrebbero richiedere lo stesso intervento.

Full Site Editing e Block Editor

Il supporto al Full Site Editing permette ai piani che lo includono di lavorare anche con template e template part costruiti con il Site Editor di WordPress.

Questo interessa soprattutto header, footer, navigazione e componenti globali dei temi a blocchi.

Il principio resta lo stesso: prima si stabilisce quali elementi appartengono alla struttura condivisa e quali devono avere un contenuto realmente localizzato. Tradurre indiscriminatamente ogni elemento globale aumenta il numero di contenuti da mantenere senza necessariamente produrre un vantaggio per l’utente.

Campi personalizzati e ACF

Nei siti più evoluti una parte consistente del contenuto può provenire dai custom field. In questo caso la traduzione deve sapere quali dati vanno tradotti e quali, invece, devono rimanere identici tra le lingue.

Per Advanced Custom Fields esiste l’add-on ACF Multilingual, che permette di definire il comportamento dei campi nelle diverse versioni linguistiche.

Un campo testuale può richiedere una traduzione, mentre un ID, un’impostazione tecnica o un riferimento strutturale potrebbe dover essere copiato. La scelta sbagliata può creare contenuti incoerenti o rompere relazioni usate dal template.

Se utilizzi ACF in modo esteso, conviene quindi progettare questa logica insieme alla struttura dei campi personalizzati di Advanced Custom Fields anziché configurarla a posteriori.

Piani WPML: Blog, CMS o Agency

WPML viene venduto in tre piani: Multilingual Blog, Multilingual CMS e Multilingual Agency.

I prezzi e le funzionalità possono cambiare, quindi per un acquisto conviene sempre controllare la pagina ufficiale dei piani WPML. Attualmente la struttura è questa:

Caratteristica	Multilingual Blog	Multilingual CMS	Multilingual Agency
Prezzo iniziale	€39	€99	€199
Siti production	1	3	Illimitati
Siti development	3	9	Illimitati
Advanced Translation Editor	No	Sì	Sì
Crediti AI inclusi	No	90.000	180.000
String Translation	No	Sì	Sì
Translation Management	No	Sì	Sì
Supporto page builder avanzato	No	Sì	Sì
WooCommerce multilingua	No	Sì	Sì
Full Site Editing	No	Sì	Sì

La differenza più importante non è quindi soltanto quanti siti puoi registrare.

Multilingual Blog è una soluzione molto più essenziale. Può andare bene se vuoi gestire manualmente un sito relativamente semplice e non hai bisogno del sistema completo di traduzione automatica, String Translation, gestione dei traduttori o integrazione ecommerce.

Multilingual CMS è normalmente il punto di ingresso per un vero progetto professionale costruito con page builder, WooCommerce o componenti che generano stringhe esterne al normale contenuto WordPress.

Agency cambia soprattutto la scala: siti di produzione e sviluppo illimitati e una quantità iniziale maggiore di crediti per la traduzione automatica.

Quale piano scegliere nei diversi scenari

Per un blog personale con poche pagine e traduzioni manuali partirei dal piano Blog soltanto se le sue limitazioni sono compatibili con il sito.

Per un sito aziendale realizzato con Elementor, un progetto che utilizza String Translation o un ecommerce sceglierei invece CMS come riferimento iniziale, perché sono proprio le integrazioni aggiuntive a rendere utile l’ecosistema completo.

Agency ha senso quando una stessa licenza deve coprire molti progetti. È quindi molto più naturale per agenzie, sviluppatori e professionisti che gestiscono siti di clienti rispetto al proprietario di un singolo sito.

Prima dell’acquisto controllerei comunque il numero di installazioni effettive e il ruolo degli ambienti di sviluppo: scegliere Agency semplicemente perché “ha tutto” non produce un vantaggio se CMS copre già il progetto reale.

WPML e SEO multilingua: URL, hreflang, canonical e sitemap

Tradurre una pagina non significa automaticamente renderla competitiva in un altro mercato.

Una strategia SEO multilingua deve coordinare architettura degli URL, versioni linguistiche, hreflang, canonical, metadati e contenuto effettivamente localizzato.

Google raccomanda URL distinti per le differenti versioni linguistiche. WPML può organizzare queste versioni con directory, domini o sottodomini differenti e supporta anche il parametro della lingua.

Per molti progetti directory o domini producono un’architettura più leggibile, ma non esiste una regola secondo cui il parametro supportato dal plugin generi automaticamente una penalizzazione.

Cosa automatizza WPML

Uno dei compiti che WPML può svolgere automaticamente è la generazione delle annotazioni hreflang, utilizzate per descrivere a Google le relazioni tra versioni linguistiche o regionali della stessa pagina.

Se, per esempio, una risorsa esiste in italiano, inglese e tedesco, le annotazioni permettono di dichiarare che non si tratta di tre pagine scollegate, ma di alternative localizzate dello stesso contenuto.

Questo non garantisce una posizione e non sostituisce il lavoro SEO. Aiuta il motore di ricerca a comprendere meglio l’insieme delle versioni disponibili.

Per approfondire l’implementazione tecnica puoi consultare anche la guida Creativemotions dedicata al tag hreflang su WordPress.

WPML dispone inoltre di integrazioni con plugin SEO come Yoast SEO e Rank Math attraverso WPML SEO, rendendo traducibili elementi come titoli SEO, meta description e altri dati gestiti dal plugin SEO.

Canonical e hreflang non svolgono lo stesso lavoro

Un errore frequente consiste nel trattare canonical e hreflang come strumenti alternativi.

Non lo sono.

Il canonical comunica quale URL deve essere considerato canonico all’interno di un insieme di contenuti duplicati o molto simili. hreflang descrive invece le relazioni tra varianti linguistiche o regionali.

Nella sua documentazione sul canonical, Google specifica che, quando si utilizza hreflang, la pagina canonica dovrebbe essere nella stessa lingua, quando disponibile.

Per questo non imposterei automaticamente tutte le versioni tradotte come canonical della pagina originale. Se le pagine italiana, inglese e tedesca sono versioni indicizzabili autonome, la configurazione deve rispettare questa architettura.

Cosa devi comunque decidere a livello SEO ed editoriale

Il plugin risolve una parte tecnica importante, ma non può decidere la strategia di ricerca di ogni mercato.

Una traduzione letterale del title italiano potrebbe non corrispondere alle query utilizzate in Germania. La pagina che funziona bene per un pubblico italiano potrebbe richiedere esempi diversi per un utente statunitense. Anche terminologia commerciale, CTA e struttura della pagina possono cambiare.

SEO multilingua e traduzione linguistica si sovrappongono, ma non coincidono.

Il vantaggio di WPML è permetterti di gestire versioni differenti dello stesso contenuto. Sta poi alla strategia editoriale utilizzare questa possibilità per produrre pagine realmente adatte al mercato di destinazione.

Traduzione di stringhe, menu e contenuti dinamici

Non tutto il testo visibile di un sito WordPress appartiene a una pagina o a un articolo.

Messaggi dei form, etichette dei plugin, impostazioni del tema, testi del checkout e altri elementi possono provenire dal database, dai file del tema o direttamente da un plugin.

Per questi casi WPML mette a disposizione String Translation.

Il sistema permette di individuare e tradurre stringhe che non compaiono nel normale editor dei contenuti e rappresenta una delle differenze più importanti tra un sito multilingua elementare e uno con molti componenti dinamici.

String Translation e testi di temi e plugin

Le versioni recenti del componente puntano sulla registrazione automatica delle stringhe effettivamente incontrate nel frontend, in modo da evitare di caricare indiscriminatamente ogni testo disponibile.

Quando una stringa non compare, è possibile intervenire con gli strumenti di localizzazione e scansione di tema e plugin.

Esiste anche il rilevamento delle stringhe presenti in file JavaScript, utile per alcuni componenti dinamici. La stessa documentazione WPML avverte però che questa funzione può incidere sulle prestazioni e consiglia di disattivarla una volta completata l’individuazione dei testi necessari.

È un buon esempio del motivo per cui non conviene considerare String Translation come un grande pulsante “traduci tutto”. Più selettiva è la configurazione, più semplice rimane capire da dove arriva un testo e come deve essere mantenuto.

Menu, widget e componenti dinamici

La stessa attenzione vale per menu e widget.

In alcuni progetti la struttura di navigazione deve essere identica in tutte le lingue e cambiano soltanto etichette e destinazioni. In altri casi un mercato può richiedere pagine che non esistono nella lingua principale e quindi una navigazione differente.

WPML permette di gestire questi scenari, ma una sincronizzazione automatica non deve sostituire la decisione editoriale.

Prima di pubblicare una nuova lingua conviene navigare realmente il sito come farebbe un utente: homepage, menu, pagina interna, form, ricerca, eventuale area riservata e, per WooCommerce, percorso prodotto-carrello-checkout.

È proprio in questi elementi secondari che emergono più facilmente stringhe rimaste nella lingua originale.

Limiti di WPML: complessità, performance e compatibilità

WPML può gestire progetti molto articolati, ma questa completezza ha un costo in termini di complessità.

Aggiungere una lingua significa aumentare il numero di contenuti e relazioni da gestire. Due lingue non equivalgono semplicemente a “due volte il testo”: entrano in gioco menu, metadati, tassonomie, stringhe, template, prodotti e aggiornamenti successivi.

Questo rende particolarmente importante la manutenzione.

Più componenti significano più punti da verificare

Tema, plugin SEO, page builder, ecommerce, cache e custom code possono interagire con la gestione multilingua.

La presenza di una compatibilità dichiarata è un ottimo punto di partenza, ma non la interpreterei come garanzia assoluta per qualsiasi combinazione di versioni e configurazioni.

Prima degli aggiornamenti importanti conviene verificare changelog e known issues dei componenti critici e testare il flusso in staging quando il sito ha un valore commerciale significativo.

Lo stesso principio vale per nuove traduzioni automatiche: prima di processare un intero archivio, controlla alcune pagine reali, il consumo previsto dei crediti e il risultato sul frontend.

WPML rallenta WordPress?

Non esiste una risposta corretta che valga per qualsiasi sito.

Una configurazione multilingua aggiunge inevitabilmente dati e logica rispetto allo stesso progetto monolingua. Questo non significa che WPML debba rendere un sito lento, ma significa che tema, query, database, cache, hosting e quantità di contenuti continuano a contare.

Attribuire automaticamente un problema di performance al plugin sarebbe quindi superficiale quanto sostenere che non possa mai avere alcun impatto.

Su un progetto grande misurerei il sito prima e dopo l’introduzione del livello multilingua, controllando soprattutto pagine rappresentative, query anomale, cache e funzionalità che cambiano comportamento in base alla lingua.

Supporto, aggiornamenti e licenza WPML

La licenza WPML è legata a un account annuale. Le condizioni ufficiali includono un anno di aggiornamenti e accesso al supporto.

La registrazione del sito avviene tramite una site key e il numero di siti che puoi collegare dipende dal piano acquistato.

Questa distinzione è importante soprattutto per chi lavora con staging e migrazioni: Blog permette un sito production e tre development, CMS tre production e nove development, mentre Agency prevede registrazioni illimitate entro le condizioni di utilizzo previste dal vendor.

Cosa succede se non rinnovi

Se lasci scadere l’abbonamento, WPML può continuare a funzionare sui siti già registrati, ma perdi gli aggiornamenti e l’accesso al supporto e non puoi registrare nuove installazioni o effettuare determinate nuove registrazioni dopo cambi di URL.

È una differenza importante rispetto all’idea che il sito smetta immediatamente di funzionare.

Il problema vero è il medio periodo: WordPress, PHP, WooCommerce e gli altri plugin continuano ad aggiornarsi. Un componente multilingua rimasto fermo può quindi diventare progressivamente incompatibile o esporre problemi già risolti nelle versioni successive.

Per un sito aziendale o ecommerce manterrei perciò la licenza attiva finché WPML rimane parte dell’infrastruttura del progetto.

Conclusione

WPML ha senso quando il sito multilingua deve essere gestito come un sistema, non semplicemente tradotto una volta.

Il vantaggio reale emerge quando devi coordinare più lingue con WordPress, Elementor, WooCommerce, campi personalizzati, traduzione automatica, traduttori e SEO internazionale. In questi scenari una struttura centralizzata riduce molto lavoro manuale e rende più controllabile l’evoluzione delle versioni linguistiche.

La stessa completezza rende però il plugin più impegnativo di una soluzione minimale. Configurazione degli URL, traduzioni, crediti, compatibilità e manutenzione devono essere pensati prima di premere “traduci tutto”.

Per un piccolo sito con poche pagine e due traduzioni manuali valuterei anche soluzioni più semplici. Per un ecommerce, un sito aziendale strutturato o un progetto sviluppato con page builder e contenuti dinamici, WPML rimane invece una delle opzioni da valutare con maggiore attenzione, soprattutto se serve un workflow multilingua integrato direttamente in WordPress.

Se il punto critico non è scegliere il plugin ma configurarlo senza compromettere struttura, template, ecommerce o indicizzazione, il nostro servizio di assistenza WordPress comprende anche interventi su installazioni e configurazioni multilingua.