Duplicate Hreflang Tags in TranslatePress: What to Fix

Your SEO audit reports duplicate hreflang tags. You check the page and find two French entries. Should you delete one?

Compare the exact language codes and destinations first. A repeated fr-BE entry pointing to two different URLs needs investigation. A fr entry and a fr-BE entry pointing to the same appropriate French page can be valid.

The fix depends on whether you have redundant output, conflicting destinations, or an incorrect association between pages. TranslatePress’s regional settings explain some repeated-looking entries; other cases require checking an integration or custom annotation source.

This guide shows what to keep, what to correct, and how LingoWP aims to keep each page’s language destinations consistent.

Published by LingoWP. External documentation was checked on 6 October 2026. The LingoWP explanation draws on its developer review for version 1.5.

Three situations that can look like duplicate hreflang

Hreflang identifies the language or regional counterparts of a page. The code and destination work together: counting “French” entries without examining both can lead to the wrong correction.

Entries on one page	What you have	Appropriate next step
fr-BE → /fr/contact/, repeated identically	Redundant output	Find why the same entry appears twice and clean up the repetition
fr-BE → /fr/contact/ and fr-BE → /fr/contactez-nous/	Competing destinations for the same code	Establish the intended current URL and correct the conflicting entry
fr → /fr/contact/ and fr-BE → /fr/contact/	Generic and regional targeting	Check that both are intentional; do not remove one solely because the URL repeats

These are illustrative examples, not newly reproduced TranslatePress defects.

Screaming Frog’s Multiple Entries check identifies multiple entries for the same language or regional code. It can also pick up multiple implementation methods, such as HTML tags and HTTP headers. Read the details behind the warning before deciding what is wrong. See the tool’s explanation.

Why TranslatePress can show both fr and fr-BE

fr targets French without a specific region. fr-BE identifies French for Belgium. They are different codes.

Google allows a generic language destination to use one of that language’s regional pages. Sharing a URL therefore does not automatically make the generic and regional entries invalid. Read Google’s localized-page guidance.

TranslatePress’s Remove duplicate hreflang setting offers country, region-independent, or both formats. Its documentation says both are displayed by default.

You can find the option under Settings → TranslatePress → Advanced → Miscellaneous. Its name is easy to misinterpret: it controls the format of the language entries; it does not establish that generic and regional targeting together is a bug. See the official advanced settings documentation.

Choose the format that matches your intended audience. Preserve meaningful targeting rather than optimizing for the smallest number of tags.

When the same code points to different URLs

A more important problem is one page declaring two competing destinations for the same exact code.

For example, one fr-BE entry may identify the working translated page while another uses an older or untranslated slug. Before removing anything, determine which destination represents the intended French counterpart.

In a TranslatePress support discussion involving The Events Calendar, a user reported two fr-BE entries on some event pages: one used the translated slug, while another used an untranslated slug that did not work. Support could not reproduce the duplicate when checking the example and requested further evidence.

That thread illustrates the symptom to investigate. It does not establish the cause on every installation or prove an ongoing defect in every release. Read the report and response.

How to diagnose and fix duplicate hreflang tags

1. Inspect one page’s actual entries

Open an affected page, choose View Page Source, and search for hreflang. Record every relevant code alongside its full destination URL.

Check the public page while logged out as well as the page your audit inspected. Compare equivalent URLs rather than mixing the original page with an editor preview.

Determine whether the warning concerns:

• The same code and URL repeated in the page’s HTML.
• The same code pointing to different destinations.
• Distinct regional and generic codes sharing a destination.
• Annotations detected through more than one method.

Repeated references across different language pages are expected. Each page describes its counterparts; that is different from conflicting entries within one page’s declarations.

2. Confirm the correct destination and page purpose

Open each competing URL and check its final address, response, language, and content. A URL that loads successfully can still be the wrong counterpart.

The French version of an article should represent that article. A tag archive should point to the corresponding tag archive, not a single post or an unrelated topic.

For illustration:

Original page	Suitable counterpart	Association to investigate
Contact page	Contact page in the target language	Homepage
Article about travel	Translation of that article	Travel tag archive
Travel tag archive	Corresponding travel tag archive	An unrelated category

For archives, compare the topic and page purpose. A translated label alone does not prove the URL identifies the correct archive.

