# Hreflang and Sitemap URLs Don't Match: A TranslatePress Guide

> Different hreflang and sitemap URLs in TranslatePress? Find the cause, check language settings and learn what LingoWP's approach currently covers.

- URL: https://www.lingowp.com/blog/translatepress-hreflang-sitemap-mismatch/
- Author: Amine Sayagh
- Category: Troubleshooting
- Published: 2026-10-06
- Language: en

Your translated pages work, but an SEO audit shows different language URLs in your page's hreflang tags and your XML sitemap. One lists the current address. The other seems to use an old slug, the wrong language folder, or the original homepage.

Which should you correct?

**First, confirm the working address for each language. Then compare entries that describe the same language version and identify which plugin generates the incorrect information. A sitemap that lists only original-language pages is a different situation from two sources declaring conflicting language destinations.**

This guide walks through those checks in TranslatePress and explains how LingoWP keeps its page-level language links consistent, including the limits of its sitemap support.

*Published by LingoWP. External guidance was checked on 6 October 2026. LingoWP behavior described here is based on the developer review for version 1.5.*

## What should you compare?

Hreflang identifies the language or regional versions of a page. A sitemap lists page URLs and may also contain language alternate entries.

The important distinction is between **the page listed in a sitemap** and **the language alternatives attached to that page**.

For example, a sitemap can list the English page while the page's HTML identifies its French counterpart. Those addresses serve different purposes, so their difference alone is not an error.

To establish a genuine mismatch, compare the destination assigned to the same language version of the same content.

| What you find | What it means |
|---|---|
| The sitemap lists an English page; its HTML links to the French version | Different addresses can be expected. |
| The HTML and sitemap both identify the French version, but use different addresses | Check whether both resolve to the intended current French page. |
| The sitemap labels the original English homepage as the French homepage | The destination does not represent the intended translation. |
| HTML uses `en`; sitemap uses `en-GB` | Review the intended regional targeting and integration settings before treating this as a URL error. |

**Do not change a working page address just to make it match an incorrect sitemap entry.** Establish the correct destination first.

## Does hreflang have to appear in the sitemap?

Google accepts three methods for declaring language alternatives: HTML tags, HTTP headers, and sitemap annotations. They are equivalent; using all three is not required and brings no additional search benefit.

That means a source-language-only sitemap does not, by itself, make HTML hreflang invalid. Translated URLs in a sitemap can help discovery, but a missing entry and a conflicting declaration are different problems.

