Traduire un site Next.js : routes linguistiques explorables et SEO

Traduire un site Next.js ne se résume pas à utiliser une bibliothèque d’internationalisation (i18n). Les moteurs de recherche ont besoin d’URL distinctes et explorables pour chaque version linguistique, avec des métadonnées et un contenu textuel présents dans la réponse HTML initiale. Les changements de langue fondés sur les cookies ou effectués uniquement côté client sur une URL unique ne fournissent pas à Google de pages distinctes à indexer.

En bref : les routes linguistiques explorables sont préférables aux changements de langue par cookies

S’il ne fallait retenir qu’une règle avant d’aborder les segments de l’App Router : attribuez à chaque langue sa propre URL explorable. Google recommande des URL différentes pour chaque langue ou région plutôt qu’un fonctionnement reposant uniquement sur les cookies ou la langue du navigateur. Les préfixes de chemin comme /en/ et /de/, les sous-domaines dédiés ou les domaines distincts créent tous des adresses indexables. Ce n’est pas le cas des changements de langue reposant uniquement sur les cookies à une même URL.

Le changement de langue fondé sur les cookies peut sembler pratique pendant le développement, car il évite de dupliquer les routes. Mais en production, cette approche masque les variantes linguistiques aux robots d’exploration, au détriment du SEO. Les versions linguistiques définies par le chemin disposent d’adresses stables que vous pouvez inclure dans les sitemaps, annoter avec hreflang et suivre dans Search Console. Pour approfondir la distinction entre stratégie par marché et stratégie par langue, consultez notre guide sur le SEO international et le SEO multilingue.

Choisir une structure d’URL Next.js pour les langues

Les équipes qui utilisent Next.js choisissent généralement l’une de ces trois structures explorables :

1. Sous-répertoires — example.com/en/docs, example.com/fr/docs. Faciles à déployer sur un seul hôte ; hiérarchie claire pour hreflang.
2. Sous-domaines — en.example.com, fr.example.com. Utiles lorsque les équipes régionales fonctionnent de manière semi-indépendante ; nécessitent tout de même des annotations hreflang réciproques.
3. ccTLD ou domaines dédiés — le signal géographique le plus fort lorsque vous gérez réellement des sites distincts ; la charge opérationnelle la plus élevée.

Google détermine la langue d’une page principalement à partir de son contenu visible. Quelle que soit la structure choisie, veillez à ce que chaque URL présente un contenu majoritairement dans une seule langue, y compris la navigation, les liens de pied de page et les pages d’erreur. Évitez de mélanger les langues dans un même modèle de page sans raison claire pour l’utilisateur.

Ne redirigez pas automatiquement les visiteurs en fonction d’une langue ou d’une localisation supposée. Google déconseille cette pratique, car elle peut bloquer les robots d’exploration et frustrer les utilisateurs. Proposez plutôt un sélecteur de langue visible qui renvoie vers l’URL de la version linguistique correspondante.

App Router et conception des segments linguistiques

Dans l’App Router, l’approche courante consiste à utiliser un segment dynamique [locale] : app/[locale]/layout.tsx englobe les pages localisées. Définissez les paramètres régionaux pris en charge dans un seul objet de configuration et validez params.locale dans les layouts ou le middleware. Les paramètres régionaux non valides doivent renvoyer une erreur 404, et non afficher silencieusement une version anglaise à la même URL.

Le middleware peut rediriger le chemin racine / vers un dossier de langue par défaut tel que /en/, mais les autres versions doivent rester accessibles par des liens. Associez le middleware à generateStaticParams lorsque vous générez statiquement des pages marketing, afin que chaque version linguistique soit générée à l’avance.

Langue définie par cookie ou par chemin : La négociation par cookie ou par en-tête sur une URL unique modifie le contenu sans changer l’adresse. Les robots d’exploration ne récupèrent généralement une URL qu’une fois ; ils ne verront donc pas toutes les variantes linguistiques. Les versions linguistiques définies par le chemin, ou leurs équivalents sur des sous-domaines ou domaines distincts, respectent la recommandation de Google d’utiliser des URL différentes. Les cookies peuvent toujours enregistrer la préférence des utilisateurs après leur choix de langue, tant que les URL publiques restent distinctes.

