# Double préfixe de langue TranslatePress : corriger les URL /fr/fr/ > Vous voyez /fr/fr/ dans une URL TranslatePress ? Trouvez où apparaît le dossier de langue en trop, corrigez la source et découvrez comment LingoWP gère les préfixes existants. - URL: https://www.lingowp.com/fr/blog/translatepress-double-prefixe-langue/ - Author: Amine Sayagh - Category: Dépannage - Published: 2026-10-06 - Language: fr Votre page d'accueil française devrait s'ouvrir sur `/fr/`, mais un lien de langue pointe vers `/fr/fr/`. Ou bien une page qui devrait utiliser `/fr/contact/` devient `/fr/fr/contact/` lorsque vous changez de langue. **Commencez par trouver où apparaît le second dossier de langue. Vérifiez le lien avant de cliquer, l'adresse atteinte ensuite et toute entrée hreflang de cette page. Corrigez ensuite le réglage ou l'intégration qui produit le dossier en trop.** Un lien saisi manuellement, une règle de redirection et une adresse de langue générée automatiquement demandent des corrections différentes. Modifier le slug de langue ou ajouter une redirection avant d'identifier la cause peut rendre le problème plus difficile à suivre. Voici une méthode pratique pour enquêter sur un double préfixe de langue dans TranslatePress, suivie de la façon dont LingoWP gère une URL qui contient déjà un dossier de langue. *Publié par LingoWP. La documentation externe a été vérifiée le 6 octobre 2026. Le comportement de LingoWP décrit ci-dessous repose sur sa revue de développement de la version 1.5. Les exemples d'URL illustrent le symptôme ; sa cause dépend de la configuration du site.* ## Qu'est-ce qu'un double préfixe de langue ? Le préfixe de langue est la partie de l'adresse qui identifie la version linguistique, comme `/fr/` pour le français. Si ce dossier est ajouté deux fois, vous pouvez voir des adresses comme celles-ci : | Adresse prévue | Adresse à examiner | |---|---| | `https://example.com/fr/` | `https://example.com/fr/fr/` | | `https://example.com/fr/contact/` | `https://example.com/fr/fr/contact/` | Vérifiez ce que signifie chaque segment du chemin avant de le modifier. Si le second `fr` est volontairement le nom d'une page, `/fr/fr/` peut être une adresse légitime. Il s'agit d'un préfixe répété lorsque les deux segments servent à identifier la même langue. Le slug d'URL configuré pour votre langue compte aussi. Un site qui utilise `/fr-be/` doit être vérifié par rapport à ce réglage, sans supposer que toute adresse française doit commencer par `/fr/`. ## Trouvez où le dossier en trop apparaît en premier Ouvrez une page concernée et reproduisez le problème lentement. Notez l'adresse de départ, la langue choisie et l'adresse finale. Avant de cliquer sur un lien visible, survolez-le ou utilisez **Copier l'adresse du lien** pour voir sa destination. Pour un sélecteur de langue qui passe par une adresse de redirection, notez aussi la destination indiquée par cette adresse au lieu de supposer qu'elle est l'URL finale de la page. Vérifiez ensuite la présence de `hreflang` dans le code source de la page si un audit SEO a signalé le préfixe répété. | Observation | Où chercher en premier | |---|---| | Le lien contient déjà `/fr/fr/` | L'élément de menu, le bouton, le sélecteur ou le composant qui génère le lien | | Le lien semble correct, mais l'adresse devient `/fr/fr/` après le clic | Les règles de redirection ou le comportement déclenché pendant la navigation | | La navigation visible fonctionne, mais hreflang indique `/fr/fr/` | Le composant qui génère les annotations de langue | | Seul un sélecteur de langue personnalisé dans l'en-tête échoue | La configuration des liens ou l'intégration de ce sélecteur | | Le problème concerne un dossier de site répété comme `/blog/blog/` | La configuration de la base du site et le routage en sous-dossier | Ces observations réduisent le champ de recherche. À elles seules, elles ne prouvent pas quelle extension est responsable. ## Comment corriger un dossier de langue répété dans TranslatePress ### 1. Vérifiez vos réglages d'URL de langue Ouvrez **Réglages → TranslatePress → Général** et vérifiez le slug configuré pour chaque langue. Comparez ces valeurs aux adresses qui fonctionnent sur votre site. Vérifiez aussi **Utiliser un sous-répertoire pour la langue par défaut**. Cette option ajoute un dossier de langue aux URL de la langue par défaut ; c'est une fonctionnalité normale, pas la preuve d'un bug de double préfixe. Gardez-la alignée sur la structure d'URL voulue. [TranslatePress documente ces réglages ici](https://translatepress.com/docs/settings/). Si vous avez récemment changé un slug de langue, repérez les liens et les règles de redirection qui utilisent encore l'ancien. Évitez de renommer le slug de la langue française simplement parce que `/fr/fr/` apparaît. Un second dossier peut venir d'une autre partie de la configuration, et changer le slug modifie les adresses de toute cette version linguistique. ### 2. Inspectez les liens personnalisés et les éléments de l'en-tête Vérifiez l'élément de menu, le bouton ou l'élément d'en-tête précis qui mène à l'adresse répétée. Regardez sa destination enregistrée, pas seulement son libellé. Si le lien enregistré contient littéralement `/fr/fr/`, remplacez-le par la destination vérifiée. S'il est enregistré correctement mais apparaît avec un dossier en trop sur la page publique, examinez la façon dont le lien est traité. TranslatePress documente la localisation automatique des liens internes. Son option **Forcer la langue dans les liens personnalisés** traite aussi les liens internes personnalisés, comme ceux saisis dans le contenu des pages. Examinez ce réglage en même temps que tout code personnalisé ou comportement du constructeur de pages qui ajoute un dossier de langue. [Voir les consignes officielles sur la traduction des liens](https://translatepress.com/docs/translation-editor/translate-links/). La question est de savoir si deux parties de votre configuration ajoutent chacune le segment de langue. Ne supposez pas que l'activation du traitement automatique des liens produit toujours un préfixe répété. Pour un sélecteur de langue personnalisé, comparez son comportement avec un sélecteur TranslatePress standard sur une page de test. TranslatePress propose un bloc Language Switcher et le shortcode `[language-switcher]`. Si le contrôle standard fonctionne et que le contrôle personnalisé échoue, concentrez-vous sur l'implémentation personnalisée. [Sa documentation du sélecteur présente les options disponibles](https://translatepress.com/docs/settings/language-switcher/). ### 3. Vérifiez les redirections si l'URL change après le clic Si le lien pointe vers la bonne adresse mais que la navigation ajoute un autre `/fr/`, examinez les redirections en jeu. Vérifiez votre extension de redirection, les éventuels réglages de redirection automatique selon la langue et les règles d'hébergement qui modifient le chemin. Demandez à votre développeur ou à votre hébergeur de vous montrer la chaîne de redirections si le changement n'est pas visible dans vos réglages WordPress. Une description utile serait : > Ce lien pointe vers /fr/contact/, mais l'ouvrir m'envoie vers /fr/fr/contact/. Pouvez-vous vérifier quelle redirection ou étape de navigation ajoute le second /fr/ ? Corrigez la règle qui génère le segment en trop. Évitez d'ajouter une règle générale qui supprime tous les dossiers répétés : certains segments répétés peuvent être des noms de pages légitimes, et un remplacement incorrect peut toucher des contenus sans rapport. ### 4. Distinguez le dossier du site du dossier de langue Si les visiteurs accèdent à votre site sous un dossier comme `/blog/`, ce dossier fait partie de l'adresse publique de base du site. Le dossier de langue est une partie distincte du chemin. Vérifiez si un lien personnalisé ou une redirection ajoute le dossier de base du site à une adresse qui le contient déjà. Prenez une page qui fonctionne comme référence plutôt que de deviner l'ordre correct des dossiers. Dans **Réglages → Général** de WordPress, distinguez l'**Adresse web de WordPress** de l'**Adresse web du site**. L'une indique où sont installés les fichiers de WordPress ; l'autre indique l'adresse publique du site. Elles peuvent légitimement différer lorsque WordPress a son propre répertoire. [WordPress explique la différence ici](https://wordpress.org/documentation/article/settings-general-screen/). Ne rendez pas ces champs identiques uniquement pour supprimer un chemin répété. Confirmez d'abord l'installation et le routage public réels avec votre développeur ou votre hébergeur. ### 5. Si seul hreflang est faux, examinez cette sortie Un sélecteur de langue qui fonctionne ne prouve pas que les annotations de la page utilisent la même destination correcte. Ouvrez la page concernée, choisissez **Afficher le code source de la page** et recherchez `hreflang`. Comparez l'adresse de langue indiquée avec l'URL vérifiée qui fonctionne. Si cette adresse redirige ou ne s'ouvre pas, voyez quoi faire quand [hreflang pointe vers une redirection](/fr/blog/translatepress-hreflang-redirection/) ou quand [hreflang pointe vers une page 404](/fr/blog/translatepress-hreflang-404/). Si le préfixe répété n'apparaît que là, notez la page et l'entrée concernées pour l'assistance. Vérifiez quelle extension ou personnalisation génère l'annotation au lieu de modifier des liens de menu qui fonctionnent déjà. Hreflang doit identifier l'équivalent linguistique approprié, et les versions concernées doivent se renvoyer mutuellement. [Les consignes de Google sur les pages localisées expliquent cette relation](https://developers.google.com/search/docs/specialty/international/localized-versions). ### 6. Actualisez la sortie et répétez l'action d'origine Après avoir corrigé la cause, videz le cache de page, d'hébergement ou de CDN concerné. Testez à nouveau en tant que visiteur déconnecté, puis répétez exactement la navigation qui produisait le dossier en trop. Vérifiez votre version installée et les notes de version pertinentes si le comportement persiste. Le journal des modifications de TranslatePress inclut des corrections de routage et de compatibilité avec les sous-répertoires : rapprochez donc toute correction proposée de la version et de la configuration que vous utilisez réellement. [Consulter le journal des modifications actuel](https://translatepress.com/docs/translatepress-free-changelog/). Vos vérifications finales doivent inclure : - Passer de la langue d'origine au français, puis revenir. - Naviguer de la page d'accueil française vers une page interne. - Utiliser le contrôle d'en-tête ou mobile qui échouait au départ. - Vérifier la destination hreflang de la page concernée. - Confirmer qu'un site en sous-dossier conserve son chemin de base. Si une adresse générée par erreur a déjà été partagée ou utilisée, envisagez une redirection exacte vers son remplacement correct après avoir corrigé la source. Google recommande des redirections permanentes pour les changements d'adresse permanents. Une redirection peut préserver un lien existant, mais les liens générés doivent utiliser directement la destination corrigée. [Lire les consignes de Google sur les redirections](https://developers.google.com/search/docs/crawling-indexing/301-redirects). ## Comment LingoWP évite d'ajouter deux fois un préfixe de langue Une URL de langue peut passer par plusieurs étapes pendant qu'un site construit sa navigation. Appliquer à nouveau la même langue doit laisser l'adresse inchangée. La revue de développement de LingoWP décrit la reconnaissance d'un préfixe de langue configuré déjà présent avant d'appliquer la langue choisie. Une URL déjà localisée en français ne reçoit donc pas un autre dossier français lorsque LingoWP la traite à nouveau. Prenons un exemple simple où le slug de la page reste le même : | URL de départ | Après application du français | |---|---| | `/contact/` | `/fr/contact/` | | `/fr/contact/` | `/fr/contact/` | L'avantage pour le propriétaire du site est une navigation prévisible : l'adresse de langue peut être réutilisée sans accumuler de dossiers de langue. La revue de **LingoWP 1.5** fait état de tests sur la conversion de langue répétée et sur la préservation du dossier du site dans une installation en sous-dossier. Ils couvrent le comportement de traitement des URL décrit ici, y compris un test de non-régression pour un ancien problème de dossier répété. Vous gérez les traductions dans l'espace de travail central de LingoWP tandis que ses liens de langue utilisent ce comportement de routage. Si les corrections d'URL répétées font désormais partie de votre maintenance, c'est une fonctionnalité concrète à évaluer en comparant les extensions. Le comparatif [LingoWP ou TranslatePress](/fr/blog/lingowp-vs-translatepress/) couvre les différences plus larges. Les règles externes doivent quand même être vérifiées. Un script personnalisé ou une redirection d'hébergement peut modifier une URL après sa génération par LingoWP. Testez la navigation et les intégrations réelles de votre site sur une copie avant de migrer. **[Découvrir LingoWP](https://lingowp.com/)** pour voir son workflow de traduction et l'évaluer pour votre site. ## Questions fréquentes ### Dois-je désactiver « Forcer la langue dans les liens personnalisés » ? Établissez d'abord si le traitement des liens personnalisés est en cause. Sur un site de préproduction, comparez le lien concerné avec et sans ce réglage, et vérifiez si une autre personnalisation ajoute aussi le dossier de langue. Le désactiver définitivement peut changer la façon dont d'autres liens internes conservent la langue choisie. ### Vider le cache supprimera-t-il les URL /fr/fr/ ? Cela peut supprimer une ancienne sortie une fois que le lien ou la règle de routage sous-jacent a été corrigé. Si l'adresse répétée revient immédiatement, quelque chose la génère encore. Remontez à cette source au lieu de vider les caches à répétition. ### /fr/fr/ est-elle toujours une URL invalide ? Non. Le second segment peut être un slug de page légitime. Confirmez la page et le chemin prévus. Pour une page d'accueil censée se trouver à `/fr/`, un dossier de langue supplémentaire mérite une vérification.