# General Translation Knowledge Base: Sottodirectory, sottodominio o ccTLD per la SEO multilingue URL: https://generaltranslation.com/it/kb/multilingual-url-structure.mdx Docs index: https://generaltranslation.com/llms.txt Description: 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. Category: SEO multilingue Last updated: 2026-10-20 Authors: Kevin Wu, Jackie Chen Published: 2026-10-20 Tutte queste strutture assegnano a ogni lingua un proprio URL, e la [guida di Google sui siti multiregionali e multilingue](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites) le mette a confronto in termini di targeting e manutenzione, senza privilegiarne nessuna. La scelta si riduce quindi a due domande: ti rivolgi a lingue o a paesi? E quanti siti vuoi gestire? ## Le quattro strutture URL a confronto I pro e i contro riportati di seguito riprendono la tabella di Google. L'ultima opzione, il parametro URL, è quella che Google indica come sconsigliata. | Struttura | Esempio | Pro secondo Google | Contro secondo Google | | ------------------------------------------ | --------------------- | ------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------- | | Dominio di primo livello nazionale (ccTLD) | `example.de` | Geotargeting chiaro; posizione del server irrilevante; siti facili da separare | Costoso e a volte non disponibile; più infrastruttura; requisiti ccTLD rigorosi in alcuni paesi; si rivolge a un solo paese | | Sottodominio | `de.example.com` | Facile da configurare; consente server in posizioni diverse; siti facili da separare | Dall'URL gli utenti non capiscono se `de` indica una lingua o un paese | | Sottodirectory | `example.com/de/` | Facile da configurare; manutenzione ridotta (stesso host) | Gli utenti potrebbero non riconoscere il targeting dall'URL; un'unica posizione del server; siti più difficili da separare | | Parametro URL | `example.com?lang=de` | Nessuno indicato (sconsigliato) | Difficile segmentare per URL; gli utenti potrebbero non riconoscere il targeting | Due dettagli delle linee guida di Google riducono le differenze: * **Tra le forme di URL, solo un ccTLD indica un paese.** Le [linee guida di Google sulle versioni localizzate](https://developers.google.com/search/docs/specialty/international/localized-versions) affermano che i sottodomini di lingua come `en` o `de` non vengono usati per determinare il pubblico di una pagina: questa associazione va indicata esplicitamente con [hreflang](/kb/what-is-hreflang). Google non menziona espressamente le cartelle, ma nulla lascia pensare che un percorso `/de/` venga trattato diversamente, quindi associa anche queste con hreflang. * **Alcuni ccTLD sono considerati generici.** Google tratta `.io`, `.ai`, `.co`, `.me`, `.tv` e altri ccTLD "di fantasia", oltre ai domini regionali come `.eu`, come domini di primo livello generici. Una startup su `example.io` non si rivolge certo al Territorio britannico dell'Oceano Indiano. Google osserva inoltre che la posizione del server "non è un segnale definitivo", perché i siti usano le CDN: questo ridimensiona lo svantaggio dell'"unica posizione del server" per le sottodirectory. Una quinta opzione mantiene un unico URL e cambia la lingua in base a un cookie o all'intestazione del browser. Google la sconsiglia perché il suo crawler potrebbe non trovare tutte le versioni; i pro e i contro sono illustrati in [come un sito dovrebbe scegliere la lingua da servire](/kb/locale-routing-seo). ## Quanto costa gestire ciascuna struttura La tabella di Google si limita a indicare "più infrastruttura". In pratica, le strutture si differenziano per il numero di elementi distinti da gestire: * **Domini nazionali:** un dominio da acquistare e rinnovare per ogni paese, con regole di registrazione locali in alcuni paesi. Ogni host richiede una copertura TLS; un singolo certificato può coprire più nomi. Pianifica la gestione della proprietà, i reindirizzamenti e il monitoraggio su tutti questi domini. * **Sottodomini:** un solo dominio, ma un record DNS e una copertura del certificato per ogni sottodominio. Le [linee guida sulla canonicalizzazione](https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls) di Google avvertono che il certificato deve corrispondere all'host completo oppure essere di tipo wildcard; in caso contrario, Google potrebbe preferire la versione HTTP. * **Sottodirectory:** le lingue possono condividere host, configurazione TLS, applicazione e pipeline di distribuzione. Si tratta di scelte operative comuni, non di requisiti: i reverse proxy possono instradare i percorsi verso app separate e gli analytics possono essere organizzati indipendentemente dalla struttura degli URL. Non dare per scontato che le sottodirectory godano di un vantaggio nel posizionamento o che ogni nuovo sottodominio parta privo di segnali utili. Il confronto di Google non dimostra né l'una né l'altra cosa. Valuta piuttosto il lavoro di hosting, gestione e rilascio richiesto dalla tua distribuzione reale. ## Conviene puntare sulle lingue o sui paesi? Google distingue un sito **multilingue** (la stessa offerta in più lingue, come un'azienda canadese che si rivolge al pubblico in inglese e in francese) da uno **multiregionale** (offerte diverse per ciascun paese, come un produttore che spedisce in Canada e negli Stati Uniti). La struttura degli URL dovrebbe riflettere il tipo di sito che gestisci: * **Punta su una lingua** quando il contenuto è identico per tutti i parlanti. Un'unica sezione `/es/` annotata con `es` si rivolge agli ispanofoni in Messico, Spagna e Argentina. * **Punta su un paese** quando qualcosa cambia da un paese all'altro: prezzi e valuta, spedizioni, termini legali o il catalogo dei prodotti. Usa `/es-mx/` e `/es-es/`, oppure `example.mx`, e annotali con `es-MX` ed `es-ES`. Il targeting per paese ha un costo. Secondo Google, il geotargeting può migliorare il posizionamento nel paese di destinazione "a scapito dei risultati in altre impostazioni regionali o lingue", e un ccTLD può avere come target un solo paese. Se decidi di suddividere per paese, Google [consiglia](https://developers.google.com/search/docs/specialty/international/localized-versions) di offrire anche una pagina basata solo sulla lingua (`es`) per i parlanti di tutti gli altri paesi. Per scegliere tra codici come `es` ed `es-MX`, consulta [quali codici locale usare](/docs/platform/core/guides/locale-codes). ## Slug localizzati Il prefisso del locale rende visibile la versione nell'URL; anche il resto del percorso può essere tradotto, ad esempio `/de/ueber-uns` anziché `/de/about-us`. Secondo Google, le parole localizzate negli URL non sono un problema, così come i nomi di dominio internazionalizzati, purché gli URL utilizzino la codifica UTF-8 e siano codificati correttamente quando vengono inseriti nei link. Uno slug non ASCII come `/de/über-uns` viene trasmesso come `/de/%C3%BCber-uns`, quindi è proprio questa forma codificata che va indicata in hreflang e nelle mappe del sito. Gli slug tradotti risultano naturali nei risultati di ricerca, ma richiedono una mappa degli slug per ogni impostazione regionale, e se la traduzione di uno slug cambia occorre un reindirizzamento dal vecchio URL. I team che rinunciano agli slug localizzati mantengono `/de/about-us` e ottengono comunque un URL distinto e indicizzabile per ogni lingua. ## Quale struttura scegliere? Usa le **sottodirectory** come punto di partenza quando un unico prodotto serve più lingue da un sito e un processo di rilascio condivisi. Spesso permettono di riutilizzare la configurazione di routing e di hosting. Sono comunque possibili distribuzioni separate, e una CDN può servire lo stesso host da più località. Usa i **domini nazionali** quando ogni paese è di fatto un'attività a sé, con entità legali, cataloghi o team di marketing separati, e vuoi il segnale geografico più forte possibile e puoi sostenerne i costi di gestione. Usa i **sottodomini** quando un'impostazione regionale richiede hosting o infrastruttura diversi, ad esempio quando un mercato deve essere servito da server situati nel paese stesso. Evita i **parametri URL** come struttura linguistica predefinita, perché Google ne sconsiglia l'uso. Non impediscono di per sé l'indicizzazione: il comportamento di reportistica e caching dipende da come i tuoi sistemi gestiscono i parametri. Qualunque struttura tu scelga, usa URL stabili e indica con hreflang le versioni pubblicate equivalenti. (Vedi [Che cos'è hreflang](/kb/what-is-hreflang)). ## Come General Translation supporta ciascuna struttura `gt-next` di General Translation supporta le sottodirectory. Nell'App Router, [`createNextMiddleware`](/docs/react/nextjs/reference/functions/create-next-middleware) instrada ogni impostazione regionale sotto un prefisso di percorso come `/es/about`; se anche l'impostazione locale predefinita debba averne uno è spiegato in [routing delle impostazioni regionali e SEO](/kb/locale-routing-seo). L'opzione `pathConfig` dello stesso middleware associa un percorso condiviso a uno slug localizzato per ciascuna impostazione regionale, ad esempio `/de/ueber-uns` per `/about`, mentre `customMapping` in `gt.config.json` permette a una route di usare un alias come `/cn`, lasciando alle traduzioni il codice canonical `zh`. (Consulta la [guida SEO sugli alias delle impostazioni regionali](/docs/react/nextjs/locale-alias-seo)). La documentazione di `gt-next` tratta il routing basato sul percorso, non quello basato sul nome host. Per sottodomini o domini nazionali, associa ogni host a un'impostazione regionale nel tuo codice e passala alla libreria, ad esempio con una funzione personalizzata per l'impostazione regionale definita tramite [`getLocalePath`](/docs/react/nextjs/config#request-function-paths), oppure con [`withGT`](/docs/node/reference/functions/with-gt) in `gt-node`. Per tag canonical, hreflang e mappa del sito, consulta [Come si configura la SEO per un'app Next.js multilingue?](/kb/multilingual-nextjs-seo). ## Punti chiave * Google confronta ccTLD, sottodomini e sottodirectory in termini di targeting e manutenzione, non di posizionamento, e sconsiglia i parametri URL per la lingua. * Un ccTLD fornisce un segnale di paese; sottodomini e percorsi che sembrano indicare una lingua non forniscono di per sé quel segnale. Usa hreflang per un targeting esplicito per lingua o regione. Google considera generici `.io`, `.ai` e `.co`. * Inizia con le sottodirectory (`example.com/de/`) se le tue impostazioni regionali condividono lo stesso sito e lo stesso processo di rilascio; la struttura degli URL non impone un'unica distribuzione né un'unica proprietà di analytics. * Suddividi per paese (`es-MX`) solo se prezzi, spedizioni, termini legali o cataloghi sono diversi; altrimenti scegli come target la lingua (`es`). * `gt-next` offre il routing basato sul prefisso del percorso, prefissi facoltativi per l'impostazione locale predefinita e slug localizzati tramite `pathConfig`. ## Related questions - [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. - [Reindirizzamenti per lingua e SEO: URL, cookie o Accept-Language?](https://generaltranslation.com/it/kb/locale-routing-seo.mdx): Lascia che sia l'URL a stabilire la lingua di ogni pagina che vuoi far indicizzare, perché Googlebot non invia alcuna intestazione Accept-Language ed esegue la scansione soprattutto da indirizzi statunitensi. Usa la scelta salvata in un cookie e, in subordine, Accept-Language solo per decidere verso quale pagina reindirizzare una radice neutra come /, con un reindirizzamento temporaneo 302 o 307. - [Come si configura la SEO per un'app Next.js multilingue?](https://generaltranslation.com/it/kb/multilingual-nextjs-seo.mdx): Assegna a ogni lingua un proprio URL con prefisso, come /en/about e /es/about, quindi pubblica html lang, un canonical autoreferenziale, alternative hreflang con x-default, un titolo e una descrizione tradotti e una voce nella mappa del sito per ogni lingua pubblicata. Contrassegna con noindex le versioni non pubblicate. gt-next di General Translation instrada ogni lingua verso il proprio URL e traduce i titoli con getGT. - [Come si rende multilingue un sito web?](https://generaltranslation.com/it/kb/make-website-multilingual.mdx): 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. ## Previous and next questions - Previous question: [Reindirizzamenti per lingua e SEO: URL, cookie o Accept-Language?](https://generaltranslation.com/it/kb/locale-routing-seo.mdx) - Next question: [Come mantengo le traduzioni aggiornate a ogni distribuzione?](https://generaltranslation.com/it/kb/translations-in-ci.mdx) ## Sitemap See the [Knowledge Base sitemap](https://generaltranslation.com/it/kb/sitemap.md) for every article.