Utilisez next-intl, next-i18next ou des bibliothèques similaires pour charger les messages, mais laissez le routage définir les URL publiques, et non les seuls cookies.

Localiser les métadonnées, Open Graph et les données structurées

Chaque route localisée doit disposer de ses propres <title>, méta-description, URL canonique et balises Open Graph dans le HTML rendu côté serveur. Avec l’App Router, utilisez generateMetadata pour chaque page, en récupérant les chaînes traduites dans vos fichiers de messages. Le titre et la méta-description localisés ne doivent pas dépendre d’un changement de langue côté client après l’hydratation.

Appliquez la même rigueur au JSON-LD : les blocs WebPage, Organization et FAQ doivent utiliser des chaînes traduites et des valeurs inLanguage adaptées à la langue et à la région. Si vous générez des éléments link hreflang, produisez l’ensemble complet des liens réciproques dans le layout ou dans la fonction utilitaire de métadonnées de la page : l’absence de liens de retour rompt les groupes hreflang.

Hreflang, URL canoniques et sitemaps pour Next.js

Hreflang indique à Google les URL des variantes linguistiques ou régionales. Chaque URL d’un groupe doit faire référence à toutes les autres, ainsi qu’à elle-même, avec les codes correspondants. Implémentez hreflang dans <head>, dans les en-têtes HTTP ou dans les sitemaps XML au moyen d’entrées xhtml:link : choisissez une seule méthode et appliquez-la de manière cohérente sur tout le site.

Chaque URL localisée doit également comporter une balise canonique pointant vers l’URL à privilégier pour cette langue lorsque des doublons existent, par exemple à cause de paramètres de suivi ou de versions imprimables. Ne faites pas pointer l’URL canonique d’une page française vers son équivalent anglais : les balises canoniques regroupent les doublons au sein d’une même langue.

Générez des sitemaps par version linguistique ou un index de sitemaps répertoriant les URL de toutes les langues. Les sitemaps facilitent la découverte des pages et peuvent contenir des annotations hreflang. Après le déploiement, vérifiez un échantillon d’URL avec l’outil d’inspection d’URL de la Search Console et une procédure de test hreflang. Notre présentation de la plateforme SEO multilingue explique comment les équipes SEO contrôlent ces signaux dans les différentes versions linguistiques et régionales.

Éviter les structures de page dont la langue dépend uniquement du client

Une erreur fréquente avec Next.js consiste à générer une structure HTML en anglais, puis à remplacer les chaînes dans useEffect. Les robots d’exploration n’exécutent pas toujours ce remplacement correctement, et les utilisateurs voient brièvement la mauvaise langue. Les composants serveur, la génération statique ou le rendu côté serveur (SSR) doivent fournir le contenu traduit dès la première réponse. Les composants client peuvent hydrater les éléments interactifs, mais les textes marketing et les titres doivent figurer dans l’arbre des composants serveur.

Les routes localisées reposant sur des chemins ou des sous-domaines créent des URL distinctes que les robots peuvent explorer ; un changement de langue reposant uniquement sur les cookies ne répond pas à la recommandation de Google. Si vous utilisez un proxy de traduction pour la prévisualisation, assurez-vous qu’en production, chaque URL localisée fournit bien un HTML complet.

Processus de gestion du contenu : glossaire, mémoire de traduction et révision

Les choix techniques ne suffisent pas à réussir sur un marché si les traductions s’écartent de la terminologie du produit. Complétez les fichiers i18n de Next.js par un glossaire, une mémoire de traduction et une révision humaine. Les recommandations de Google sur les contenus utiles privilégient les pages conçues avant tout pour les internautes ; les versions linguistiques pauvres en contenu ou composées uniquement de textes standardisés sont peu performantes en SEO et constituent de faibles sources de réponses.

Exemple de processus :

• Extrayez les chaînes des fichiers JSON ou PO et intégrez-les à un flux de travail compatible avec les outils de TAO.
• Imposez le respect du glossaire pour les noms de produits et les libellés de l’interface.
• Effectuez un contrôle qualité linguistique sur les URL de préproduction, sans vous limiter à comparer les fichiers sources.
• Resynchronisez les traductions lorsque le texte source anglais change : des versions linguistiques obsolètes érodent la confiance.

