Mettere WordPress in multilingua è già un bel passo. Farlo bene in modalità multilingua + multi-country senza incasinare codice, SEO e performance… è tutta un’altra storia.

Aggiungi lingue, aggiungi paesi, aggiungi varianti di contenuto e in un attimo ti ritrovi con URL duplicati, template ingestibili, traduzioni che spariscono, hreflang messi a caso e un backend che nessuno vuole più toccare.

In questo articolo ti porto dietro le quinte di come gestisco la parte tecnica in PHP su WordPress multilingua/multi-country, così capisci cosa va progettato subito e cosa evitare se non vuoi ritrovarti con un mostro ingestibile tra un anno.

Multilingua e multi-country in WordPress: come gestire la parte tecnica in PHP senza problemi

Multilingua e multi-country non sono la stessa cosa

La prima cosa da chiarire è semplice ma fondamentale: multilingua e multi-country non sono la stessa cosa.

Multilingua significa che hai gli stessi contenuti (più o meno) in più lingue: italiano, inglese, spagnolo, tedesco. Multi-country significa che hai contenuti diversi per paese: Italia, Francia, Spagna, Germania, magari anche se usano la stessa lingua. Offerte diverse, referenze diverse, normative diverse, prezzi diversi.

Nella pratica puoi trovarti in tre scenari:

• solo multilingua: it / en / es per lo stesso sito

• solo multi-country: it-IT / it-CH / it-SM con varianti locali

• multilingua + multi-country: it-IT, it-CH, en-GB, en-US, ecc.

Per WordPress e per il tuo codice PHP questo cambia tutto. Se tratti un multi-country come un “semplice multilingua”, rischi di avere:

• un inglese unico che non rispecchia mercati diversi

• un “italiano” uguale per Italia e Svizzera dove magari cambiano IVA, normative o messaggi

• difficoltà a segmentare contenuti e logiche di business per nazione.

Scegliere la struttura URL prima di scrivere una riga di PHP

La struttura degli URL è il primo tassello tecnico serio, anche prima del plugin multilingua.

Hai tre macro strade:

• sottodirectory del tipo /it/, /en/, /fr/

• sottodomini tipo it.sito.com, en.sito.com

• domini separati: sito.it, sito.fr, sito.es

Se ti spingi sul multi-country, spesso conviene ragionare per country:

• sito.it per l’Italia

• sito.fr per la Francia

• sito.es per la Spagna

oppure una struttura tipo sito.com/it-it/, sito.com/it-ch/, sito.com/en-gb/.

Dal punto di vista del PHP, la cosa importante è che la struttura scelta:

• permetta di capire da subito lingua e paese correnti

• sia gestibile via plugin e funzioni custom senza mille if sparsi nei template

• non richieda riscritture manuali con rewrite artigianali ogni volta che aggiungi una lingua.

Quando progetto un multilingua serio, parto sempre da questa domanda: “Come vogliamo che siano gli URL tra cinque anni, non solo domani mattina?”

Plugin multilingua sì, ma con la testa sul PHP

Parliamoci chiaro: oggi nessuno mette in piedi un progetto multilingua complesso “a mano”.  Si usano plugin come WPML, Polylang, TranslatePress e simili. Il problema è che spesso vengono usati “di pancia”, spuntando opzioni e sperando vada tutto bene, senza pensarla dal punto di vista del codice.

Come programmatore PHP mi interessa sapere:

• come il plugin gestisce ID delle traduzioni, relazioni tra post, tassonomie e media

• quali hook ed API mette a disposizione per intervenire in modo pulito

• come gestisce lingua e country correnti (costanti, funzioni, globali, ecc.)

• se è compatibile con i custom post type e i campi personalizzati che useremo

Se si parte senza questa analisi, dopo un po’ ti ritrovi con template pieni di condizioni strane, query non localizzate, widget che mostrano contenuti nella lingua sbagliata e logiche SEO tutte da rifare.

Evitare stringhe hard-coded: il primo passo per non impazzire

Uno degli errori più frequenti è il classico “appiccico il testo nel template PHP e via”.

Nel momento in cui il progetto diventa multilingua, il codice esplode. Ti ritrovi stringhe in italiano ovunque e nessun sistema pulito per gestire le versioni nelle altre lingue.

La prima regola è banale ma salvavita: niente testi hard-coded nei template, se possibile.

Meglio usare:

• funzioni di localizzazione di WordPress (__(), _e(), ecc.) per i testi fissi del tema

• opzioni e campi personalizzati (ACF, opzioni tema, impostazioni plugin) per testi gestiti dal backend

• file di traduzione .po e .mo per theme e plugin

In questo modo il plugin multilingua può fare il suo lavoro, e tu dal lato PHP non devi duplicare template e condizioni all’infinito.

Custom post type, tassonomie e contenuti per paese

Appena smetti di ragionare solo in “pagine e articoli”, arrivano loro: CPT e tassonomie.

Cataloghi, casi studio, sedi, FAQ, servizi, listini: è normale creare custom post type dedicati. In un multilingua/multi-country devi decidere se:

• un CPT è condiviso tra tutti i paesi

• ogni paese ha i suoi contenuti separati

• alcune tassonomie sono globali e altre locali

Da qui nascono logiche in PHP del tipo:

• mostrare solo le sedi del paese corrente

• filtrare le case studies per lingua + mercato

• cambiare esempi e referenze in base al country dell’utente

Se questo non viene pensato subito, ti ritrovi a fare “patch” dopo, con query personalizzate buttate dentro shortcodes o template in modo poco controllato.

Quando progetto un sito multi-country cerco sempre di:

• avere tassonomie che rappresentano il country

• avere CPT pensati per poter essere filtrati da lingua e paese

