Come tradurre un sito in dieci lingue: il mio sistema con WordPress, Polylang, un plugin su misura e tanta IA

Uno dei modi più semplici per ottenere più traffico organico è tradurre un sito.

È logico: più URL, più intenti di ricerca; se il contenuto è buono, ti porta più traffico.

Certo, farlo con l’IA sembra facile. E lo è, nei siti piccoli.

Nei siti medi e grandi la cosa si complica, almeno se provi a farla bene.

Perché non si tratta solo di prendere un articolo in spagnolo, incollarlo in ChatGPT e chiedere cinque versioni. 

Questo va bene per una prova, ma un sito reale ha categorie, tag, SEO, immagini, campi personalizzati, link interni, menu, pagine archivio, pagina iniziale, slug, date, hreflang e struttura editoriale. 

Per non parlare del fatto che dentro ogni articolo ci sono grassetti, liste e corsivi che è ideale mantenere nella traduzione.

E tutto deve essere tradotto.

Quello che ho fatto questa settimana sul mio sito è stato costruire un sistema per passare da un sito in spagnolo a un sito multilingue in dieci lingue: inglese, francese, portoghese, italiano, tedesco, olandese, svedese, polacco e norvegese, usando il plugin Polylang, un plugin sviluppato da me e un paio di GPTs personalizzati.

Il risultato è che ora ho il sito in dieci lingue, con tutta la struttura di categorie e tag e vari articoli pubblicati già tradotti.

E con un sistema che aggiunge tra 5 e 10 minuti di lavoro extra a qualsiasi articolo in spagnolo per averlo tradotto in queste dieci lingue, cosa che mi sembra più che ragionevole.

Ti racconto tutto il processo nel caso tu voglia replicarlo.

1. Il problema iniziale: tradurre gli articoli non bastava

Quando mi sono messo ad analizzare lo sviluppo, ho scoperto che nel mio caso, oltre agli articoli in sé, dovevo tradurre tutto questo:

• Categorie.
• Tag.
• Slug.
• Meta description.
• Titoli SEO.
• Immagini in evidenza.
• Testi alternativi.
• Campi ACF.
• Blocchi interni.
• Link tra articoli.
• Pagine archivio.
• Testi fissi del tema.
• Moduli della pagina iniziale.
• CTAs.
• Moduli.
• Indici dei contenuti.
• Articoli correlati.
• Mantenere date e note.
• …

Tanti testi lì dentro e troppe lingue per farlo uno per uno.

Ma bisognava tradurlo, perché se anche solo uno di quei pezzi resta in spagnolo, la traduzione rimane a metà.

Per questo l’obiettivo non era “tradurre contenuti”, ma creare un’architettura multilingue completa e scalabile, nel caso domani voglia aggiungere altre lingue.

Ed è proprio quello che è successo: ho iniziato solo con cinque lingue (inglese, portoghese, francese, tedesco e italiano) e ho aggiunto le altre quattro strada facendo. E già che c’ero ho verificato che il sistema mi permetteva di scalare quanto mi serviva.

2. La base: WordPress, Polylang e copia locale

Il progetto parte da un sito WordPress con tema Genesis, design personalizzato in stile magazine e diversi modelli su misura.

Essendo qualcosa di una certa portata e che avrebbe richiesto molti test, ho lavorato con una copia locale usando LocalWP. L’idea era poter rompere cose senza paura, provare importazioni, rivedere tassonomie e verificare che Polylang collegasse correttamente ogni traduzione.

A proposito, ho usato questo plugin come base perché genera già tutto il necessario per avere un sito in più lingue. A partire da quello, ho creato il mio plugin completandolo e adattandolo a ciò di cui avevo bisogno: creare rapidamente la struttura del sito e gli articoli in più lingue.

Sempre in questa prima fase ho ottimizzato LocalWP perché all’inizio l’ambiente era troppo lento e avevo bisogno di un posto dove esportare, importare, cancellare, ripetere e validare in modo fluido..

