# TranslatePress Double Language Prefix: Fix /fr/fr/ URLs

> Seeing /fr/fr/ in a TranslatePress URL? Find where the extra language folder appears, fix the source and see how LingoWP handles existing prefixes.

- URL: https://www.lingowp.com/blog/translatepress-double-language-prefix/
- Author: Amine Sayagh
- Category: Troubleshooting
- Published: 2026-10-06
- Language: en

Your French homepage should open at `/fr/`, but a language link points to `/fr/fr/`. Or a page that should use `/fr/contact/` becomes `/fr/fr/contact/` when you switch languages.

**Start by finding where the second language folder appears. Check the link before clicking it, the address reached afterward, and any hreflang entry for that page. Then correct the setting or integration producing the extra folder.**

A manually entered link, a redirect rule, and an automatically generated language address need different fixes. Changing the language slug or adding another redirect before identifying the cause can make the problem harder to follow.

Here is a practical way to investigate a double language prefix in TranslatePress, followed by how LingoWP handles a URL that already includes a language folder.

*Published by LingoWP. External documentation was checked on 6 October 2026. LingoWP behavior below is based on its developer review for version 1.5. The URL examples illustrate the symptom; its cause depends on the site's configuration.*

## What counts as a double language prefix?

The language prefix is the part of the address that identifies the language version, such as `/fr/` for French.

If that folder is added twice, you may see addresses like these:

| Intended address | Address to investigate |
|---|---|
| `https://example.com/fr/` | `https://example.com/fr/fr/` |
| `https://example.com/fr/contact/` | `https://example.com/fr/fr/contact/` |

Confirm what each path segment means before changing it. If the second `fr` is deliberately the name of a page, `/fr/fr/` may be a legitimate address. It is a repeated prefix when both segments are being used to identify the same language.

Your configured language URL slug also matters. A site using `/fr-be/` should be checked against that setting, rather than assuming every French address must begin with `/fr/`.

## Find where the extra folder first appears

Open one affected page and reproduce the problem slowly. Record the starting address, the language you select, and the final address.

Before clicking a visible link, hover over it or use **Copy link address** to inspect its destination. For a switcher that uses a redirect endpoint, also note the destination specified by that endpoint rather than assuming the endpoint itself is the final page URL.

Then check the page's source for `hreflang` if an SEO audit reported the repeated prefix.

| Observation | Where to investigate first |
|---|---|
| The link already contains `/fr/fr/` | The menu item, button, switcher, or component generating the link |
| The link looks correct, but the address changes to `/fr/fr/` after clicking | Redirect rules or behavior triggered during navigation |
| Visible navigation works, but hreflang lists `/fr/fr/` | The component generating the language annotations |
| Only a custom header switcher fails | That switcher's link setup or integration |
| The problem concerns a repeated site folder such as `/blog/blog/` | Site-base configuration and subfolder routing |

These observations narrow the investigation. They do not, by themselves, prove which plugin is responsible.

## How to fix a repeated language folder in TranslatePress

### 1. Confirm your language URL settings

Open **Settings → TranslatePress → General** and check the slug configured for each language. Compare those values with the working addresses on your site.

