# General Translation Knowledge Base: Comment configurer le SEO d’une application Next.js multilingue ? URL: https://generaltranslation.com/fr/kb/multilingual-nextjs-seo.mdx Docs index: https://generaltranslation.com/llms.txt Description: 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. Category: Référencement multilingue Last updated: 2026-10-22 Authors: General Translation Team Published: 2026-02-17 Le SEO multilingue dans Next.js consiste à attribuer à chaque version linguistique d’une page sa propre URL et à indiquer aux moteurs de recherche comment ces URL sont liées entre elles. Une page qui détermine sa langue à partir d’un cookie ou de l’en-tête `Accept-Language` n’a qu’une seule URL : les moteurs de recherche ne l’indexent donc généralement que dans une seule langue. Chaque version linguistique doit remplir les six conditions de ce tableau, et le routage, les métadonnées et le plan de site doivent s’accorder sur l’URL de chaque langue. | Exigence | Rôle | Emplacement dans Next.js | | ------------------------------- | --------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- | | Une URL par langue | Chaque version est une page distincte à explorer et à indexer | Un segment de route `[locale]` et un middleware de routage selon les paramètres régionaux | | `` | Indique la langue de la page aux navigateurs et aux technologies d’assistance | La mise en page racine, `app/[locale]/layout.tsx` | | URL canonique | Cette URL est la version de référence pour sa propre langue, et non un doublon d’une autre langue | `alternates.canonical` dans `generateMetadata` | | Variantes localisées `hreflang` | Toutes les versions linguistiques publiées de la page, y compris celle-ci, ainsi qu’un contenu de secours `x-default` | `alternates.languages` dans `generateMetadata` | | Titre et description traduits | Le texte généralement affiché dans les résultats de recherche pour cette langue | `title` et `description` dans `generateMetadata` | | Entrée de plan de site | Toutes les URL linguistiques publiées de chaque page | `app/sitemap.ts` | Le package `gt-next` de General Translation associe chaque langue à une URL telle que `/es/about` et traduit les titres et descriptions avec [`getGT`](/docs/react/nextjs/reference/functions/get-gt). L’URL canonique, les variantes localisées `hreflang` et le plan de site sont fournis par l’[API de métadonnées](https://nextjs.org/docs/app/api-reference/functions/generate-metadata#alternates) de Next.js. ## Video The video is narrated in English, with English captions. [How do I set up SEO for a multilingual Next.js app?](https://caxecubb9c64cezv.public.blob.vercel-storage.com/films/kb-multilingual-nextjs-seo.mp4) (50 s) General Translation lets you give every language its own URL and tell search engines about them. Move your pages into `app/[locale]` with `gt-next`'s middleware, set the html `lang` attribute with `useLocale`, add canonical and hreflang links with a helper, translate the title with `getGT`, and list every page in every language in a sitemap. ## Pourquoi Google n’indexe-t-il qu’une seule langue de mon site Next.js ? Google n’indexe qu’une seule langue lorsque toutes les langues partagent la même URL. Googlebot [envoie ses requêtes sans en-tête `Accept-Language`](https://developers.google.com/search/docs/specialty/international/locale-adaptive-pages) et [ne conserve pas les cookies d’un chargement de page à l’autre](https://developers.google.com/search/docs/crawling-indexing/javascript/fix-search-javascript) : une page qui détermine sa langue à partir de l’un ou de l’autre présente donc systématiquement sa langue par défaut à Google. Les autres langues n’ont aucune URL que Google puisse explorer. La solution consiste à attribuer à chaque langue une URL distincte, déclarée dans les variantes localisées `hreflang` et dans le plan de site. Google [recommande d’utiliser des URL distinctes pour chaque version linguistique](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites) plutôt que des cookies ou les paramètres du navigateur. Une application `gt-next` de General Translation sans middleware présente le même problème : son sélecteur de paramètre régional enregistre le choix dans un cookie et conserve des URL sans préfixe tant que vous n’ajoutez pas [`createNextMiddleware`](/docs/react/nextjs/reference/functions/create-next-middleware). Des pages anglaises et françaises entièrement traduites ne constituent pas des doublons du seul fait qu’elles décrivent le même produit. Google ne considère les versions localisées comme des doublons que si le contenu principal reste non traduit. (Consultez les [recommandations de Google sur les pages localisées](https://developers.google.com/search/docs/specialty/international/localized-versions)). ## Les versions linguistiques doivent-elles utiliser des sous-répertoires, des sous-domaines ou des domaines distincts ? Utilisez des sous-répertoires, comme `example.com/es/about`, sauf si chaque marché nécessite son propre emplacement de serveur ou son propre site. Le guide de Google sur la [gestion des sites multirégionaux et multilingues](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites) présente les sous-répertoires comme faciles à mettre en place et peu exigeants en maintenance, puisque toutes les langues restent sur un même hôte, et déconseille les paramètres d'URL. | Structure | Exemple | Évaluation de Google | Dans une application Next.js | | ---------------------------- | --------------------------- | ---------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Sous-répertoires | `example.com/es/about` | Faciles à mettre en place, maintenance réduite (même hôte), un seul emplacement de serveur | Le middleware `gt-next` de General Translation gère cette structure par défaut | | Sous-domaines | `es.example.com/about` | Faciles à mettre en place, permettent des emplacements de serveur différents | Routage basé sur l'hôte, à écrire vous-même ; [`createNextMiddleware`](/docs/react/nextjs/reference/functions/create-next-middleware) effectue le routage par chemin | | Domaines nationaux | `example.es/about` | Ciblage géographique clair, mais coûteux, davantage d'infrastructure et un seul pays par domaine | Un déploiement ou un routage basé sur l'hôte pour chaque domaine | | Paramètres d'URL | `example.com/about?lang=es` | Déconseillés | À éviter | | Cookie ou en-tête uniquement | `example.com/about` | Des URL distinctes sont recommandées à la place | Indexation dans une seule langue | Utilisez des sous-domaines ou des domaines nationaux lorsque les marchés nécessitent un hébergement distinct ou un ciblage par pays. Pour un déploiement Next.js unique, les sous-répertoires demandent le moins de code : le middleware `gt-next` de General Translation gère `/es/about` par défaut, tandis que les sous-domaines et les domaines nationaux nécessitent un routage basé sur l'hôte, à écrire vous-même. (Consultez la [comparaison des structures d'URL](/kb/multilingual-url-structure) pour en connaître les avantages et inconvénients.) ## Comment attribuer à chaque langue sa propre URL dans Next.js ? Ajoutez un middleware de routage selon les paramètres régionaux ainsi qu'un segment de route `app/[locale]`. Avec `gt-next` de General Translation, créez un fichier `proxy.ts` à la racine du projet (`middleware.ts` pour Next.js 15 et versions antérieures) : ```ts title="proxy.ts" import { createNextMiddleware } from 'gt-next/middleware'; export default createNextMiddleware({ prefixDefaultLocale: true }); export const config = { matcher: ['/((?!api|static|.*\\..*|_next).*)'], }; ``` Déplacez ensuite vos pages dans `app/[locale]` : ```text proxy.ts app/ ├── sitemap.ts └── [locale]/ ├── layout.tsx ├── page.tsx └── about/ └── page.tsx ``` `prefixDefaultLocale: true` place tous les paramètres régionaux, y compris l'anglais, sous un préfixe : chaque URL de contenu sert donc toujours une seule langue. Cet article utilise cette configuration tout du long. Un chemin sans préfixe tel que `/about` devient un point d’entrée : le middleware répond par une redirection temporaire `307` vers le paramètre régional enregistré du visiteur ou vers la meilleure correspondance `Accept-Language`, ou vers `/en/about` à défaut des deux. Une URL localisée ne change jamais : `/en/about` renvoie la version anglaise, même à un navigateur qui préfère le français. Sans cette option, les paramètres régionaux par défaut ne sont pas préfixés et `/about` peut rediriger en fonction du cookie ou de l'en-tête du navigateur. (Consultez [routage selon les paramètres régionaux et SEO](/kb/locale-routing-seo) pour comprendre pourquoi c'est important.) Deux autres paramètres modifient le routage : * [`pathConfig`](/docs/react/nextjs/reference/functions/create-next-middleware#path-config) traduit les chemins, par exemple `/fr/a-propos` pour `/about`. * [`ignoreBrowserLocales: true`](/docs/react/nextjs/config#ignore-browser-locales) dans `withGTConfig` empêche le middleware de déduire le paramètre régional de l'en-tête `Accept-Language`. Google [déconseille de rediriger](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites) les visiteurs sur la base d'une supposition quant à leur langue. Si vous prérendez des pages avec `generateStaticParams`, ajoutez également un fichier `getLocale.ts` à la racine du projet, car le middleware ne s'exécute pas lors de la génération statique. Le [guide du middleware pour l'App Router](/docs/react/nextjs/app-router-middleware#root-locale) fournit ce fichier ainsi que toutes les étapes de configuration du routage. ## Comment définir l'attribut html lang pour chaque paramètre régional ? Définissez `lang` à partir du paramètre de route `[locale]` dans la mise en page racine, `app/[locale]/layout.tsx`. Grâce à la vérification [`isLocaleSupported`](/docs/react/nextjs/reference/functions/is-locale-supported), un paramètre régional que vous n'avez pas configuré renvoie une erreur 404 au lieu d'afficher, à cette URL, le contenu dans les paramètres régionaux par défaut : ```tsx title="app/[locale]/layout.tsx" import { GTProvider, isLocaleSupported } from 'gt-next'; import { notFound } from 'next/navigation'; export default async function LocaleLayout({ children, params, }: { children: React.ReactNode; params: Promise<{ locale: string }>; }) { const { locale } = await params; if (!isLocaleSupported(locale)) { notFound(); } return ( {children} ); } ``` L'attribut `lang` indique la langue de la page aux technologies d'assistance et aux navigateurs pour les comportements qui dépendent de la langue. Google détermine la langue à partir du [contenu visible](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites#language), et non de l'attribut `lang`. Veillez donc à ce qu'il soit exact pour l'accessibilité, plutôt que de le considérer comme un levier de classement. La mise en page racine doit se trouver dans `app/[locale]/layout.tsx` lorsque les pages sont prérendues, car une mise en page située au-dessus du segment `[locale]` ne peut pas lire le paramètre régional lors de la génération statique. Si un segment d'URL est un alias, comme `/cn` pour le chinois, convertissez-le avec [`resolveCanonicalLocale`](/docs/react/nextjs/reference/functions/resolve-canonical-locale) pour que `lang` vaille `zh`. Pour la gestion des alias dans les métadonnées et le plan de site, consultez [Gérer le SEO des alias de paramètres régionaux](/docs/react/nextjs/locale-alias-seo). ## Comment ajouter des liens alternatifs hreflang et des URL canoniques dans l'App Router de Next.js ? Dans l'App Router de Next.js, ajoutez des liens alternatifs `hreflang` en renvoyant `alternates.languages` depuis la fonction `generateMetadata` de chaque page, et l'URL canonique en renvoyant `alternates.canonical`. Next.js affiche chaque entrée de `alternates.languages` sous la forme d'une balise ``. Google exige que [chaque version linguistique se référence elle-même ainsi que toutes les autres versions](https://developers.google.com/search/docs/specialty/international/localized-versions) et ignore les liens `hreflang` qui ne sont pas déclarés réciproquement par les deux pages : chaque version d'une page doit donc renvoyer la même liste. L'entrée `x-default` désigne l'URL destinée aux visiteurs dont la langue ne correspond à aucune des versions. L'URL canonique de chaque version pointe vers sa propre URL ; évitez de faire pointer les pages traduites vers la version anglaise. Une URL canonique est une indication, pas une garantie. (Voir [balises hreflang et canoniques](/kb/what-is-hreflang#should-hreflang-pages-use-self-referencing-canonicals)). Une traduction peut être en retard par rapport à sa page : générez donc l'URL canonique, les variantes localisées et le plan de site à partir d'une source unique qui recense les paramètres régionaux dans lesquels chaque page est publiée. Cet utilitaire construit l'URL canonique et les variantes localisées à partir de cette source, et marque en `noindex` toute version qui n'est pas encore publiée : ```ts title="lib/i18n-metadata.ts" import type { Metadata } from 'next'; import { getLocale } from 'gt-next/server'; export const BASE_URL = 'https://example.com'; // Les paramètres régionaux dans lesquels chaque page est publiée. Ajoutez un paramètre régional une fois sa traduction relue. export const PUBLISHED: Record = { '/': ['en', 'fr', 'es'], '/about': ['en', 'fr', 'es'], '/pricing': ['en', 'fr'], // L'espagnol n'est pas encore traduit }; export const localeUrl = (locale: string, path: string) => `${BASE_URL}/${locale}${path === '/' ? '' : path}`; export async function getI18NMetadata(path: string): Promise { const locale = await getLocale(); const published = PUBLISHED[path] ?? []; // Exclure de l'index une version non encore publiée. if (!published.includes(locale)) { return { robots: { index: false }, alternates: null, }; } const languages: Record = {}; for (const loc of published) languages[loc] = localeUrl(loc, path); languages['x-default'] = localeUrl(published.includes('en') ? 'en' : published[0], path); return { alternates: { canonical: localeUrl(locale, path), languages } }; } ``` Appelez-la ensuite depuis chaque page : ```tsx title="app/[locale]/pricing/page.tsx" import { getI18NMetadata } from '@/lib/i18n-metadata'; export async function generateMetadata() { return getI18NMetadata('/pricing'); } ``` Compilée avec Next.js 16.4.2 et `gt-next` 11.4.14, la page `/fr/about`, publiée dans les trois langues, a affiché le `` suivant : ```html title="/fr/about" ``` `/fr/pricing` ne déclare aucune version alternative en espagnol, car la page de tarifs en espagnol n'est pas publiée : ```html title="/fr/pricing" ``` La route répond toujours à `/es/pricing`, mais son `` ne contient que ``, sans URL canonique ni variantes localisées, de sorte que les robots d'exploration peuvent découvrir l'instruction `noindex`. Définir `alternates: null` supprime toute URL canonique ou variante localisée héritée d'une mise en page parente. Laissez la route accessible aux robots d'exploration : `noindex` n'est pas un mécanisme de contrôle d'accès. `x-default` pointe vers l'anglais s'il est publié, sinon vers le premier paramètre régional publié. L'utilitaire part du principe que le chemin est identique pour chaque paramètre régional ; si vous utilisez des chemins traduits issus de `pathConfig`, des slugs localisés ou des alias de route, construisez plutôt l'URL de chaque paramètre régional à partir de cette table de routes, afin que `fr` pointe vers `/fr/a-propos`. Proposez également un [sélecteur de langue](/kb/language-switcher) avec des liens classiques vers les pages équivalentes. Hreflang ne remplace pas une option de navigation visible. ## Comment traduire les titres de page et les méta-descriptions pour chaque paramètre régional dans Next.js ? Traduisez les chaînes renvoyées par `generateMetadata`. Les résultats de recherche affichent généralement le titre et la description d'une page : une page en espagnol dotée d'un titre en anglais fera donc apparaître du texte en anglais dans les résultats de recherche en espagnol. Les moteurs de recherche peuvent aussi réécrire les titres et les extraits affichés ; les métadonnées fournies ne garantissent donc pas une présentation identique. La fonction [`getGT`](/docs/react/nextjs/reference/functions/get-gt) de General Translation, exportée par `gt-next/server`, renvoie une fonction de traduction pour le paramètre régional de la requête en cours et peut être utilisée dans `generateMetadata`. Renvoyez le titre et la description traduits, accompagnés des variantes localisées fournies par l'utilitaire : ```tsx title="app/[locale]/about/page.tsx" import type { Metadata } from 'next'; import { getGT } from 'gt-next/server'; import { getI18NMetadata } from '@/lib/i18n-metadata'; export async function generateMetadata(): Promise { const gt = await getGT(); const i18nMeta = await getI18NMetadata('/about'); return { title: gt('About us'), description: gt('Meet the team that builds our product.'), ...i18nMeta, }; } ``` Passez des littéraux de chaîne de caractères, comme ci-dessus, pour que l'étape de compilation puisse les détecter. Les traductions de production pour [`getGT`](/docs/react/nextjs/reference/functions/get-gt) sont préparées avant le déploiement : exécutez donc [`npx gt translate`](/docs/cli/reference/commands/translate) avant `next build` : ```json title="package.json" { "scripts": { "build": "npx gt translate && next build" } } ``` Lorsque le titre anglais change, la compilation suivante traduit le nouveau texte dans chaque paramètre régional, sans aucun fichier de messages à mettre à jour. Relisez les titres et les descriptions dans l’[éditeur du tableau de bord](/docs/platform/dashboard/guides/reviewing-translations) avant d’ajouter un paramètre régional à `PUBLISHED`. Les [termes partagés du glossaire](/docs/platform/dashboard/guides/defining-context-for-translations) contribuent à garantir la cohérence des noms de produits entre la page et ses métadonnées de recherche. Après la publication, mesurez les impressions, les clics et les conversions réels plutôt que de tabler sur une amélioration fixe du taux de clics. (Pour en savoir plus sur les mots-clés par marché, la longueur des textes selon les langues et les balises Open Graph, consultez [Comment traduire les titres SEO et les méta-descriptions ?](/kb/translate-seo-metadata)) ## Comment ajouter toutes les langues à un plan de site Next.js ? Dans `app/sitemap.ts`, ajoutez une entrée par page et par paramètre régional publié. Lisez le même Record `PUBLISHED` pour que le plan de site et les liens `hreflang` restent toujours cohérents : ```ts title="app/sitemap.ts" import type { MetadataRoute } from 'next'; import { PUBLISHED, localeUrl } from '@/lib/i18n-metadata'; export default function sitemap(): MetadataRoute.Sitemap { return Object.entries(PUBLISHED).flatMap(([path, locales]) => locales.map((locale) => ({ url: localeUrl(locale, path) })), ); } ``` Le fichier `/sitemap.xml` généré répertoriait huit URL : `/en`, `/fr`, `/es`, les trois versions de `/about`, `/en/pricing` et `/fr/pricing`. `/es/pricing` en reste exclue tant qu'elle n'est pas publiée. Si vous ajoutez `lastModified`, indiquez la date de la dernière mise à jour substantielle de la page, et non l'heure de génération du plan de site. (Consultez les [recommandations de Google sur les plans de site](https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap)). Comme les métadonnées de la page déclarent déjà `hreflang` dans le HTML, ce plan de site se contente de répertorier les URL. Vous pouvez aussi déclarer `hreflang` dans le plan de site à la place : attribuez à chaque entrée un objet `alternates.languages`, que Next.js 14.2 et versions ultérieures transforme en variantes localisées `xhtml:link` dans chaque ``. Google traite [`hreflang` dans un plan de site](https://developers.google.com/search/docs/specialty/international/localized-versions) exactement comme `hreflang` dans le HTML. Selon Google, combiner les deux méthodes n'apporte aucun avantage supplémentaire dans la recherche : choisissez-en donc une seule. La [référence Next.js sur les plans de site](https://nextjs.org/docs/app/api-reference/file-conventions/metadata/sitemap#generate-a-localized-sitemap) documente le champ `alternates`. (Consultez [Comment créer un plan de site pour un site web multilingue ?](/kb/multilingual-sitemap) pour connaître les limites de taille, la répartition à l'aide d'un index de plans de site et les vérifications à effectuer avant de le soumettre.) ## Quelle bibliothèque d’i18n pour Next.js gère les routes par paramètre régional et le hreflang pour le SEO ? Pour le SEO, une bibliothèque d’i18n pour Next.js doit attribuer à chaque langue sa propre URL. `gt-next` de General Translation et next-intl le font tous deux grâce à un middleware App Router ; avec i18next et react-intl, le routage reste à votre charge. Le middleware de next-intl envoie également les variantes localisées `hreflang` dans un en-tête HTTP, et `gt-next` traduit les titres et les descriptions lors de la compilation, sans fichiers de messages. Aucune de ces bibliothèques ne génère pour vous l’URL canonique ni le plan de site. | Approche | URL par langue | `hreflang` | Titres et descriptions traduits | URL canonique et plan de site | | ------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- | | next-intl | Middleware avec préfixes de paramètre régional (`/en/about` par défaut), chemins localisés ou un domaine par paramètre régional | Par défaut, le middleware [envoie les variantes localisées, y compris `x-default`, dans un en-tête HTTP `Link`](https://next-intl.dev/docs/routing/configuration#alternate-links) | Messages rédigés par votre équipe ou un service de traduction dans le catalogue JSON de chaque langue | À écrire vous-même | | i18next ou react-intl | Pas de routage Next.js ; le middleware est à écrire vous-même | À écrire vous-même | Messages dans le catalogue de chaque langue | À écrire vous-même | | Google Traduction dans le navigateur du visiteur | Une URL par page | Aucun | Traduits uniquement dans le navigateur ; les résultats de recherche affichent la langue source | Une seule URL, donc rien à lister | | Une API d’IA brute (OpenAI API, Claude API) | Routes à créer vous-même | À écrire vous-même | Un script à relancer après chaque modification du texte | À écrire vous-même | | General Translation (`gt-next` et la CLI `gt`) | [`createNextMiddleware`](/docs/react/nextjs/reference/functions/create-next-middleware) sert `/en/about`, `/es/about` et des chemins traduits tels que `/fr/a-propos` | Vous renvoyez depuis `generateMetadata` un objet `alternates.languages` construit à partir d’un Record des paramètres régionaux publiés | Chaînes [`getGT`](/docs/react/nextjs/reference/functions/get-gt), traduites par [`npx gt translate`](/docs/cli/reference/commands/translate) avant `next build` | Vous les écrivez dans `generateMetadata` et `app/sitemap.ts` à partir de ce même Record | Choisissez next-intl si votre équipe maintient déjà des catalogues de messages et souhaite que le `hreflang` soit envoyé par le middleware. Choisissez i18next ou react-intl si vous disposez de traducteurs, de textes qui changent rarement et du temps nécessaire pour écrire le routage. Réservez la traduction dans le navigateur aux pages qui n’ont pas besoin de trafic de recherche dans d’autres langues, comme une application accessible uniquement après connexion, que les moteurs de recherche ne peuvent pas explorer. Choisissez `gt-next` de General Translation si l’application publie souvent de nouveaux textes et que chaque version linguistique doit avoir sa propre page indexée et son titre traduit : le texte reste intégré dans vos composants, et la compilation traduit les pages et les titres en même temps. La plateforme et la documentation de Profound sont disponibles dans plus de 47 paramètres régionaux grâce à General Translation. (Voir les [déploiements en production](https://generaltranslation.com/enterprise).) ## Related questions - [Redirections linguistiques et SEO : URL, cookie ou Accept-Language ?](https://generaltranslation.com/fr/kb/locale-routing-seo.mdx): 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. - [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. - [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. - [Liste de contrôle des tests de localisation pour les applications multilingues](https://generaltranslation.com/fr/kb/multilingual-app-launch-checklist.mdx): Testez neuf points dans chaque paramètre régional pris en charge sur une compilation de Production : les parcours complets, y compris les états d’erreur et les e-mails, le changement de langue, les formes plurielles, la devise et les fuseaux horaires, le foisonnement du texte, la mise en page right-to-left, l’accessibilité, la distribution des traductions et des URL de langue explorables. Associez à chaque vérification un critère de réussite explicite. ## Previous and next questions - Previous question: [Comment traduire du texte conditionnel en JSX ?](https://generaltranslation.com/fr/kb/translate-conditional-jsx.mdx) - Next question: [Quel est le meilleur logiciel de localisation pour les développeurs ?](https://generaltranslation.com/fr/kb/best-localization-software.mdx) ## Sitemap See the [Knowledge Base sitemap](https://generaltranslation.com/fr/kb/sitemap.md) for every article.