Liste de contrôle de mise en œuvre

Avant la mise en ligne, vérifiez les chemins d’exploration, les métadonnées et les annotations :

• Une URL publique distincte par version linguistique ou régionale (chemin, sous-domaine ou domaine)
• Un sélecteur de langue visible avec des liens vers les URL des autres versions
• Des titres et descriptions rendus côté serveur pour chaque version linguistique ou régionale
• Des liens hreflang réciproques dans l’ensemble du groupe
• Des URL canoniques propres à chaque langue, sans renvoi vers une autre langue
• Des entrées de sitemap tenant compte de la langue et de la région
• Aucune redirection automatique selon la zone géographique ou la langue qui bloque les robots d’exploration
• Un contrôle qualité en préproduction dans les langues cibles, en parcourant réellement le site

Les consignes de Bing pour les webmasters insistent elles aussi sur l’importance d’un contenu utile et accessible aux robots d’exploration, ainsi que d’une structure claire : les bonnes pratiques qui aident Google favorisent généralement aussi l’indexation par Bing.

Erreurs courantes

Choix de langue reposant uniquement sur un cookie, avec une URL unique — masque les variantes aux robots d’exploration.

Absence de liens hreflang de retour — rompt la réciprocité et fragilise le regroupement des pages.

URL canonique pointant vers l’anglais sur les pages traduites — envoie un signal de consolidation erroné.

Métadonnées générées uniquement côté client — titres et descriptions absents du HTML initial.

Redirection automatique selon l’adresse IP ou Accept-Language — bloque les robots d’exploration et ignore le choix de l’utilisateur.

Éléments d’interface non traduits — une navigation mêlant plusieurs langues perturbe la détection de la langue.

Traduction automatique sommaire, sans révision — ne répond pas aux exigences en matière de contenu utile.

Les fondamentaux de la recherche traditionnelle et des moteurs de réponse

Les mêmes fondamentaux pour les routes multilingues Next.js et le HTML généré côté serveur restent essentiels pour Google, Bing et les moteurs de réponse : des versions linguistiques explorables, des entités clairement identifiées, des affirmations étayées, des données structurées fidèles au contenu et une véritable localisation — pas de simples coquilles en anglais. Considérez les guides ci-dessous comme des éclairages propres à chaque plateforme sur un même niveau d’exigence pour le déploiement multilingue.

Guide par plateforme : Google Search

Sur Google Search, la découverte des pages repose sur des URL localisées explorables, avec un HTML adapté à la langue, des titres et des intertitres précis, ainsi que des annotations hreflang réciproques lorsqu’il existe des versions alternatives. Les bases techniques comprennent du contenu indexable, et non des changements de langue reposant uniquement sur des cookies, des métadonnées localisées, des sitemaps et une gestion rigoureuse des URL canoniques. Un contenu de qualité suppose un contenu principal conçu d’abord pour les internautes dans chaque langue ; l’autorité repose sur une identité d’organisation claire et des sources concordantes, pas sur le discours marketing d’un outil de traduction. Conséquence pour le multilingue : chaque URL propre à un marché ou à une langue doit se suffire à elle-même. Mesurez les résultats à l’aide des rapports de couverture et de l’outil d’inspection d’URL de Search Console pour chaque version locale. Ce qui est établi et ce qui reste incertain : Google documente le fonctionnement du multilingue et de hreflang, mais ne garantit aucun positionnement lié à un CMS ou à un processus de post-édition de traduction automatique (MTPE).

Guide par plateforme : Bing

Bing découvre et indexe les pages multilingues explorables dont la structure est claire, avec des exigences de clarté des URL et du contenu similaires à celles de Google. Les bases techniques comprennent des URL localisées accessibles aux robots, du contenu utile et un suivi dans Bing Webmaster Tools. Privilégiez la localisation des titres, des affirmations et des FAQ plutôt que la seule traduction de l’interface. Les signaux d’autorité reposent toujours sur des sources fiables et des entités cohérentes. Conséquence pour le multilingue : ne masquez pas les langues derrière des sélecteurs fonctionnant uniquement côté client. Mesurez l’indexation et les statistiques d’exploration dans Bing Webmaster Tools. Ce qui est établi et ce qui reste incertain : les consignes de Bing mettent l’accent sur du contenu utile et explorable ; n’inventez pas de facteurs de classement propres à Bing pour les outils de traduction.