If a destination redirects or returns 404, establish the correct working address before adjusting the language set. Do not preserve a broken destination merely because another page also references it. The guides for when hreflang points to a redirect and when hreflang points to a 404 page cover those checks.

3. Find what generates the extra entry

TranslatePress may not be the only component supplying language annotations. Check integrations that explicitly generate hreflang, custom snippets, theme header customizations, and remnants of a previous multilingual setup.

On a staging copy, compare the output before and after disabling one suspected annotation source. If its removal eliminates the extra entry, you have a useful lead. Check that the remaining entries are complete and correct before carrying that change to the live site.

If a component offers a setting to disable its hreflang output, use that setting. Otherwise, ask its support team or developer how to stop the redundant output without removing unrelated SEO features.

The aim is to avoid independent components publishing conflicting language destinations for the same page.

4. Review regional settings and custom code mappings

If the entries are simply fr and fr-BE, review the TranslatePress format setting against your intended targeting. You may decide both should remain.

If two entries use exactly the same code, inspect any custom language-code mapping. A customization that assigns the same code to different configured versions can create a conflict even when their URLs are individually valid.

TranslatePress documents a trp_hreflang filter for changing the output code. If your developer has used it, have them review the mapping alongside the current settings. You do not need to introduce custom code merely to choose between the standard regional formats. See the developer documentation.

5. Correct wrong slugs or archive associations

When one entry uses the wrong page address, correct the setting or integration that generates that destination.

TranslatePress’s paid SEO Pack supports translating page, term, taxonomy, and post-type slugs. Check the relevant slug category rather than treating every word in a path as the page’s name. Its documentation explains the supported slug types.

A translated archive base is not automatically wrong. It must match routing that your setup actually supports. Compare the intended archive with a working address, and investigate the plugin defining that route if the two disagree.

When contacting support, show both entries and the correct destination:

On this page, two fr-BE entries point to different addresses. This one is the working translation; the other leads to an old slug. Here are the page URL, both entries, and my active plugin versions.

That is more actionable than reporting only that “hreflang is duplicated.”

6. Check the language set after the correction

Clear relevant caches after changing the generating settings, then inspect the public output again.

Confirm that:

• Each exact language or regional code has a clear intended destination within the chosen implementation.
• Any generic and regional entries that remain are intentional.
• Destinations open at the correct current addresses.
• The pages represent equivalent content or corresponding archive topics.
• The language versions include the expected return links.

TranslatePress’s own hreflang validation guide explains checking destinations and return links. Rerun the audit on the affected page types, including archives or event pages where relevant.

If you use HTML and sitemap annotations together, also check that their language destinations agree. Multiple methods are permitted, but combining them does not remove the need to maintain consistent output. See what to do when hreflang and sitemap URLs don’t match.

How LingoWP keeps language associations consistent

For a site owner, the useful result is clear: each page should identify the correct counterpart in every published language without maintaining competing address lists.

LingoWP’s developer review describes one generated entry per published language, plus an x-default entry. Its reported tests check that language versions list the expected set and point back to one another.

The review also describes preserving fixed tag and category route bases in tested cases. The intended benefit is linking to the correct corresponding page or archive using supported routes.

You manage translations in LingoWP’s central workspace while the plugin generates its language associations from the current page information. This is a practical feature to assess when repeated annotation corrections have become part of your maintenance work. The LingoWP vs TranslatePress comparison covers the wider differences.

The advantage is predictable destinations and page pairing. Fewer tags are not inherently better: TranslatePress’s generic and regional entries can be valid, and x-default is an optional fallback annotation, as its validation documentation notes.

The LingoWP findings cover the reviewed version 1.5 and its reported tests. External plugins or custom code can still add competing annotations. Verify your actual archive, event, or other integrations on a copy of the site before switching.

Explore LingoWP to see its translation workspace and evaluate its approach for your site.

Frequently asked questions

Should I delete every repeated hreflang URL?

No. Different valid language or regional codes can intentionally use the same destination. Check the codes and the purpose of each entry before removing anything.

Will “Remove duplicate hreflang” fix two conflicting fr-BE URLs?

That setting selects country, generic, or both formats. It may change which entries appear, but a conflicting address from another integration or customization still needs its source corrected. Verify the actual output afterward.

Is a working URL enough to prove the association is correct?

No. Confirm that it contains the corresponding content in the expected language. A working tag archive is not automatically the counterpart of a working article.