Also review **Use subdirectory for default language**. This option adds a language folder to default-language URLs; it is a normal feature, not evidence of a double-prefix bug. Keep it aligned with the URL structure you intend to use. [TranslatePress documents these settings here](https://translatepress.com/docs/settings/).

If you recently changed a language slug, identify links and redirect rules that still refer to the previous one.

Avoid renaming the French language slug simply because `/fr/fr/` appears. A second folder can come from another part of the setup, and changing the slug affects addresses throughout that language version.

### 2. Inspect custom links and header controls

Check the exact menu item, button, or header element that leads to the repeated address. Look at its saved destination, not only its label.

If the saved link literally contains `/fr/fr/`, correct that entry to the verified destination. If it is saved correctly but appears with an extra folder on the public page, investigate how the link is processed.

TranslatePress documents automatic localization of internal links. Its **Force language in custom links** option also handles custom internal links, such as those entered in page content. Review that setting alongside any custom code or builder behavior that adds a language folder. [See the official link translation guidance](https://translatepress.com/docs/translation-editor/translate-links/).

The question to answer is whether two parts of your setup are independently adding the language segment. Do not assume that enabling automatic link handling always produces a repeated prefix.

For a custom language switcher, compare its behavior with a standard TranslatePress switcher on a test page. TranslatePress provides a Language Switcher block and the `[language-switcher]` shortcode. If the standard control works and the custom control fails, focus on the custom implementation. [Its switcher documentation covers the available options](https://translatepress.com/docs/settings/language-switcher/).

### 3. Check redirect rules when the URL changes after clicking

If the link points to the correct address but navigation introduces another `/fr/`, review the redirects involved.

Check your redirect plugin, any automatic language redirection settings, and hosting rules that modify the path. Ask your developer or host to show the redirect chain if the change is not visible in your WordPress settings.

A useful description is:

> This link points to /fr/contact/, but opening it sends me to /fr/fr/contact/. Please check which redirect or navigation step adds the second /fr/.

Correct the rule that generates the extra segment. Avoid adding a broad rule that removes every repeated folder: some repeated path segments may be legitimate page names, and an incorrect replacement can affect unrelated content.

### 4. Separate the site folder from the language folder

If visitors reach your site under a folder such as `/blog/`, that folder is part of the site's public base address. The language folder is a separate part of the route.

Investigate whether a custom link or redirect adds the site's base folder to an address that already includes it. Use a known working page as the reference rather than guessing the correct order of folders.

In **WordPress Settings → General**, distinguish **WordPress Address** from **Site Address**. One identifies where WordPress files are installed; the other identifies the public site address. They can legitimately differ when WordPress has its own directory. [WordPress explains the distinction here](https://wordpress.org/documentation/article/settings-general-screen/).

Do not make those fields identical merely to remove a repeated path. Confirm the actual installation and public routing with your developer or host first.

### 5. If only hreflang is wrong, investigate that output

A working language switcher does not prove that its page annotations use the same correct destination.

Open the affected page, choose **View Page Source**, and search for `hreflang`. Compare the listed language address with the verified working URL. If that address redirects or fails to open, see what to do when [hreflang points to a redirect](/blog/translatepress-hreflang-redirect/) or when [hreflang points to a 404 page](/blog/translatepress-hreflang-404/).

If the repeated prefix appears only there, record the affected page and entry for support. Check which plugin or customization generates the annotation rather than changing menu links that already work.

Hreflang should identify the appropriate language counterpart, and the relevant versions should link back to one another. [Google's localized-page guidance explains that relationship](https://developers.google.com/search/docs/specialty/international/localized-versions).

### 6. Refresh the output and repeat the original action

After correcting the cause, clear the relevant page, hosting, or CDN cache. Retest as a logged-out visitor, then repeat the exact navigation that produced the extra folder.

Check your installed version and relevant release notes if the behavior persists. TranslatePress's changelog includes routing and subdirectory compatibility fixes, so match any proposed fix to the version and configuration you actually use. [Review the current changelog](https://translatepress.com/docs/translatepress-free-changelog/).

Your final checks should include:

- Switching from the original language to French and back.
- Navigating from the French homepage to an internal page.
- Using the header or mobile control that originally failed.
- Checking the affected page's hreflang destination.
- Confirming that a subfolder site keeps its base path intact.

If an incorrectly generated address has already been shared or used, consider an exact redirect to its proper replacement after fixing the source. Google recommends permanent redirects for permanent address changes. A redirect can preserve an existing link, while generated links should use the corrected destination directly. [Read Google's redirect guidance](https://developers.google.com/search/docs/crawling-indexing/301-redirects).

## How LingoWP avoids adding a language prefix twice

A language URL can pass through more than one step while a site builds navigation. Applying the same language again should leave the address stable.

LingoWP's developer review describes recognizing an existing configured language prefix before applying the selected language. That means a URL already localized to French does not receive another French folder when LingoWP processes it again.

For a simple example where the page slug stays the same:

| Starting URL | After applying French |
|---|---|
| `/contact/` | `/fr/contact/` |
| `/fr/contact/` | `/fr/contact/` |

The benefit for the site owner is predictable navigation: the language address can be reused without accumulating language folders.

The review for **LingoWP 1.5** reports tests for repeated language conversion and for preserving the site folder on a subfolder installation. These cover the specific URL-handling behavior described here, including a regression check for an earlier repeated-folder issue.

You manage translations in LingoWP's central workspace while its language links use that routing behavior. If repeated URL corrections have become part of your maintenance routine, this is a concrete feature to assess when comparing plugins. The [LingoWP vs TranslatePress](/blog/lingowp-vs-translatepress/) comparison covers the wider differences.

External rules still need checking. A custom script or hosting redirect can alter a URL after LingoWP generates it. Test your site's actual navigation and integrations on a copy before migrating.

**[Explore LingoWP](https://lingowp.com/)** to see its translation workflow and evaluate it for your site.

## Frequently asked questions

### Should I turn off “Force language in custom links”?

First establish whether custom link handling is involved. On a staging site, compare the affected link with and without that setting, and check whether another customization also adds the language folder. Disabling it permanently may change how other internal links retain the selected language.

### Will clearing the cache remove /fr/fr/ URLs?

It can remove older output after the underlying link or routing rule has been corrected. If the repeated address returns immediately, something is still generating it. Follow that source rather than repeatedly clearing caches.

### Is /fr/fr/ always an invalid URL?

No. The second segment could be a legitimate page slug. Confirm the intended page and route. For a homepage meant to live at `/fr/`, an additional language folder needs investigation.