Agosto 2024, kickoff con un editore italiano di una testata verticale entertainment/cinema, già tenant del network AI Multisite: la testata aveva chiuso il primo semestre con una crescita di sessioni dall’estero che il piano editoriale non aveva pianificato. Lo scope del progetto Fieldwork: portare la testata in tre paesi (versione localizzata in tre lingue), preservare il dominio storico italiano come canonico, indirizzare i lettori esteri sulla loro lingua senza rompere SEO. Quattro mesi end-to-end, ~14.000 articoli storici tradotti per due lingue, traffico locale sui paesi target a +28% dopo 90 giorni. Vedi anche gli altri post di questa rubrica: Fieldwork.
Il cliente, anonimizzato
Un editore italiano del network AI Multisite, verticale entertainment/cinema, audience italiana solida da diversi anni, redazione interna piccola con cadenza giornaliera. Il sito storico era già passato sopra la nostra piattaforma multi-tenant nei mesi precedenti: WordPress in container Docker, MariaDB dietro MaxScale, Typesense come search, Cloudflare davanti. Il bacino di lettori in Spagna e Portogallo cresceva da mesi via referral di siti aggregatori, e l’editore aveva già tentato un’apertura informale (versioni tradotte a campione, senza pipeline stabile). Il nome non lo scriviamo: in Fieldwork il cliente lo citiamo solo con consenso esplicito scritto. Qui parliamo del lavoro.
Il problema, in sintesi
La frase del responsabile editoriale del progetto, parafrasata da una call di kickoff, era diretta: “abbiamo lettori in Spagna e Portogallo che traducono i nostri pezzi su Google Translate. Possiamo fare di meglio?”. Sotto la frase c’erano tre punti operativi:
- Il traffico estero cresceva ma la conversione (newsletter, ritorni nei 7 giorni) era nettamente inferiore a quella italiana. Lettori che non hanno il sito nella loro lingua tornano meno.
- La lingua sorgente (italiano) doveva restare il canonico SEO. Una redirect 301 forte da italiano a localizzato avrebbe distrutto il posizionamento storico costruito in cinque anni.
- La voce di redazione era riconoscibile: critica cinematografica con tono editoriale specifico. Una traduzione automatica generalista avrebbe consegnato testi corretti ma piatti.
L’output dell’audit non era una lista di feature, era un piano di pipeline con tre milestone numerate e una finestra di rollback per ogni step.
Il metodo: pipeline traduzione AI-assistita
La traduzione è stata trattata come pipeline asincrona, non come feature di rendering. Tre stadi.
Stadio 1, prompt stilometrico. Per ogni lingua target abbiamo costruito un prompt di sistema con esempi golden estratti dalla redazione: 30 pezzi italiani con la loro versione “ideale” tradotta a mano da un revisore madrelingua, scelti come spettro stilistico (recensione, opinion, cronaca di festival, intervista). Il prompt forza tono, registro, gestione degli idiomi specifici del lessico cinematografico italiano (es. “regia”, “messa in scena”, “sceneggiatura”) con i corrispettivi nella lingua target. Niente traduzione letterale: adattamento.
Stadio 2, LLM primario + fallback. Job Horizon su coda dedicata translation:{locale}. LLM provider primario per il pass principale, un secondo provider come fallback per retry su errori di rate limit o timeout, scelta blind a livello di codice (interfaccia adapter su Laravel). Il dispatcher monitora costo e latenza, rotazione automatica se il primario degrada. Output normalizzato in JSON con i blocchi del post (titolo, sommario, body segmentato per <h2>, didascalie media), checksum per integrità.
Stadio 3, controllo umano sui pezzi opinion. I caporedattori del cliente hanno una coda di review nel back office: i pezzi categorizzati come “opinion”, “editoriale”, “intervista” arrivano in pending_review dopo la traduzione, mai pubblicati direttamente. I pezzi “news pura” e “scheda film” passano in pubblicazione immediata, con un sample del 5% pescato a campione per QA settimanale. La regola architetturale del prodotto: l’AI propone, il caporedattore decide.
Geo-redirect: Accept-Language + CF-IPCountry, niente forzature
Il routing geografico è stato gestito su Cloudflare Workers, davanti a tutto. Logica:
- Se l’utente arriva su un URL di una lingua specifica (es.
/es/), nessun redirect, viene servito quel locale. - Se l’utente arriva sul dominio canonico italiano e ha già un cookie
preferred_locale, lo rispetta. - Se non c’è cookie, il Worker legge
CF-IPCountrye il primo valore diAccept-Language. Mapping deterministico: paesi target → lingua corrispondente con preferenza Accept-Language quando in conflitto. - Fallback al sito italiano sempre. Se il paese non è uno dei target o il browser non dichiara una lingua tra quelle servite, italiano canonico, nessun redirect, nessun 30x. La sovranità del dato editoriale e la SEO storica restano sulla versione sorgente.
- Il redirect, quando c’è, è un 302 (non 301) verso la home in lingua, banner di switch sempre visibile per tornare al canonico. Niente trappole utente.
I 301 forti da italiano a localizzato sono stati scartati esplicitamente: avrebbero rotto il posizionamento storico, e il bacino italiano vale ancora la quota maggiore del traffico totale.
hreflang, sitemap, search per lingua
Tre dettagli che decidono la SEO multi-lingua.
hreflang completo. Per ogni post tradotto, il template di rendering emette i link rel="alternate" hreflang per tutte le varianti esistenti più x-default puntato all’italiano. Il backend Laravel mantiene la mappa (post_id, locale) → url come fonte di verità: niente plugin che scopre relazioni a runtime, lookup deterministico in compilazione del template.
Sitemap separate. Una sitemap per lingua, indicizzata in un sitemap index unico al root del dominio. Submission separata su Search Console per ogni proprietà (un proprietario distinto per lingua, accesso al cliente). Niente sitemap unica con URL misti: l’esperienza dimostra che i crawler si confondono.
Search Typesense per locale. La collection Typesense esistente del cliente è stata ribattezzata articles_it e affiancata da articles_es, articles_pt. Il frontend determina la collection sulla base del locale corrente, niente filtraggio a runtime, niente collection unica multilingue. Il routing già scegliebbe il locale, il search lo eredita.
Cosa abbiamo scartato
Due alternative valutate e tagliate.
Redirect 301 forte da italiano a localizzato. Avrebbe semplificato la vita del crawler ma distrutto la SEO storica del dominio principale. Cinque anni di backlink non si sostituiscono in tre mesi di indicizzazione delle nuove proprietà.
Traduzione full-automatica senza review. Per news pura e schede tecniche funziona; per opinion e interviste il livello qualitativo era troppo basso, anche con prompt stilometrici accurati. La voce di redazione si misura su mille piccole scelte lessicali che il LLM non recupera senza un revisore madrelingua a campione. Il costo umano (un caporedattore part-time per lingua) è risultato sostenibile rispetto al rischio di pubblicare contenuto piatto.
I numeri
| Metrica | Valore |
|---|---|
| Durata progetto | 4 mesi end-to-end |
| Articoli storici tradotti | ~14.000 (per due lingue; la terza solo nuovi pezzi) |
| Lingue servite al go-live | 3 (oltre all’italiano canonico) |
| Costo LLM medio per articolo | ~0,15 € |
| Traffico locale +90gg sui paesi target | +28% sessioni |
| Tempo medio di traduzione per articolo | ~12 secondi (LLM primario) |
| Pezzi opinion in coda review | ~6% del volume totale |
| Persone Romiltec coinvolte | 2 (un senior dev, Rocco sul DevOps e architettura) |
Il +28% sui paesi target è misurato su Search Console e Plausible del cliente, finestra 90 giorni post go-live vs 90 giorni precedenti, escludendo i picchi da social. La metrica che è piaciuta di più al cliente non è il traffico totale: è la profondità di sessione (pagine/visita) sui locali nuovi, che ha eguagliato quella italiana entro il secondo mese, segnale che i lettori atterrano e restano.
Voce del cliente
“La cosa che non mi aspettavo è quanto bene abbia tenuto la voce della redazione. La traduzione automatica che avevamo provato anni fa restituiva testi corretti ma anonimi. Qui i pezzi suonano come se li avessimo scritti noi nella loro lingua, anche su pezzi di critica dove la sfumatura conta. Sui pezzi opinion il caporedattore della lingua interviene poco, e quando interviene è per scelte stilistiche, non per errori. Il flusso è entrato nella routine settimanale in due mesi: ora pubblichiamo direttamente nei tre paesi senza pensarci, e i numeri dicono che funziona.” — il responsabile editoriale del progetto.
Cosa stiamo costruendo dopo
Due tracce in corso al momento del go-live, già firmate nel piano del trimestre successivo.
Quarta lingua. Apertura su un quarto paese, mercato laterale individuato dal cliente sui dati di traffico organico anomalo. Stesso pattern, riuso integrale della pipeline, golden set stilometrico in costruzione con un revisore madrelingua.
Seconda testata sullo stesso pattern. Un altro tenant del network, verticale diverso (cultura/musica), candidato per replicare l’architettura. La pipeline è già astratta abbastanza: la parte cliente-specifica è solo il prompt stilometrico e il golden set.
Box laterale
Stack: WordPress su container Docker, Laravel 12 backend, MariaDB con MaxScale, Cloudflare Workers (geo-routing su Accept-Language + CF-IPCountry), Typesense (collection per locale), LLM provider primario + secondo provider in fallback (interfaccia adapter), Horizon su Redis per le code di traduzione, sitemap per lingua, hreflang completo, AI Multisite come piattaforma orchestrante.
Durata progetto: 4 mesi end-to-end (audit, golden set, pipeline, cutover, monitor 30 giorni).
Team Romiltec: 1 senior dev sul codice della pipeline, Rocco sul DevOps e architettura. Lato cliente: 1 responsabile editoriale del progetto, 3 caporedattori (uno per lingua) sulla coda review.