--- title: Perché un sito WordPress multilingue è una decisione GEO, non di traduzione canonical_url: https://lolacore.com/it/wordpress-multilingue-decisione-geo-non-traduzione/ last_updated: 2026-07-26T11:48:16+00:00 plugin_version: 1.2.3 --- # Perché un sito WordPress multilingue è una decisione GEO, non di traduzione ## La lingua della domanda decide chi ha diritto di essere citato Un modello generativo che risponde a una domanda in italiano non traduce tutto il web per poi scegliere la fonte migliore. Recupera dei passaggi, e il recupero viene filtrato per lingua prima ancora di valutare la qualità. La tua pagina in inglese può essere la cosa più accurata, meglio strutturata e più autorevole mai scritta sull'argomento. Se il lettore ha fatto la domanda in italiano e non esiste una versione italiana di quella pagina, la tua pagina non era nemmeno nel gruppo tra cui il modello stava scegliendo. Questo è il punto che si perde quando il lavoro multilingue viene archiviato sotto la voce "traduzione". Non è un problema di posizionamento che puoi vincere con contenuti migliori. È un problema di ammissibilità. O hai una pagina nella lingua della domanda, o non ce l'hai, e nessuna qualità sul lato inglese compensa quell'assenza. Questo cambia il senso di tutta la decisione. Tradurre il tuo sito non serve a servire lettori che non sanno leggere l'inglese. Molti di loro leggono l'inglese perfettamente. Serve a esistere dentro l'insieme di recupero del modello che risponde loro quando scelgono di fare la domanda nella propria lingua, che è quello che le persone fanno di default quando la risposta riguarda la loro attività. ## Cosa dimostrano i dati e cosa no Troverai molti numeri che circolano su questo tema. La maggior parte arriva da aziende che vendono servizi di traduzione, e diversi sono costruiti in modi che non reggono a una lettura attenta. Non li ripeteremo, perché un'affermazione che non puoi verificare vale meno del meccanismo su cui puoi ragionare direttamente. Il meccanismo regge anche senza i numeri. Il recupero è sensibile alla lingua. La documentazione di Google sui siti internazionali dice da anni che URL specifici per lingua e un'annotazione hreflang corretta sono il modo in cui un motore di ricerca decide quale versione di una pagina appartiene a quale pubblico. I motori generativi sono costruiti sullo stesso recupero e sugli stessi segnali. Non serve un whitepaper per crederci. Quello che non ha buone prove a supporto è l'idea che attivare la traduzione automatica su tutto un sito produca un beneficio GEO. I modelli non contano le tue versioni linguistiche. Citano passaggi che si leggono come se una persona competente li avesse scritti per quel pubblico. La traduzione letterale di un testo commerciale è il modo più veloce per produrre un testo che è tecnicamente in spagnolo e semanticamente in nessuna lingua. ## Il problema dell'entità sotto il problema della lingua C'è un secondo effetto che conta di più per un prodotto che per un blog. Attraverso le lingue, un modello sta costruendo un'immagine di cosa sia il tuo prodotto. Stesso nome, stesso prezzo, stesse funzionalità, stesse affermazioni. Quando la pagina spagnola dice una cosa sul prezzo e quella inglese ne dice un'altra, quando il nome del prodotto viene ammorbidito in portoghese perché suonava meglio così, quando lo schema di una versione omette ciò che le altre dichiarano, non hai creato quattro descrizioni di un prodotto. Hai creato quattro mezze descrizioni di qualcosa di cui il modello ora è meno sicuro. È la coerenza tra le versioni linguistiche a permettere a un modello di trattarle tutte come la stessa entità e di sommare l'autorevolezza. L'incoerenza la divide. Per questo la traduzione del sito di un prodotto è prima di tutto un esercizio di posizionamento, e solo dopo un esercizio linguistico: ogni termine che possiedi deve attraversare la traduzione intatto, e ogni termine che non possiedi va reso nel vocabolario che il lettore locale usa davvero. ## Cosa deve essere vero a livello tecnico I requisiti tecnici sono poco appariscenti e non negoziabili. Ogni lingua vive al proprio URL. Le sottocartelle sono la soluzione più comune per un sito WordPress: /es/, /pt-br/, /it/. Una lingua per pagina, mai mescolate. Le annotazioni hreflang collegano le versioni tra loro e dichiarano quale appartiene a quale pubblico, con un tag auto-referenziale su ciascuna. I tag canonical puntano alla pagina stessa nella propria lingua, non all'originale in inglese, che è il modo più comune con cui un'installazione WordPress multilingue si rimuove silenziosamente dall'indice. Il markup Schema.org dichiara inLanguage su ogni versione e mantiene la stessa identità di entità in tutte. La sitemap include ogni versione linguistica. Qualsiasi plugin di traduzione WordPress competente fa gran parte di questo lavoro al posto tuo. [LolaCore for Polylang](https://lolacore.com/it/lolacore-for-polylang/) è il ponte che usiamo su questo sito quando Lola deve mantenere allineate le versioni collegate e l'hreflang. Il punto non è quale plugin scegli. Il punto è che se questi segnali sono sbagliati, il contenuto sotto di loro non viene letto per quello che intendevi, e hai pagato il costo della traduzione senza incassarne il beneficio. ## Cosa tradurre, e in che ordine Non tutto, e non prima la homepage. I modelli citano i passaggi che rispondono alle domande. Questo significa documentazione, guide pratiche, pagine di confronto, pagine sui casi d'uso: le cose che le persone formulano come domande quando le scrivono in una finestra di chat. Una homepage tradotta è una brochure in un'altra lingua. Una sezione di documentazione tradotta è un insieme di risposte recuperabili in un'altra lingua, ed è quello che finisce dentro una risposta generata. Per un negozio WooCommerce, la priorità equivalente sono le pagine prodotto, le pagine categoria e le FAQ collegate, perché le domande che le persone fanno a un modello di IA su un negozio sono domande a cui risponde una pagina prodotto. La homepage conta per la persona che arriva dopo che il modello l'ha già indirizzata lì. Non è quello che l'ha fatta arrivare. ## Il costo che nessuno mette in conto Ecco la parte che decide se un sito multilingue sopravvive al primo anno. Pubblichi una pagina in inglese. Poi la pubblichi in altre tre lingue. Poi cambi un prezzo. Poi rinomini una funzionalità. Poi riscrivi la sezione che non convertiva. Ognuna di queste modifiche adesso è quattro modifiche, in quattro posti, in quattro lingue che magari non parli tutte, con quattro set di annotazioni hreflang che si rompono in silenzio se una versione esce dalla sincronia. Nessuno abbandona un sito multilingue perché tradurre è difficile. Lo abbandona perché la manutenzione è incessante e invisibile. La versione inglese resta aggiornata perché è quella che guardi ogni giorno. Le altre tre si allontanano, in silenzio, finché la pagina italiana descrive un prodotto che non esiste più e il modello sta citando con sicurezza, in italiano, a un lettore italiano, un'affermazione superata su di te. Quello scarto è un sintomo di fatica amministrativa: il divario tra la frase semplice che hai in testa, "aggiorna il prezzo su questa pagina", e il numero di schermate e lingue che quella frase tocca davvero. [Ecco cosa intendiamo con questo.](https://lolacore.com/it/fatica-amministrativa-wordpress-woocommerce/) La conseguenza pratica è una regola che suona prudente e non lo è: scegli meno lingue di quante pensi di poter gestire, e mantienile sincronizzate. Quattro lingue mantenute battono otto lingue pubblicate. Una pagina non aggiornata in una lingua che non sai leggere è peggio di nessuna pagina, perché resta comunque ammissibile per essere citata. ## Scritto da un sito che lo fa Niente di quanto sopra è una proiezione. Questo sito esiste in inglese e in spagnolo, e la versione spagnola della pagina che stai leggendo ora è a un clic di distanza nel selettore di lingua. Non è stato tradotto automaticamente in blocco. Ogni pagina è stata transcreata tramite Polylang e [LolaCore for Polylang](https://lolacore.com/it/lolacore-for-polylang/), il che significa che la terminologia che possediamo è stata portata attraverso deliberatamente, e la terminologia che non possediamo è stata resa nel modo in cui un lettore spagnolo la dice davvero. Il problema di sincronizzazione descritto nella sezione precedente è quello a cui dedichiamo tempo vero. Ed è anche il motivo per cui le prossime due lingue sono in fase di pianificazione, non già pubblicate.