# General Translation Knowledge Base: Redirections linguistiques et SEO : URL, cookie ou Accept-Language ? URL: https://generaltranslation.com/fr/kb/locale-routing-seo.mdx Docs index: https://generaltranslation.com/llms.txt Description: Laissez l’URL déterminer la langue de chaque page que vous souhaitez faire indexer, car Googlebot n’envoie aucun en-tête Accept-Language et explore principalement depuis des adresses américaines. Ne vous servez du choix enregistré dans un cookie, puis d’Accept-Language, que pour décider vers où redirige une racine neutre comme /, avec une redirection temporaire 302 ou 307. Category: Référencement multilingue Last updated: 2026-10-20 Authors: Kevin Wu, Jackie Chen Published: 2026-10-20 Ces trois signaux sont utiles, mais ils ne répondent pas à la même question. L’URL indique quelle version a été demandée, un cookie indique ce que ce visiteur a choisi précédemment, et `Accept-Language` indique la langue configurée dans son navigateur. Seule l’URL se présente de la même façon à un robot d’exploration et à vos visiteurs : c’est donc à elle de déterminer le contenu d’une page. ## Pourquoi chaque langue a-t-elle besoin de sa propre URL ? Les recommandations de Google sur les [pages adaptées aux paramètres régionaux](https://developers.google.com/search/docs/specialty/international/locale-adaptive-pages) expliquent le problème. Si une page renvoie un contenu différent selon le pays ou la langue supposés du visiteur, Google risque de ne pas explorer, indexer ou classer toutes les versions : les adresses IP par défaut de Googlebot semblent en effet situées aux États-Unis, et le robot envoie ses requêtes sans en-tête `Accept-Language`. Google recommande donc des URL distinctes pour chaque paramètre régional, annotées avec [hreflang](/kb/what-is-hreflang). Googlebot explore certes aussi depuis des adresses IP situées hors des États-Unis, mais le [guide de Google sur les sites multirégionaux](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites) précise qu'il ne fait pas varier la localisation du robot pour découvrir les variantes d'un site. Il recommande des URL différentes pour chaque langue « plutôt que d'utiliser des cookies ou les paramètres du navigateur ». Les conséquences sont bien réelles. Supposons que `/pricing` renvoie la version allemande à un navigateur configuré en allemand, et la version anglaise à tous les autres. Googlebot arrive sans `Accept-Language` ni cookie, reçoit l'anglais et indexe l'anglais. La version allemande existe bien pour les utilisateurs, mais Google risque de ne pas la découvrir ni l'indexer. ## À quoi sert chaque signal | Signal | Ce qu'il vous indique | Ce qu'envoie un robot d'exploration | À utiliser pour | | -------------------- | ------------------------------------------------------------------ | ---------------------------------------------------------------------- | ------------------------------------------------------- | | URL (`/de/preise`) | La version demandée | L'URL trouvée dans un lien, un plan de site ou une balise hreflang | Déterminer le contenu : la source de vérité indexable | | Cookie (`locale=de`) | La langue choisie précédemment par ce visiteur | Aucun des choix de vos visiteurs | Mémoriser un choix explicite lors des visites suivantes | | `Accept-Language` | La langue de l'IU du navigateur et les préférences configurées | Rien (Googlebot omet cet en-tête) | Suggérer une langue lors d'une première visite | | Géolocalisation IP | Un pays approximatif, pas une langue | Une adresse généralement américaine | Suggérer une région ; en vaut rarement la peine | L'en-tête du navigateur est moins fiable qu'il n'y paraît. La [référence `Accept-Language`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Accept-Language) de MDN le présente comme une simple indication, souligne qu'il échappe souvent au contrôle de l'utilisateur (en voyage, par exemple), précise que Safari et le mode navigation privée de Chrome n'indiquent qu'une seule langue, et affirme qu'un serveur ne doit jamais remplacer un choix de langue explicite. L'IP est encore moins fiable : selon Google, l'analyse de la localisation par IP est « difficile et généralement peu fiable ». (Voir [pourquoi la géolocalisation IP n'est pas le bon signal](/kb/detect-user-language).) ## Priorité : l'URL, puis le choix enregistré, puis l'en-tête Lorsque les signaux divergent, résolvez-les dans cet ordre : 1. **L'URL.** Une requête vers `/de/preise` renvoie de l'allemand, quel que soit le navigateur, à chaque fois. Le contenu de chaque URL reste ainsi stable, ce dont dépendent les robots d'exploration et les caches. 2. **Le choix enregistré.** Un cookie ou un paramètre de compte défini par le visiteur lorsqu'il a choisi une langue. Il peut déterminer vers où la racine neutre le redirige ou quelle alternative lui suggérer, mais il ne réécrit pas une URL localisée sur laquelle il a cliqué. Le [sélecteur de langue](/kb/language-switcher) doit indiquer la langue actuellement affichée. 3. **L'en-tête `Accept-Language`.** Utilisé uniquement en l'absence de choix enregistré, et seulement pour choisir une destination depuis la racine ou pour proposer une suggestion. 4. **Les paramètres régionaux par défaut.** Le contenu de secours lorsque rien ne correspond ; c'est aussi ce que reçoit Googlebot. Choisir une langue dans le sélecteur mène à l'URL de cette langue : la règle 1 s'applique donc. Lorsqu'un signal de rang inférieur contredit l'URL, proposez l'autre version plutôt que de changer de langue. Une bannière indiquant « This page is available in Deutsch » respecte à la fois le lien suivi par le visiteur et la langue qu'il souhaite probablement. La manière de lire ces signaux est expliquée dans [comment détecter la langue du navigateur d'un utilisateur](/kb/detect-user-language). ## Faut-il rediriger les visiteurs selon la langue du navigateur ? L'erreur courante consiste à rediriger les URL localisées en fonction de l'en-tête ou de l'adresse IP : un visiteur dont le navigateur est en français et qui ouvre `/en/pricing` est renvoyé d'office vers `/fr/tarifs`. Le guide de Google conseille aux sites d'éviter cette pratique : selon lui, des redirections fondées sur la langue supposée de l'utilisateur risquent d'empêcher les utilisateurs comme les moteurs de recherche de consulter toutes les versions du site. Un francophone qui souhaite consulter la page en anglais ne peut pas y accéder, et un robot d'exploration doté d'une adresse américaine ne voit que la version anglaise. Deux pratiques la remplacent : * **Des liens entre les versions.** Google recommande de relier chaque page à ses autres versions linguistiques pour que les utilisateurs puissent choisir. Un sélecteur de langue présent sur chaque page fournit aussi aux robots d'exploration un chemin vers chaque version. * **Une seule redirection, sur une racine neutre.** Une URL racine comme `/`, sans contenu propre, peut rediriger en fonction du choix enregistré ou de l'en-tête, ou bien afficher un sélecteur de langue. Vous pouvez la déclarer comme `x-default` (facultatif) dans le groupe hreflang de la page d'accueil. Google cite les sélecteurs de langue et les pages d'accueil à redirection automatique parmi les cas d'usage ; les pages internes doivent quant à elles conserver un contenu de secours pertinent pour leur propre contenu. ### Quel code d'état utiliser à la racine Utilisez une redirection temporaire, `302` ou `307`, car la destination dépend de l'auteur de la requête. Le [guide des redirections](https://developers.google.com/search/docs/crawling-indexing/301-redirects) de Google distingue le routage temporaire d'un déplacement permanent d'URL : les redirections temporaires tendent à conserver l'URL source, tandis que les redirections permanentes `301` ou `308` constituent un signal fort en faveur de la destination. Une redirection permanente depuis une racine indépendante de la langue enverrait donc un mauvais signal, puisque la destination ne reflète qu'un choix propre à chaque visiteur. ## Mise en cache lorsque les réponses varient Un cache stocke les réponses par URL. Si une même URL renvoie différentes langues selon un en-tête ou un cookie, un CDN peut servir à un visiteur la langue du visiteur précédent. HTTP gère ce cas avec l'en-tête de réponse `Vary` : * **`Vary: Accept-Language`** indique aux caches d'indexer la réponse sur la combinaison de l'URL et de l'en-tête, comme l'explique le [guide de MDN sur la mise en cache](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Caching#vary). Les valeurs de cet en-tête varient énormément (`en-US,en;q=0.9` et `en-GB,en;q=0.9,de;q=0.8` constituent des clés différentes), ce qui fait chuter le taux de succès du cache. * **`Vary: Cookie`** est encore pire. La [RFC 9111](https://www.rfc-editor.org/rfc/rfc9111#section-4.1) ne réutilise une réponse stockée que si les en-têtes de requête désignés correspondent, or l'en-tête `Cookie` transporte tous les cookies, y compris ceux de session et d'analyse. Lorsque les réponses sont personnalisées, MDN recommande d'utiliser `Cache-Control: private` plutôt que de faire varier la réponse selon les cookies. Placer le paramètre régional dans l'URL permet de mettre en cache le contenu traduit par URL. Mais la réponse entière ne peut être partagée sans risque que si le reste de son contenu ne dépend pas non plus du visiteur. Dans cet exemple, appliquez à la redirection personnalisée de la racine les en-têtes `Vary: Accept-Language, Cookie` et `Cache-Control: private`. Si une suggestion de langue server-rendered ou du contenu lié au compte varie selon le visiteur, gardez également cette réponse privée, ou affichez la suggestion séparément côté client. ## Un exemple indépendant de tout framework Cette fonction dissocie le routage de la négociation de langue. Résolvez d'abord un choix enregistré, puis les préférences du navigateur, en suivant le [guide de détection de la langue](/kb/detect-user-language). Transmettez ensuite ce paramètre régional pris en charge en tant que `preferredLocale` ; la fonction détermine alors s'il faut rediriger, servir la page ou proposer une autre version. ```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 }; } ``` | Chemin | Préférence résolue | Décision | | ------------- | --------------------------------- | -------------------------------------------------- | | `/` | Aucune | Redirection temporaire vers `/en/` | | `/` | `de` | Redirection temporaire vers `/de/` | | `/` | `fr`, issue d’un choix enregistré | Redirection temporaire vers `/fr/` | | `/de/preise` | Aucune | Servir la version allemande | | `/de/preise` | `fr` | Servir la version allemande ; suggérer le français | | `/en/pricing` | `de` | Servir la version anglaise ; suggérer l’allemand | | `/pt/precos` | Aucune | Introuvable : le portugais n'est pas configuré | La fonction renvoie une décision de routage ; elle n’envoie pas de redirection et n’affiche aucune page. Appliquez le code d’état et les en-têtes de cache qu’elle fournit dans l’intégration serveur, et ne proposez une version suggérée que si la page est publiée dans la langue cible. Cette approche limitée à la racine n’est qu’une implémentation parmi d’autres ; d’autres chemins sans préfixe peuvent également servir de points d’entrée neutres, à condition que le contenu réel se trouve à des URL localisées stables. ## Comment gt-next de General Translation détermine la langue Dans `gt-next`, [`createNextMiddleware`](/docs/react/nextjs/reference/functions/create-next-middleware) vérifie le paramètre régional présent dans l’URL avant le cookie de paramètre régional enregistré et l’en-tête `Accept-Language`, de sorte qu’une URL localisée sert toujours sa propre langue. L’ordre de résolution complet et le nom du cookie sont détaillés dans [comment détecter la langue du navigateur d’un utilisateur](/kb/detect-user-language). Pour les sites publics, définissez `prefixDefaultLocale: true` dans [`createNextMiddleware`](/docs/react/nextjs/reference/functions/create-next-middleware). L’anglais est alors servi sous `/en/about`, le français sous `/fr/about`, et chaque URL de contenu conserve sa langue, quelle que soit la préférence du visiteur. Les chemins sans préfixe, comme `/about`, servent de points d’entrée neutres et effectuent des redirections temporaires. Le [guide SEO pour Next.js](/kb/multilingual-nextjs-seo) explique comment cette configuration s’articule avec les URL canoniques, les métadonnées et les plans de site. Par défaut, l’anglais reste sans préfixe et `/about` peut être redirigé en fonction du cookie enregistré ou de l’en-tête du navigateur. Activer explicitement le préfixe évite que cette URL serve à la fois de contenu en anglais et de point d’entrée dépendant des préférences. Pour ignorer les préférences transmises par l’en-tête du navigateur, définissez [`ignoreBrowserLocales`](/docs/react/nextjs/config#ignore-browser-locales) sur `true` dans `withGTConfig` ; l’URL et le choix enregistré restent pris en compte. ## Points clés * Googlebot n'envoie aucun en-tête `Accept-Language` et explore principalement depuis des adresses américaines : un contenu choisi en fonction de l'en-tête, du cookie ou de l'adresse IP risque donc de ne jamais être indexé dans d'autres langues. * Résolvez la langue dans cet ordre : URL, choix enregistré, `Accept-Language`, puis valeur par défaut. Ne laissez jamais un signal de priorité inférieure remplacer l'URL. * Dans cette approche, ne négociez la langue qu'au niveau d'une racine neutre, au moyen d'une redirection temporaire `302` ou `307` ; `x-default` est facultatif. Conservez des URL stables pour le contenu localisé et proposez des alternatives. * Des URL de langue stables permettent de partager du contenu mis en cache, mais les redirections, suggestions et données de compte propres à chaque visiteur exigent tout de même des contrôles de cache adaptés. * Dans `gt-next`, le paramètre régional de l'URL prime sur le cookie et l'en-tête ; `prefixDefaultLocale` et `ignoreBrowserLocales` permettent de durcir ces règles. ## Related questions - [Comment détecter la langue du navigateur d’un utilisateur ?](https://generaltranslation.com/fr/kb/detect-user-language.mdx): Lisez la liste ordonnée des langues du navigateur (navigator.languages en JavaScript ou l’en-tête Accept-Language côté serveur), triée par valeur q, puis mettez-la en correspondance avec vos paramètres régionaux pris en charge, en prévoyant une solution de secours. Safari et la navigation privée de Chrome n’indiquent qu’une seule langue, et la géolocalisation par IP révèle l’emplacement, pas la langue. - [Bonnes pratiques pour le sélecteur de langue : UX, SEO et accessibilité](https://generaltranslation.com/fr/kb/language-switcher.mdx): Affichez chaque langue sous son propre nom, comme Deutsch ou 日本語, et bannissez les drapeaux, qui représentent des pays. Faites pointer chaque option vers la même page dans cette langue grâce à un lien explorable par les robots, mémorisez le choix dans un cookie et ne redirigez jamais automatiquement une URL localisée. - [Qu’est-ce que hreflang et comment le configurer ?](https://generaltranslation.com/fr/kb/what-is-hreflang.mdx): Hreflang indique à Google quelles URL correspondent aux versions linguistiques ou régionales d’une même page, afin qu’il affiche la bonne dans les résultats de recherche. Ajoutez-le à l’aide de balises link HTML, d’en-têtes HTTP Link ou d’un plan de site, veillez à ce que chaque lien soit réciproque et utilisez des codes valides comme en-GB, et non en-UK. - [Sous-répertoire, sous-domaine ou ccTLD pour le SEO multilingue](https://generaltranslation.com/fr/kb/multilingual-url-structure.mdx): Utilisez des sous-répertoires comme example.com/de/ lorsqu’un même produit partage un site et un processus de livraison. Seul un ccTLD signale un pays, les sous-domaines permettent un hébergement distinct, Google déconseille les paramètres ?lang= et considère les domaines « de complaisance » comme .io et .ai comme génériques. - [Comment configurer le SEO d’une application Next.js multilingue ?](https://generaltranslation.com/fr/kb/multilingual-nextjs-seo.mdx): Attribuez à chaque langue sa propre URL préfixée, comme /en/about et /es/about, puis publiez html lang, une URL canonique autoréférente, des variantes localisées hreflang avec x-default, un titre et une description traduits, ainsi qu’une entrée de plan de site pour chaque langue publiée. Marquez les versions non publiées en noindex. Le package gt-next de General Translation associe chaque langue à sa propre URL et traduit les titres avec getGT. ## Previous and next questions - Previous question: [Qu’est-ce que le format de message ICU ?](https://generaltranslation.com/fr/kb/icu-message-format.mdx) - Next question: [Sous-répertoire, sous-domaine ou ccTLD pour le SEO multilingue](https://generaltranslation.com/fr/kb/multilingual-url-structure.mdx) ## Sitemap See the [Knowledge Base sitemap](https://generaltranslation.com/fr/kb/sitemap.md) for every article.