3. Il sistema: plugin su misura più GPTs

Avrei potuto usare una soluzione standard di traduzione automatica, ma l’obiettivo era un altro.

Traduzione semplice di ogni articolo

Con la traduzione degli articoli sono stato MOLTO ambizioso, perché volevo un sistema in cui GPTs creati per questo traducessero il contenuto di ogni articolo mantenendo:

• Il mio stile personale.
• La stessa struttura dell’articolo originale.
• Titoli ufficiali di film, serie o libri in ogni lingua (cioè, se l’opera è in spagnolo, la traduzione doveva prendere il titolo con cui è uscita in Italia, per esempio.
• Slug puliti.
• Alt delle immagini tradotti.
• Yoast con campi completi tradotti, inclusa la description.
• Campi ACF personalizzati, in modo da poter scegliere se esportarli o meno, se tradurli o lasciarli com’erano (come, per esempio, il voto che do a ogni opera nelle mie recensioni).
• Frammenti HTML senza romperli: liste, grassetti, blocchi di codice… che rimanessero e che le parti necessarie restassero non tradotte (come gli script di codice).
• Link interni degli articoli: che puntassero all’URL di ogni lingua, non sempre all’originale.
• Data di pubblicazione: deve mantenere quella originale dell’articolo in spagnolo.

Come vedi, la logica dietro tutto questo non è “traduci e basta”. Ci sono molti test dietro e persino qualche esclusione, come lo schema che, per ora, resta solo in spagnolo.

E, inoltre, volevo che fosse un sistema gratuito, usando GPTs invece dell’API di OpenAI o Claude. Più manuale, ma meno costoso.

La soluzione che ho adottato include questi passaggi:

1. Pubblico un articolo in spagnolo come faccio normalmente.
2. Uso il mio plugin per esportare un JSON strutturato, che contiene tutto il contenuto dell’articolo spezzato per la traduzione.
3. Un GPT traduce quel JSON nelle nove lingue, restituendomi nove JSON (uno per lingua).
4. Il plugin importa i nove JSON tradotti.
5. Polylang collega ogni traduzione al suo originale.
6. Gli articoli vengono generati come bozza.
7. Controllo e/o pubblico.
8. Riparo i link interni (automaticamente) se necessario.

Inoltre, c’è stato un passaggio iniziale: creare la struttura in più lingue. Questo si fa solo la prima volta che ci sono nuove lingue, cosa che nel mio caso è successa due volte: la prima per le cinque lingue iniziali e la seconda per le altre quattro.

Se togliamo quel primo compito una tantum, il processo che ho progettato aggiunge circa cinque minuti in più alla preparazione di ogni articolo soltanto, mentre moltiplico per nove il contenuto utile del mio sito.

Mica male.

La struttura multilingue

Vediamo:

• Sito super personalizzato.
• Con testi di interfaccia.
• Una pagina iniziale che teneva quasi tutti i suoi testi nel codice.
• 23 categorie e sottocategorie, con le intestazioni dei loro moduli, vari testi in campi su misura e le loro variabili SEO.
• 24 tag con caratteristiche simili.
• Diversi moduli su misura.
• Plugin che non permettono il multilingua in modo predefinito.

E non so se mi sto dimenticando qualcos’altro.

Tutto questo andava tradotto una volta per lingua. E mi avrebbe richiesto, non so, almeno quattro ore in ogni caso. E questo ammesso che conoscessi tutte quelle lingue, cosa che non è.

Col cavolo.

Che cosa ho fatto?

Beh, questo processo:

1. Adattare tutti i testi a variabili, nel codice e nei campi personalizzati di ACF..
2. Creare una funzionalità nel plugin che esporta tutte queste variabili di ogni categoria o tag in JSON.
3. Creare un GPT che traduce quel JSON nella lingua di cui ho bisogno.
4. Aggiungere un importatore nel plugin che raccolga il JSON tradotto e crei la struttura completa delle tassonomie nella nuova lingua.
5. Ripetere il processo con ogni lingua.
6. Cambiare i testi rimasti in sospeso.

Ci sono stati diversi punti che mi hanno dato fastidio, come gli slug nelle tassonomie, dato che Polylang base non permette di creare due slug uguali (solo con il Pro).

Cioè, il tag “comic” in spagnolo non si poteva creare come “comic” in inglese, ma doveva essere “comic-en” o qualcosa di simile.

Ho sviluppato il plugin per permetterlo, mantenendo dominio.com/comic in spagnolo e dominio.com/en/comic in inglese.

Yaarp (il plugin che usavo per gli articoli correlati) mi dava anche problemi, quindi l’ho disattivato perché consigliava articoli in altre lingue. Probabilmente in futuro gli creerò una funzionalità che dia priorità alla lingua rispetto al resto delle variabili nei consigli.

La sottoscrizione alla lista in altre lingue l’ho esclusa anche per il lancio. Forse in futuro deciderò di inviare la mia newsletter tradotta, ma per ora non lo farò, quindi non ho creato nuove liste in Acumbamail.

4. Il contenuto già creato: poco a poco

Tutto quello che ti ho raccontato funziona alla grande per i nuovi articoli, ma che succede con gli oltre duecento che ho già pubblicato?

Mi piacerebbe dirti che ho creato una funzionalità che automatizza la loro traduzione, ma non è così.

Il massimo a cui sono arrivato è creare una funzionalità che mi genera JSON esportati in lotti di più articoli, ma quando ho provato a tradurre più articoli insieme in nove lingue, il GPT li processa peggio. Quindi, per ora, uno alla volta.

Considerando che impiego circa tre minuti per articolo, è abbastanza semplice tradurne dieci al giorno, il che farebbe sì che in meno di un mese avrei tutto il sito nelle dieci lingue.

Mi torna.

Ho anche pensato di montarmi un Hermes e provare a vedere se lo fa manualmente, ma siccome per ora non ho fretta e questo non mi porta soldi, preferisco non spendere in token più del necessario.

Il risultato

Per ora sono contento. Ho già più di dieci articoli tradotti in dieci lingue. Vale a dire che il mio sito è cresciuto del 33% in una settimana.

Per ora non sto forzando l’indicizzazione di nulla. Voglio aspettare finché non avrò almeno 50 o 60 articoli. Ma se si indicizza, non mi preoccupa nemmeno. È una cosa a lungo termine.

Quello che posso dirti è che sono contento del risultato. 

Penso che il sistema che ho messo insieme sia abbastanza robusto — con i suoi probabili miglioramenti, certo — ma nemmeno nei miei sogni migliori, un anno fa, avrei immaginato di gestire un sito multilingue con questo volume di contenuti.

Ora, come dico sempre, vediamo dove mi porta tutto questo.

Cose imparate dal processo e conclusione

La conclusione principale — che già prevedevo — è che tradurre un sito con l’IA non significa “tradurre testi”, ma progettare un sistema.

L’IA è super utile se riceve input puliti e restituisce output controllati. Ma se le dai un blocco enorme, senza struttura e senza regole, ti restituisce qualcosa di bello, ma inutile da importare.

Credimi, mi è successo spesso all’inizio.

La chiave è stata costruire un sistema in cui ogni parte faccia ciò che deve fare:

• WordPress è il cuore di tutto.
• Polylang mette in relazione i contenuti.
• Il plugin esporta e importa.
• GPT traduce.
• Io prendo le decisioni editoriali.

Avere chiaro dove si inserisce ogni pezzo e perché fa quello e non altro, è ciò che mi ha permesso di creare un sistema reale per scalare un sito usando la traduzione con IA come leva.

Se ti è piaciuto il mio sistema e vuoi che chiarisca qualche punto, lascia le tue domande nei commenti e ti rispondo.