• usare funzioni PHP pulite per recuperare ciò che mi serve, invece di query copia-incolla.

Hreflang e SEO tecnica: meglio PHP che plugin a casaccio

In un multilingua serio non puoi ignorare gli hreflang. Sono quelli che dicono a Google quali versioni di una pagina esistono per lingue e paesi diversi.

Molti plugin li gestiscono automaticamente, ma quando cominci a spingere sulla parte multi-country (it-IT, it-CH, en-GB, en-US, ecc.) spesso servono logiche più fini.

Qui il PHP entra in gioco per:

• costruire l’elenco completo delle varianti di una pagina

• gestire casi particolari (pagine che esistono in alcune lingue ma non in altre)

• generare hreflang coerenti anche su template custom, archivi e pagine dinamiche

In alcuni progetti scrivo direttamente funzioni che, in base alla lingua/country corrente e alle relazioni tra contenuti, generano il blocco hreflang da inserire nel <head>. Così evito di affidarmi ciecamente a plugin che non conoscono le specifiche esigenze del cliente.

Geolocalizzazione, scelta lingua e country: non esagerare con la “magia”

Quando si parla di multi-country, parte sempre l’idea: “Facciamo che il sito capisce da solo da dove arriva l’utente e lo manda alla versione giusta”.

Bello, ma va maneggiato con cura.

Dal lato PHP e WordPress puoi:

• usare servizi di geolocalizzazione per suggerire una lingua/paese, non per forzare tutto

• mostrare un popup di scelta lingua/country pre-selezionato in base alla posizione

• ricordare le preferenze dell’utente tramite cookie o sessione

L’errore è farsi prendere la mano e:

• redirect in automatico senza via d’uscita

• bloccare i motori di ricerca con logiche lato IP

• creare conflitti tra URL “canonici” e versioni geolocalizzate

Nella pratica cerco sempre di usare la geolocalizzazione come un aiuto, non come qualcosa che “decide al posto dell’utente”.

Performance e caching in un sito con più lingue e paesi

Altro tema delicato: caching e performance.

Ogni lingua e ogni country spesso ha:

• menu diversi

• contenuti diversi

• blocchi di pagina condizionati

Se il caching non è configurato bene, rischi di:

• mostrare una lingua a utenti di un’altra

• servire menu sbagliati

• mescolare varianti di contenuto

Quando lavoro sul PHP di un sito multilingua/multi-country, tengo sempre presenti due cose:

• il modo in cui il plugin multilingua gestisce le pagine (parametri, percorsi, cookie)

• come il sistema di cache (plugin o layer server) differenzia le versioni

Su siti più complessi può avere senso usare header e variazioni per lingua/country, in modo che il server sappia che esistono più versioni della stessa pagina e le gestisca in modo corretto.

Come affronto un progetto multilingua/multi-country come programmatore PHP

Quando qualcuno mi chiede aiuto su un multilingua WordPress che sta diventando ingestibile, non parto mai da “aggiungiamo una lingua e via”. Parto da domande molto terra terra:

• Come vendi e a chi, paese per paese?
• Quali contenuti devono cambiare davvero per mercato e quali possono essere solo tradotti?
• Quali strumenti esterni usi (CRM, marketing, booking, e-commerce) che devono dialogare con il sito?
• Che struttura URL vogliamo avere tra due anni?

Da lì analizzo la base tecnica: plugin multilingua, tema, CPT, tassonomie, stato del codice.

Solo dopo propongo una strategia:

• ripulire dove serve
• standardizzare logiche in PHP
• centralizzare le funzioni multi-country invece di spargerle qua e là
• impostare un flusso chiaro per chi inserisce e traduce contenuti.

L’obiettivo non è solo “essere multilingua”, ma avere un sito che puoi gestire e far crescere, senza tremare ogni volta che aggiungi un paese, una lingua o una nuova sezione.

---

FAQ – Multilingua e multi-country in WordPress lato tecnico

WordPress può gestire bene sia multilingua sia multi-country o è meglio cambiare piattaforma?

WordPress può gestire molto bene sia il multilingua sia il multi-country, a patto che la struttura venga progettata fin dall’inizio con attenzione. Non è solo una questione di plugin, ma di URL, tassonomie, custom post type, logiche PHP e caching. Quando questi elementi sono allineati, non c’è bisogno di cambiare piattaforma per avere un progetto internazionale stabile.

Serve per forza un plugin multilingua o si può fare tutto “a mano” in PHP?

Tecnicamente si potrebbe fare tutto a mano, ma nella pratica avrebbe poco senso. I plugin multilingua seri forniscono una base solida per gestire traduzioni, relazioni tra contenuti e interfaccia backend. Il codice PHP personalizzato ha più senso per estendere, rifinire e integrare il comportamento del plugin con le esigenze specifiche del sito, non per reinventare da zero la ruota.

Come si evita il rischio di contenuti duplicati in un sito multilingua/multi-country?

Il rischio di duplicazione si controlla progettando bene struttura URL, hreflang, relazioni tra traduzioni e regole di indicizzazione. Dal lato PHP è importante evitare che versioni diverse puntino a URL identici o che contenuti pensati per un solo paese vengano esposti come globali. Un lavoro combinato tra SEO tecnica e sviluppo permette di minimizzare il problema.

È complicato aggiungere una nuova lingua o un nuovo paese a progetto già avviato?

Diventa complicato se la base non è stata pensata per crescere. Se invece la struttura è stata progettata con una logica pulita (tassonomie, CPT, URL, funzioni PHP centralizzate), aggiungere una lingua o un paese richiede lavoro, ma non è un salto nel vuoto. In molti casi è sufficiente estendere regole e configurazioni esistenti, senza dover riscrivere tutto.