Generic and regional tags can also coexist legitimately. For example, `en` and `en-GB` can point to the same appropriate page. The question is whether they express your intended targeting and identify the correct content. Our guide to [duplicate hreflang tags in TranslatePress](/blog/translatepress-duplicate-hreflang/) explains when generic and regional entries are valid. [See Google's localized-page guidance](https://developers.google.com/search/docs/specialty/international/localized-versions).

## Why TranslatePress and a sitemap plugin can disagree

Your page's language tags and its sitemap may involve different plugins or integrations. A mismatch can arise when those components use different URL information or interpret language settings differently.

Possible causes include:

- A page or translated slug changed, but one output still uses the previous address.
- A sitemap integration does not honor a custom language configuration.
- The homepage is handled differently from ordinary pages.
- A content plugin controls an event, product, or category URL base.
- Cached HTML or XML still reflects earlier settings.

The error message alone does not identify which component is responsible.

### A documented example: SureRank and TranslatePress

In a WordPress support discussion, a site owner reported that TranslatePress's HTML used their configured `en` code, while SureRank's sitemap used `en-GB`. The sitemap also pointed the English homepage alternate to the original homepage rather than `/en/`.

SureRank support reproduced the reported behavior and acknowledged the homepage handling problem on its side. It also explained that the sitemap derived the regional code from the underlying locale rather than matching TranslatePress's hreflang configuration.

This is a useful diagnosis example, not evidence that every current installation has the same defect. [Read the report and support response](https://wordpress.org/support/topic/xml-sitemap-hreflang-wrong-en-gb-instead-of-custom-en/).

## How to diagnose and fix the mismatch

### 1. Record one affected page and its language destinations

Choose a specific page from the audit. Start with the homepage if the warning concerns it; do not assume a correct blog post proves the homepage is also correct.

Open each language version and record its current working address. Check that it contains the equivalent content in the expected language.

For illustration:

| Language version | Confirmed working URL |
|---|---|
| English contact page | `https://example.com/contact/` |
| French contact page | `https://example.com/fr/contactez-nous/` |

Use these addresses as the starting point for comparison. Your site may legitimately use untranslated slugs; translated wording in the address is not the test of whether the page works.

### 2. Compare the HTML and XML entries

Open the affected page, choose **View Page Source**, and search for `hreflang`. Record the URL associated with each relevant language code.

Then open the sitemap URL from your SEO plugin or your Search Console Sitemaps report. If it is a sitemap index, follow the relevant page or post sitemap and find the affected entry.

Look for two things:

- The main page URL, often shown inside a `<loc>` entry.
- Any alternate entries that associate a language code with another URL.

You do not need to edit XML. You are checking whether both sources describe the same destination correctly.

| Source | French destination | Finding |
|---|---|---|
| Working page | `/fr/contactez-nous/` | Intended current address |
| HTML hreflang | `/fr/contactez-nous/` | Matches |
| Sitemap's French alternate | `/fr/contact/` | Needs investigation |

This is an illustrative comparison, not a reproduced TranslatePress defect. The last address might redirect, fail, or serve another page; check it before deciding how to correct it.

### 3. Check the URLs themselves

Use your audit tool's response information to see whether the listed addresses open directly or redirect elsewhere. Confirm the content as well: a URL can load successfully and still show the wrong language or page.

If one entry uses an older address, correct the component generating that entry. Keep a useful redirect from the old address to its replacement so older links still work. The guide for when [hreflang points to a redirect](/blog/translatepress-hreflang-redirect/) walks through that correction.

Also review canonical settings. A canonical identifies the preferred page address; it should not contradict the destination you intend to publish. Google recommends including preferred canonical URLs in sitemaps. [Read its sitemap guidance](https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap).

### 4. Check TranslatePress's sitemap and language settings

TranslatePress documents multilingual sitemap support through its paid **SEO Pack**, working with supported SEO plugins. If you expect translated URLs and alternate entries, confirm that the add-on is active and that your sitemap plugin's integration supports your setup. [See the SEO Pack documentation](https://translatepress.com/docs/addons/seo-pack/).

Next, check **Settings → TranslatePress → Advanced**:

- **Exclude translated links from sitemap** controls whether translated links are excluded from SEO-plugin sitemaps when SEO Pack is active. If those links are intentionally excluded, their absence is expected.
- **Remove duplicate hreflang** offers country, region-independent, or both formats. Check which format you have chosen before comparing language codes in the HTML and XML.

The setting's name does not mean generic and regional tags are inherently invalid together. Choose the format that matches your audience and confirm that the sitemap integration handles it as intended. [TranslatePress explains these options here](https://translatepress.com/docs/settings/advanced-settings/).

Avoid changing language folder names on a live site merely to silence a warning. First determine whether the problem concerns the URL, the language code, or both.

### 5. Fix the component producing the incorrect entry

If the HTML is correct and the sitemap is wrong, investigate the sitemap plugin and its TranslatePress integration. If the sitemap is correct and HTML points to an old address, investigate the page's language URL configuration.

For event, product, or archive URLs, include the plugin that defines those addresses in the investigation. Check relevant release notes and test updates on a staging copy where possible.

When contacting support, provide the affected page, the correct language URL, the incorrect entry, and the active plugin versions. For example:

> The French contact page works at /fr/contactez-nous/. Its HTML hreflang uses that address, but the sitemap's French alternate uses /fr/contact/. Here are the sitemap URL and my TranslatePress, add-on, and SEO plugin versions.

Correct the generating settings or integration rather than manually changing a generated sitemap file, which may be replaced on the next update.

### 6. Refresh and verify the public output

After making the correction, refresh the sitemap through the generating plugin if needed and clear relevant HTML or sitemap caches. Check the public page while logged out.

Verify the homepage separately, along with an ordinary page and any affected custom content type.

Your final checks are:

- Each published language destination leads to the expected current page.
- The URL works directly and the page can be crawled and indexed as intended.
- HTML and sitemap alternate declarations describe compatible language relationships.
- Canonical settings agree with the intended page addresses.
- Language counterparts provide the expected return links.

Use Search Console to check sitemap processing and relevant indexing information. A **Success** sitemap status means Google fetched and processed the file; it does not prove that every language association is correct. [See Google's Sitemaps report documentation](https://support.google.com/webmasters/answer/7451001?hl=en).

## What LingoWP helps keep consistent

For a site owner, changing a page should not mean separately maintaining its address in the language switcher, internal links, and language annotations.

LingoWP's developer review describes a shared way of generating language addresses for hreflang, the switcher, internal links, canonical tags, and redirects. It uses the current page information when building those destinations.

The practical benefit is keeping LingoWP's page-level links aligned as you manage content and translations in one workspace. That reduces the need to maintain several independent address mappings for the same page.

### The sitemap limitation to know before choosing

**In the reviewed LingoWP 1.5 behavior, the plugin does not add translated URLs to the XML sitemap. The sitemap remains limited to source-language pages.**

LingoWP's page-level URL handling therefore does not establish that an external sitemap plugin will produce matching translated entries. If translated sitemap listings are a requirement for your site, verify a supported solution before migrating. The [LingoWP vs TranslatePress](/blog/lingowp-vs-translatepress/) comparison covers the wider differences.

You can still use correctly implemented HTML hreflang to identify language versions. The choice is whether LingoWP's translation workflow and page-level consistency meet your needs alongside that sitemap limitation.

**[Explore LingoWP](https://lingowp.com/)** to see its translation workspace and assess how it fits your multilingual site.

## Frequently asked questions

### Which should I trust: hreflang or the sitemap?

Check the actual working page first. Confirm its language, content, final address, and canonical settings, then correct the output that describes it inaccurately. Either source can contain outdated or incorrect information.

### Will installing TranslatePress SEO Pack fix every mismatch?

SEO Pack provides documented multilingual sitemap functionality, but a particular mismatch may involve the sitemap plugin, custom language settings, routing, or caching. Identify the affected integration and verify the result after changing it.

### Should I delete the sitemap to remove the conflict?

Start by correcting the incorrect entries. If you choose HTML as your hreflang method, you can still retain an ordinary sitemap for page discovery. Removing language annotations and deleting the entire sitemap are different actions.