# General Translation Knowledge Base: Come si rende multilingue un sito web? URL: https://generaltranslation.com/it/kb/make-website-multilingual.mdx Docs index: https://generaltranslation.com/llms.txt Description: Scegli dove gestire le traduzioni (in un proxy, in un plugin del CMS, in un site builder o nel tuo codice), poi assegna a ogni lingua un URL dedicato, come raccomanda Google. Traduci le pagine per intero, compresi titoli e meta description, collega le versioni con hreflang e offri un selettore della lingua anziché reindirizzare automaticamente i visitatori. Category: Internazionalizzazione Last updated: 2026-10-20 Authors: Kevin Wu, Jackie Chen Published: 2026-10-20 Un sito web multilingue offre ogni pagina in più lingue, con ciascuna versione su un URL dedicato, e indica ai motori di ricerca come le versioni sono collegate tra loro. Gli approcci si distinguono soprattutto per il punto in cui risiede il testo tradotto, e da questo dipende quanto controllo mantieni su SEO, qualità e aggiornamenti. Per questo conviene scegliere l'approccio prima di tradurre qualsiasi cosa. ## Quale approccio scegliere? L'opzione più leggera non richiede alcun intervento da parte tua: sono i browser dei visitatori a tradurre le pagine. [Chrome](https://support.google.com/chrome/answer/173424), ad esempio, può tradurre una pagina con Google Translate in base alle impostazioni della lingua del lettore. Questo aiuta il singolo lettore, ma non rende il tuo sito multilingue. Non ci sono URL per lingua da indicizzare, non puoi rivedere il risultato e l'unico strumento a tua disposizione è contrassegnare testi come i nomi dei brand con l'attributo [`translate="no"`](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Global_attributes/translate). I proxy di traduzione e gli overlay JavaScript si collocano davanti a un sito già completato. Il [reverse proxy di Weglot](https://weglot.com/technical-presentation/) recupera la tua pagina, ne traduce il contenuto tramite l'API di Weglot e serve il risultato su un sottodominio o una sottodirectory per lingua, aggiungendo hreflang. La sua integrazione JavaScript, invece, inserisce le traduzioni nel browser dopo il caricamento della pagina; Weglot precisa che i motori di ricerca non rilevano queste traduzioni e consiglia questa modalità per test o contenuti privati. In entrambi i casi, le traduzioni risiedono nella dashboard del fornitore. I plugin per CMS e i site builder mantengono le traduzioni all'interno della piattaforma. Su WordPress, [WPML](https://wpml.org/documentation/getting-started-guide/language-setup/language-url-options/) colloca le lingue in directory, su un dominio o sottodominio per lingua oppure in un parametro `?lang=`, mentre [Polylang](https://wordpress.org/plugins/polylang/) determina la lingua tramite un codice nell'URL o tramite un sottodominio o dominio per lingua. [Webflow Localize](https://webflow.com/localization) serve le impostazioni regionali in sottodirectory come `/es/`, traduce meta title e meta description e genera una mappa del sito con tag hreflang. L'impostazione multilingue di Squarespace [collega Weglot](https://support.squarespace.com/hc/en-us/articles/205809778-Creating-a-multilingual-site-with-Weglot) sui siti versione 7.1 e le traduzioni si modificano in Weglot, poiché Squarespace non consente di modificarle direttamente. I generatori di siti statici e le librerie i18n mantengono le traduzioni nel tuo repository. [Docusaurus](https://docusaurus.io/docs/i18n/introduction) archivia i file tradotti in `i18n/[locale]/` e imposta automaticamente le intestazioni hreflang. [Hugo](https://gohugo.io/content-management/multilingual/) assegna la lingua di una pagina in base a un suffisso del nome file come `about.fr.md` o alla directory dei contenuti in cui si trova, quindi la serve sotto un prefisso come `/fr/`. In un'app realizzata con React, Next.js o Vue, una libreria come i18next o next-intl renderizza le traduzioni a partire da file gestiti da te. Nessuno di questi strumenti produce le traduzioni: devi scriverle, acquistarle o collegare uno strumento di traduzione. | Approccio | Dove risiedono le traduzioni | Controllo SEO | Controllo qualità | Impegno di sviluppo | Ideale per | | ------------------------------------------------------ | ----------------------------------------- | --------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- | | Traduzione del browser | Generate nel browser di ogni visitatore | Nessuno; nessun URL per lingua | Nessuno oltre a `translate="no"` | Nessuno | Lettori di siti non localizzati | | Proxy o overlay (Weglot) | Dashboard del fornitore | La modalità proxy aggiunge URL per lingua e hreflang; la modalità JavaScript non viene indicizzata | Traduzione automatica, poi modifiche o traduzione umana su ordinazione nell'editor del fornitore | Modifica DNS o tag script | Siti completati che non vuoi ricostruire | | Plugin per CMS (WPML, Polylang) | Il tuo database WordPress | Formato URL e selettore di lingua impostati nel plugin | Traduzione manuale, automatica o tramite agenzia all'interno di WordPress | Configurazione del plugin, poi lavoro pagina per pagina | Siti WordPress | | Site builder (Webflow Localize, Squarespace) | Il builder, oppure Weglot per Squarespace | Gestito dal builder | Traduzione automatica più modifiche manuali | Basso | Siti creati e ospitati su quel builder | | i18n dei generatori di siti statici (Docusaurus, Hugo) | File nel tuo repository | Completo; URL e modelli sono sotto il tuo controllo | Dipende dal processo che produce i file | Moderato; la traduzione è un lavoro a parte | Siti di documentazione e contenuti generati da Markdown | | General Translation | File generati nella build o CDN di GT | Routing e metadati sono sotto il tuo controllo; `gt-next` fornisce helper per il routing delle impostazioni regionali | Contesto derivato dal codice, terminologia condivisa e revisione integrata | Contrassegnare il testo di origine o collegare i cataloghi esistenti, generare prima della build, testare le impostazioni regionali | Siti gestiti dagli sviluppatori che necessitano sia della generazione delle traduzioni sia del rendering | | Sola libreria i18n (i18next, next-intl) | File di traduzione nel tuo repository | Completo | Dipende dal processo che produce i file | Estrazione delle stringhe, routing, distribuzione delle traduzioni e QA; le integrazioni esistenti possono automatizzare parte del lavoro | App che dispongono già di un flusso di lavoro di traduzione | Usa un proxy o la funzionalità integrata nel tuo site builder quando un team di marketing ha bisogno di pagine tradotte senza dover ricompilare il sito. Per WordPress, usa un plugin CMS. Usa le funzionalità i18n del generatore di siti statici o una libreria i18n quando il sito è gestito dagli sviluppatori e le traduzioni sono già disponibili. Scegli General Translation se vuoi anche generare e revisionare gli aggiornamenti nell'ambito dei rilasci; la sua CLI può tradurre i file esistenti senza sostituire la tua libreria. L'impegno richiesto dipende dal routing, dai contenuti e dal processo di revisione già in uso; la tabella descrive le attività da svolgere, non tempi di configurazione misurati. ## I passaggi che ogni approccio deve affrontare Qualunque approccio tu scelga, dovrà sciogliere questi sette nodi, più o meno in quest'ordine. ### 1. Scegliere lingue e impostazioni regionali Partite dai mercati in cui si trovano già il vostro traffico e i vostri clienti. Ogni impostazione regionale aggiunta comporta un insieme di pagine da tradurre, revisionare e tenere aggiornate, quindi aggiungete una variante regionale solo se la terminologia o i formati cambiano per quel pubblico: il portoghese brasiliano e quello europeo (`pt-BR`, `pt-PT`) hanno un lessico diverso, mentre un unico `fr` può bastare per i lettori francofoni di più paesi. La [guida ai codici locale](/docs/platform/core/guides/locale-codes) spiega come scrivere e scegliere questi tag. ### 2. Scegli una struttura degli URL Google [consiglia di usare un URL distinto per ciascuna versione linguistica](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites), anziché un unico URL la cui lingua cambia in base a un cookie o alle impostazioni del browser. Sottodirectory (`example.com/fr/`), sottodomini e domini nazionali sono tutte soluzioni valide; [la guida alla struttura degli URL](/kb/multilingual-url-structure) le mette a confronto. ### 3. Tradurre contenuti e metadati Google [determina la lingua di una pagina in base al suo contenuto visibile](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites), non dagli attributi `lang` né dall'URL, e sconsiglia di tradurre solo la navigazione lasciando il corpo della pagina in un'unica lingua. Traduci l'intera pagina, insieme al titolo, alla meta description, al testo alternativo (alt) delle immagini, ai messaggi di errore dei moduli e alle email inviate dalla pagina. Imposta comunque `` su ogni versione: [browser e screen reader lo usano](https://www.w3.org/International/questions/qa-lang-why) per la scelta dei font, la sillabazione e la sintesi vocale. ### 4. Aggiungere hreflang Le annotazioni hreflang indicano ai motori di ricerca quali URL sono versioni linguistiche della stessa pagina, in modo che possano mostrare a chi effettua la ricerca la versione nella propria lingua. [Che cos'è hreflang](/kb/what-is-hreflang) illustra le regole, `x-default` e gli errori più comuni. ### 5. Aggiungi un selettore della lingua Offri ai visitatori un controllo ben visibile che li porti alla stessa pagina in un'altra lingua, ed evita di [reindirizzarli automaticamente](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites) in base alla lingua che si presume parlino, una pratica sconsigliata da Google. Per i dettagli, consulta [la guida al selettore della lingua](/kb/language-switcher); per scegliere una lingua iniziale sensata, consulta la guida su [come rilevare la lingua dell'utente](/kb/detect-user-language). ### 6. Localizzare la formattazione Date, numeri, valute e plurali seguono regole diverse a seconda dell'impostazione regionale: `1,234.5` in inglese diventa `1.234,5` in tedesco. Le API `Intl` di JavaScript e la maggior parte delle librerie i18n si occupano della formattazione al posto tuo. Se aggiungi l'arabo o l'ebraico, anche il layout dovrà essere invertito specularmente; consulta [CSS right-to-left](/kb/right-to-left-css). ### 7. Mantenere aggiornate le traduzioni Le versioni di un sito nelle altre lingue diventano obsolete la prima volta che qualcuno modifica il testo sorgente e nessuno riesegue la traduzione. Stabilisci chi o cosa deve tradurre le modifiche, e quando: a ogni pubblicazione, a ogni distribuzione o secondo un calendario di revisione. Prima del lancio, esegui la [checklist per il lancio multilingue](/kb/multilingual-app-launch-checklist) in ogni impostazione regionale. ## Come General Translation rende un sito multilingue Per siti e app sviluppati nel codice, esegui `npx gt@latest` in un progetto Next.js o React: la [procedura guidata di configurazione](/docs/cli/quickstart) rileva il framework e scrive la config. Poi racchiudi il markup esistente in [``](/docs/react/reference/components/t) (`gt-vue` offre lo stesso componente): in questo modo i testi restano dove sono scritti, senza dover mantenere una chiave sorgente separata per ogni messaggio. Infine esegui [`npx gt translate`](/docs/cli/reference/commands/translate) prima della build per generare tutte le impostazioni regionali. Le guide di avvio rapido per [Next.js](/docs/react/nextjs-quickstart), [React](/docs/react/react-quickstart) e [Vue](/docs/vue/quickstart) illustrano passo passo ciascuna configurazione. [`createNextMiddleware`](/docs/react/nextjs/reference/functions/create-next-middleware) di `gt-next` serve percorsi con il prefisso dell'impostazione regionale, come `/es/about`, ma per impostazione predefinita lascia senza prefisso la lingua predefinita e reindirizza quegli URL in base al cookie dell'impostazione regionale del visitatore o all'intestazione `Accept-Language`. Imposta quindi `prefixDefaultLocale: true` per fare in modo che ogni URL di contenuto corrisponda a una sola lingua. (Per i pro e i contro, consulta [routing delle impostazioni regionali e SEO](/kb/locale-routing-seo).) Il JSX contrassegnato fornisce al servizio di traduzione la struttura degli elementi del testo ed eventuali note di contesto esplicite. Rivedi i testi generati nell'[editor della dashboard](/docs/platform/dashboard/guides/reviewing-translations) prima della pubblicazione. Le traduzioni corrispondenti vengono riutilizzate nelle esecuzioni successive, quindi modificare la sorgente non richiede di rigenerare l'intero sito. Oltre al codice dell'app, la CLI traduce file [HTML](/docs/cli/reference/formats/html-files) e [Markdown e MDX](/docs/cli/reference/formats/mdx-md-files), [Locadex](/docs/platform/locadex/quickstart) traduce la documentazione realizzata con Mintlify, Fern e Docusaurus, e le integrazioni collegano [Sanity](/docs/integrations/sanity/quickstart), [Payload CMS](/docs/integrations/payload/quickstart) e [Storyblok](/docs/integrations/storyblok/quickstart). Tutti questi strumenti condividono i [gruppi di contesto](/docs/platform/dashboard/guides/defining-context-for-translations) per terminologia e stile. ## Punti chiave * Per prima cosa, decidi dove risiederanno le traduzioni. La traduzione del browser e gli overlay JavaScript non creano pagine indicizzabili per ogni lingua; proxy, builder e plugin conservano le traduzioni presso un fornitore o una piattaforma; gli approcci basati sul codice le mantengono nel tuo repository. * Qualunque approccio deve risolvere le stesse sette questioni: impostazioni regionali, URL, contenuto tradotto e metadati, hreflang, selettore di lingua, formattazione e aggiornamenti. * Google consiglia un URL distinto per ogni lingua, determina la lingua in base al contenuto visibile e chiede di non reindirizzare automaticamente i visitatori. * Per i siti sviluppati nel codice, usa [``](/docs/react/reference/components/t) per la UI e [`npx gt translate`](/docs/cli/reference/commands/translate) per generare le traduzioni, quindi configura il routing e testa ogni impostazione regionale prima del lancio. ## Related questions - [Sottodirectory, sottodominio o ccTLD per la SEO multilingue](https://generaltranslation.com/it/kb/multilingual-url-structure.mdx): Usa sottodirectory come example.com/de/ quando un unico prodotto condivide sito e processo di rilascio. Solo un ccTLD indica un paese, i sottodomini consentono un hosting separato, Google sconsiglia i parametri ?lang= e tratta i domini di fantasia come .io e .ai come generici. - [Che cos'è hreflang e come si configura?](https://generaltranslation.com/it/kb/what-is-hreflang.mdx): Hreflang indica a Google quali URL sono versioni linguistiche o regionali della stessa pagina, così che possa mostrare quella giusta nei risultati di ricerca. Puoi aggiungerlo con tag link HTML, intestazioni HTTP Link o una mappa del sito: assicurati che ogni collegamento sia reciproco e usa codici validi come en-GB, non en-UK. - [Best practice per il selettore della lingua: UX, SEO e accessibilità](https://generaltranslation.com/it/kb/language-switcher.mdx): Indica ogni lingua con il suo nome nativo, ad esempio Deutsch o 日本語, ed evita le bandiere, che rappresentano paesi. Collega ogni opzione alla stessa pagina in quella lingua tramite un link scansionabile, memorizza la scelta in un cookie e non reindirizzare mai automaticamente un URL localizzato. - [Checklist per il test di localizzazione delle app multilingue](https://generaltranslation.com/it/kb/multilingual-app-launch-checklist.mdx): Verifica nove aspetti in ogni impostazione regionale supportata su una build di produzione: percorsi completi, inclusi gli stati di errore e le email, cambio di lingua, plurali, valuta e fusi orari, espansione del testo, layout right-to-left, accessibilità, distribuzione delle traduzioni e URL per lingua scansionabili. Assegna a ogni verifica un criterio di superamento esplicito. - [Qual è il miglior software di localizzazione per sviluppatori?](https://generaltranslation.com/it/kb/best-localization-software.mdx): Il miglior software di localizzazione per sviluppatori traduce i contenuti direttamente nel codice in cui sono scritti, con il contesto del tuo prodotto, e mantiene aggiornata ogni lingua. General Translation lo fa con librerie open source, i gruppi di contesto e Locadex, un agente IA che apre pull request. ## Previous and next questions - Previous question: [Come si localizza un'app iOS con gli String Catalog?](https://generaltranslation.com/it/kb/localize-ios-app.mdx) - Next question: [Come si rileva la lingua del browser di un utente?](https://generaltranslation.com/it/kb/detect-user-language.mdx) ## Sitemap See the [Knowledge Base sitemap](https://generaltranslation.com/it/kb/sitemap.md) for every article.