Guide par plateforme : ChatGPT

ChatGPT peut citer ou résumer des pages accessibles au public lorsque leurs versions linguistiques sont clairement identifiées et que leur contenu se prête à la formulation de réponses. La découverte ne suit pas un classement classique fondé sur l’exploration : la visibilité consiste à être sélectionné comme source ou mentionné dans les réponses. Les bases techniques reposent toujours en premier lieu sur des URL HTML accessibles, et non sur des widgets en surcouche qui masquent le texte. Parmi les qualités utiles du contenu figurent des réponses directes, des FAQ et une terminologie stable issue de glossaires. L’autorité repose sur des preuves et sur la cohérence des entités entre les versions locales. Conséquence pour le multilingue : chaque page localisée doit être compréhensible de manière autonome. La mesure reste imparfaite : considérez les vérifications de citations comme des hypothèses à tester. Ce qui est établi et ce qui reste incertain : aucune garantie documentée n’indique que la MTPE ou une quelconque intégration à un CMS permet d’obtenir des citations dans ChatGPT.

Guide par plateforme : Gemini

Gemini et les expériences d’IA associées de Google bénéficient d’entités cohérentes, de données structurées conformes à la réalité et de pages localisées indexables. La visibilité consiste à être cité ou reconnu, pas à inventer des facteurs de classement pour Gemini. Les bases techniques recoupent les exigences de Google Search en matière d’explorabilité et de qualité des métadonnées. Le contenu doit présenter des affirmations et des définitions claires dans chaque langue. L’autorité dépend de la cohérence de l’identité de l’organisation et d’éléments corroborants. Conséquence pour le multilingue : des noms de produits encadrés par un glossaire réduisent les confusions entre les versions locales. Mesurez les performances de manière classique avec Search Console et analysez qualitativement un échantillon de réponses de l’IA. Ce qui est établi et ce qui reste incertain : le comportement de Gemini ne remplace pas les recommandations documentées de Google Search concernant hreflang et les versions linguistiques.

Guide par plateforme : Google AI Overviews

Google AI Overviews peut proposer des liens vers des pages qui étayent ses réponses ; les critères d’éligibilité reposent toujours sur un contenu indexable, conçu d’abord pour les internautes. Ces aperçus ne sont pas un sélecteur de langue et ne remplacent pas hreflang. Les bases techniques restent un HTML localisé explorable et des données structurées conformes à la réalité. Un contenu de qualité comprend des réponses concises et des titres clairs dans chaque langue. Les signaux d’autorité reflètent les exigences relatives au contenu utile. Conséquence pour le multilingue : aucune page traduite n’est assurée d’être incluse dans un aperçu. Utilisez les rapports de Search Console sur les résultats génératifs lorsqu’ils sont disponibles, tout en suivant séparément les indicateurs d’indexation classiques. Ce qui est établi et ce qui reste incertain : aucun processus de traduction ne peut promettre une présence dans les aperçus.

Le rôle de GlotEO

Une internationalisation Next.js développée sur mesure convient aux petits sites ; le passage à l’échelle nécessite une gestion du glossaire, des files de révision et une validation SEO pour chaque version linguistique. GlotEO s’intègre aux stacks modernes pour permettre aux équipes marketing de gérer les traductions, tandis que les développeurs conservent la structure de l’App Router.

Les équipes qui abordent la localisation comme un enjeu de routage et de qualité du contenu — et non comme un simple remplacement de chaînes de texte — livrent plus rapidement de nouvelles versions sans compromettre les chemins d’exploration. Partagez un glossaire avant que les traducteurs ne commencent, vérifiez les pages en contexte sur l’environnement de préproduction et contrôlez à nouveau les annotations hreflang à chaque ajout de routes. Suivez l’indexation dans Search Console par dossier linguistique ou par sous-domaine, plutôt que de vous fier à des données agrégées pour l’ensemble du site.

Découvrez la plateforme de localisation de sites web sur Localisation de sites web GlotEO et comparez les tarifs et offres GlotEO pour définir le périmètre de votre déploiement.