# General Translation Knowledge Base: Reindirizzamenti per lingua e SEO: URL, cookie o Accept-Language? URL: https://generaltranslation.com/it/kb/locale-routing-seo.mdx Docs index: https://generaltranslation.com/llms.txt Description: 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. Category: SEO multilingue Last updated: 2026-10-20 Authors: Kevin Wu, Jackie Chen Published: 2026-10-20 Tutti e tre i segnali sono utili, ma rispondono a domande diverse. L'URL indica quale versione è stata richiesta, un cookie indica cosa ha scelto in precedenza quel visitatore e `Accept-Language` indica come è configurato il suo browser. Solo l'URL appare identico sia ai crawler sia ai visitatori, quindi deve essere proprio l'URL a determinare il contenuto di una pagina. ## Perché ogni lingua ha bisogno di un proprio URL? Le indicazioni di Google sulle [pagine adattive in base all'impostazione regionale](https://developers.google.com/search/docs/specialty/international/locale-adaptive-pages) spiegano il problema. Se una pagina restituisce contenuti diversi in base al paese o alla lingua presunti del visitatore, Google potrebbe non eseguire la scansione, l'indicizzazione o il posizionamento di tutte le versioni: gli indirizzi IP predefiniti di Googlebot risultano infatti localizzati negli Stati Uniti e il crawler invia le richieste senza un'intestazione `Accept-Language`. Google consiglia di usare URL separati per ogni impostazione regionale, annotati con [hreflang](/kb/what-is-hreflang). Googlebot esegue la scansione anche da indirizzi IP al di fuori degli Stati Uniti, ma la [guida di Google sui siti multiregionali](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites) precisa che la posizione del crawler non viene variata per individuare le varianti di un sito. Consiglia quindi URL diversi per ogni lingua «anziché utilizzare cookie o impostazioni del browser». Le conseguenze sono concrete. Supponiamo che `/pricing` restituisca la versione in tedesco ai browser che preferiscono il tedesco e quella in inglese a tutti gli altri. Googlebot arriva senza `Accept-Language` e senza cookie, riceve l'inglese e indicizza l'inglese. La versione tedesca esiste per gli utenti, ma Google potrebbe non individuarla né indicizzarla. ## A cosa serve ciascun segnale | Segnale | Cosa ti dice | Cosa invia un crawler | Usalo per | | -------------------- | ---------------------------------------------------------- | -------------------------------------------------------------------- | -------------------------------------------------------- | | URL (`/de/preise`) | La versione richiesta | L'URL trovato in un link, in una mappa del sito o in un hreflang | Stabilire il contenuto: la fonte di verità indicizzabile | | Cookie (`locale=de`) | La lingua scelta in precedenza da questo visitatore | Nessuna delle scelte dei tuoi visitatori | Ricordare una scelta esplicita nelle visite successive | | `Accept-Language` | La lingua della UI del browser e le preferenze configurate | Niente (Googlebot omette l'intestazione) | Suggerire una lingua alla prima visita | | Geolocalizzazione IP | Un paese approssimativo, non una lingua | Perlopiù un indirizzo statunitense | Suggerire una regione; raramente ne vale la pena | L'intestazione del browser è meno affidabile di quanto sembri. Il [riferimento su `Accept-Language`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Accept-Language) di MDN la definisce un suggerimento, osserva che spesso sfugge al controllo dell'utente (ad esempio quando è in viaggio), segnala che Safari e la modalità in incognito di Chrome indicano una sola lingua e afferma che un server non dovrebbe mai sovrascrivere una scelta di lingua esplicita. L'IP è ancora meno affidabile: Google definisce l'analisi della posizione tramite IP "difficile e generalmente non affidabile" (vedi [perché la geolocalizzazione IP è il segnale sbagliato](/kb/detect-user-language)). ## Precedenza: URL, poi scelta salvata, poi intestazione Quando i segnali sono in conflitto, risolvili in quest'ordine: 1. **L'URL.** Una richiesta per `/de/preise` riceve sempre il tedesco, da qualsiasi browser. In questo modo il contenuto di ciascun URL resta stabile, ed è proprio su questo che fanno affidamento crawler e cache. 2. **La scelta salvata.** Un cookie o un'impostazione dell'account che il visitatore ha definito scegliendo una lingua. Può determinare verso quale pagina la radice neutra lo reindirizza o quale alternativa suggerire, ma non riscrive un URL localizzato su cui ha cliccato. Il [selettore della lingua](/kb/language-switcher) dovrebbe indicare la lingua attualmente visualizzata. 3. **L'intestazione `Accept-Language`.** Usata solo in assenza di una scelta salvata, e solo per scegliere una destinazione a partire dalla radice o per proporre un suggerimento. 4. **L'impostazione locale predefinita.** Il fallback quando non c'è alcuna corrispondenza, nonché ciò che riceve Googlebot. Una lingua scelta nel selettore porta all'URL di quella lingua, quindi rientra nella regola 1. Quando un segnale di priorità inferiore è in conflitto con l'URL, proponi l'altra versione anziché cambiare lingua. Un banner con la scritta "Questa pagina è disponibile in Deutsch" rispetta sia il link seguito dal visitatore sia la lingua che probabilmente preferisce. Le modalità di lettura di questi segnali sono descritte in [come rilevare la lingua del browser di un utente](/kb/detect-user-language). ## Conviene reindirizzare i visitatori in base alla lingua del browser? L'errore più comune è reindirizzare gli URL localizzati in base all'intestazione o all'IP: un visitatore con il browser in francese che apre `/en/pricing` viene dirottato su `/fr/tarifs`. La guida di Google invita i siti a evitarlo, spiegando che i reindirizzamenti basati sulla lingua presunta dell'utente potrebbero impedire a utenti e motori di ricerca di visualizzare tutte le versioni del sito. Un francofono che vuole la pagina in inglese non riesce a raggiungerla, e un crawler con un indirizzo statunitense non vede altro che la versione inglese. Al suo posto si usano due accorgimenti: * **Link tra le versioni.** Google consiglia di collegare ogni pagina alle relative versioni in altre lingue, così che gli utenti possano scegliere. Un selettore di lingua su ogni pagina offre inoltre ai crawler un percorso verso ciascuna versione. * **Un solo reindirizzamento, su una radice neutra.** Un URL radice come `/`, privo di contenuti propri, può reindirizzare in base alla scelta salvata o all'intestazione, oppure mostrare un selettore di lingua. Puoi indicarlo come `x-default` facoltativo nel cluster hreflang della homepage. Google cita i selettori di lingua e le homepage con reindirizzamento automatico come casi d'uso; le pagine interne dovrebbero invece mantenere un fallback pertinente per i propri contenuti. ### Quale codice di stato usare nella radice Usa un reindirizzamento temporaneo, `302` o `307`, perché la destinazione dipende da chi effettua la richiesta. La [guida ai reindirizzamenti](https://developers.google.com/search/docs/crawling-indexing/301-redirects) di Google distingue il routing temporaneo dallo spostamento permanente di un URL: i reindirizzamenti temporanei tendono a mantenere l'URL sorgente, mentre i reindirizzamenti permanenti `301` o `308` sono un segnale forte a favore della destinazione. Un reindirizzamento permanente da una radice indipendente dalla lingua invierebbe quindi un segnale sbagliato, dato che la destinazione è solo una scelta legata al singolo visitatore. ## Caching quando le risposte variano Una cache memorizza le risposte in base all'URL. Se uno stesso URL restituisce lingue diverse a seconda di un'intestazione o di un cookie, una CDN può servire a un visitatore la lingua di quello precedente. HTTP gestisce questo caso con l'intestazione di risposta `Vary`: * **`Vary: Accept-Language`** fa sì che le cache usino come chiave della risposta la combinazione di URL e intestazione, come spiegato nella [guida al caching di MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Caching#vary). I valori dell'intestazione variano molto (`en-US,en;q=0.9` e `en-GB,en;q=0.9,de;q=0.8` sono chiavi diverse), quindi l'hit rate si abbassa. * **`Vary: Cookie`** è ancora peggio. [RFC 9111](https://www.rfc-editor.org/rfc/rfc9111#section-4.1) riutilizza una risposta memorizzata solo se le intestazioni di richiesta indicate corrispondono, e l'intestazione `Cookie` contiene tutti i cookie, compresi quelli di sessione e di analytics. Quando le risposte sono personalizzate, MDN consiglia di usare `Cache-Control: private` anziché variare in base ai cookie. Inserire l'impostazione regionale nell'URL permette di mettere in cache il contenuto tradotto in base all'URL. Tuttavia, l'intera risposta si può condividere in sicurezza solo se anche il resto del contenuto non dipende dal visitatore. In questo esempio, contrassegna il reindirizzamento personalizzato della radice con `Vary: Accept-Language, Cookie` e `Cache-Control: private`. Se un suggerimento di lingua server-rendered o un contenuto legato all'account varia in base al visitatore, mantieni privata anche quella risposta, oppure renderizza il suggerimento separatamente sul client. ## Un esempio indipendente dal framework Questa funzione separa il routing dalla negoziazione della lingua. Risolvi prima un'eventuale scelta salvata, poi le preferenze del browser, seguendo la [guida al rilevamento della lingua](/kb/detect-user-language). Passa l'impostazione regionale supportata così ottenuta come `preferredLocale`: sarà la funzione a decidere se reindirizzare, servire la pagina o suggerire un'altra versione. ```ts title="routeLocale.ts" const LOCALES = ['en', 'de', 'fr', 'es-MX']; const DEFAULT_LOCALE = 'en'; type Decision = | { action: 'serve'; locale: string; suggest?: string } | { action: 'redirect'; status: 302; location: string; headers: Record } | { action: 'not-found' }; export function routeLocale(pathname: string, preferredLocale?: string): Decision { const preferred = LOCALES.includes(preferredLocale ?? '') ? preferredLocale : undefined; if (pathname === '/') { return { action: 'redirect', status: 302, location: `/${preferred ?? DEFAULT_LOCALE}/`, headers: { Vary: 'Accept-Language, Cookie', 'Cache-Control': 'private' }, }; } const segment = pathname.split('/')[1]; const urlLocale = LOCALES.find((l) => l.toLowerCase() === segment.toLowerCase()); if (!urlLocale) return { action: 'not-found' }; return preferred && preferred !== urlLocale ? { action: 'serve', locale: urlLocale, suggest: preferred } : { action: 'serve', locale: urlLocale }; } ``` | Percorso | Preferenza risolta | Decisione | | ------------- | --------------------------- | ----------------------------------------------------- | | `/` | Nessuna | Reindirizzamento temporaneo a `/en/` | | `/` | `de` | Reindirizzamento temporaneo a `/de/` | | `/` | `fr`, da una scelta salvata | Reindirizzamento temporaneo a `/fr/` | | `/de/preise` | Nessuna | Servi la versione tedesca | | `/de/preise` | `fr` | Servi la versione tedesca; suggerisci quella francese | | `/en/pricing` | `de` | Servi la versione inglese; suggerisci quella tedesca | | `/pt/precos` | Nessuna | Non trovato: il portoghese non è configurato | La funzione restituisce una decisione di routing; non invia un reindirizzamento né renderizza una pagina. Applica il relativo codice di stato e le intestazioni di cache nell'integrazione server e proponi una versione suggerita solo se quella pagina è pubblicata nella lingua di destinazione. Questo pattern limitato alla radice è solo una delle possibili implementazioni: anche altri percorsi senza prefisso possono fungere da punti di ingresso neutri, purché i contenuti effettivi risiedano in URL localizzati stabili. ## Come gt-next di General Translation determina la lingua In `gt-next`, [`createNextMiddleware`](/docs/react/nextjs/reference/functions/create-next-middleware) verifica l'impostazione regionale nell'URL prima del cookie con l'impostazione regionale salvata e dell'intestazione `Accept-Language`, così un URL localizzato serve sempre la propria lingua. L'ordine di risoluzione completo e il nome del cookie sono descritti in [come rilevare la lingua del browser di un utente](/kb/detect-user-language). Per i siti pubblici, imposta `prefixDefaultLocale: true` in [`createNextMiddleware`](/docs/react/nextjs/reference/functions/create-next-middleware). L'inglese si trova in `/en/about`, il francese in `/fr/about` e ogni URL di contenuto mantiene la propria lingua indipendentemente dalle preferenze del visitatore. I percorsi senza prefisso, come `/about`, fungono da punti di ingresso neutri con reindirizzamenti temporanei. La [guida SEO per Next.js](/kb/multilingual-nextjs-seo) mostra come questa configurazione si collega agli URL canonical, ai metadati e alle mappe del sito. Con la configurazione predefinita l'inglese resta senza prefisso e `/about` può essere reindirizzato in base al cookie salvato o all'intestazione del browser. Abilitando esplicitamente il prefisso si evita che quell'URL faccia da contenuto in inglese e, al tempo stesso, da punto di ingresso basato sulle preferenze. Per ignorare le preferenze indicate nell'intestazione del browser, imposta [`ignoreBrowserLocales`](/docs/react/nextjs/config#ignore-browser-locales) su `true` in `withGTConfig`; l'URL e la scelta salvata restano comunque validi. ## Punti chiave * Googlebot non invia alcuna intestazione `Accept-Language` ed esegue la scansione principalmente da indirizzi statunitensi, quindi i contenuti selezionati in base a intestazione, cookie o IP potrebbero non venire mai indicizzati nelle altre lingue. * Risolvi la lingua in quest'ordine: URL, scelta salvata, `Accept-Language` e infine il valore predefinito, senza mai permettere a un segnale di priorità inferiore di sovrascrivere l'URL. * In questo pattern, esegui la negoziazione solo su una radice neutra tramite un `302` o `307` temporaneo; `x-default` è facoltativo. Mantieni stabili gli URL dei contenuti localizzati e proponi delle alternative. * Gli URL stabili per lingua possono condividere i contenuti in cache, ma i reindirizzamenti specifici per visitatore, i suggerimenti e i dati dell'account richiedono comunque controlli di cache adeguati. * In `gt-next`, l'impostazione regionale nell'URL ha la precedenza sul cookie e sull'intestazione; `prefixDefaultLocale` e `ignoreBrowserLocales` rendono le regole più restrittive. ## Related questions - [Come si rileva la lingua del browser di un utente?](https://generaltranslation.com/it/kb/detect-user-language.mdx): Leggi l'elenco ordinato delle lingue del browser (navigator.languages in JavaScript o l'intestazione Accept-Language sul server), ordinato per q-value, e confrontalo con le impostazioni regionali supportate, prevedendo un fallback. Safari e Chrome in incognito restituiscono una sola lingua, mentre la geolocalizzazione tramite IP rivela la posizione, non la lingua. - [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. - [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. - [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. - [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. ## Previous and next questions - Previous question: [La traduzione con l'IA è abbastanza accurata per un'app in produzione?](https://generaltranslation.com/it/kb/is-ai-translation-accurate.mdx) - Next question: [Sottodirectory, sottodominio o ccTLD per la SEO multilingue](https://generaltranslation.com/it/kb/multilingual-url-structure.mdx) ## Sitemap See the [Knowledge Base sitemap](https://generaltranslation.com/it/kb/sitemap.md) for every article.