Redirect URL in XML Sitemaps: How to Fix It

What "Redirect URL in XML Sitemaps" means

This issue flags URLs inside your XML sitemap that do not return a successful 200 status. Instead, when a crawler requests them, they respond with a 3xx redirect (most often a 301 permanent or 302 temporary redirect) that sends the request on to a different address. In other words, the crawler asks for URL A, gets told "go to URL B," and only URL B actually serves content.

A sitemap is supposed to be your clean, authoritative list of the URLs you want indexed. Every entry should be a live, canonical, indexable destination. A redirecting URL is none of those things; it is a pointer to the right page rather than the right page itself.

Why only final URLs belong in a sitemap

According to Google Search Central, the URLs you place in a sitemap are a signal of your preferred, canonical pages. The whole point of the file is to say "these are the addresses I want in search results." A redirecting URL contradicts that signal because the address you listed is not the address that actually serves the content.

There are three concrete reasons this matters:

It wastes crawl resources

Each redirect forces a crawler to make an extra request before it reaches real content. Across a large sitemap, those wasted hops add up and slow down how quickly your genuinely important pages get discovered and refreshed.

It signals a stale, untended sitemap

Redirects in a sitemap almost always mean the file was generated against an old URL structure and never updated. Search engines notice this. Bing in particular places less trust in sitemaps that contain "dirt" such as redirects, errors, or non-indexable URLs, which can reduce how much they rely on the file for crawling and indexing at all.

It sends mixed canonical signals

You are telling search engines that URL A is canonical (by listing it in the sitemap) while your own server is telling them URL B is canonical (by redirecting to it). That contradiction makes it harder for search engines to confidently pick the page you actually want ranked.

Common causes

The single most frequent cause is a site migration. When you move from HTTP to HTTPS, switch from non-www to www (or the reverse), change your URL structure, or move to a new domain, you set up 301 redirects from the old addresses to the new ones. That part is correct. The problem is that the sitemap often keeps listing the old, pre-migration URLs, so every entry now redirects.

Other common triggers include:

A trailing-slash policy change that adds a site-wide redirect while the sitemap still holds the old format. Changing a post slug or category path in a CMS without the sitemap plugin refreshing. Or a hardcoded or cached sitemap that was generated once and never regenerated.

How to diagnose

You want a list of exactly which sitemap URLs are redirecting and where each one lands. A crawler does this fastest. In Screaming Frog, switch to List mode, point it at your sitemap (Download XML Sitemap), run the crawl, and look at the Status Code column. Any row showing 301 or 302 is a redirecting entry; the "Redirects In Sitemap" filter under the Sitemaps tab isolates exactly these 3xx URLs that should be updated to their final destination. Sitebulb performs the same check and reports each redirected sitemap URL with its target.

You can also spot-check a single URL from the command line to confirm the status and see the destination in the Location header:

curl -sIL https://example.com/old-page/

# Look for the first response line and the Location header:
# HTTP/1.1 301 Moved Permanently
# Location: https://example.com/new-page/
# HTTP/1.1 200 OK   <- the final destination you should list

Export the full list of redirecting URLs and their destinations so you have a clear before-and-after mapping to work from.

How to fix it

The fix is to make sure the sitemap lists only final 200 destination URLs, then regenerate it. Do not delete the redirects on your server; those are still needed for any old links and bookmarks pointing at the original addresses. You are only correcting what the sitemap advertises.

If your sitemap is generated by a plugin or your CMS (for example a WordPress SEO plugin), the cleanest path is almost always to regenerate it rather than hand-edit. Clear any sitemap or page cache, confirm the canonical settings match your live URL scheme (correct protocol, www choice, and trailing-slash rule), then rebuild the sitemap so it pulls fresh canonical URLs. After that, recrawl it to confirm zero 3xx entries remain.

If your sitemap is a static or custom-generated file, replace each redirecting entry with the destination URL you captured during diagnosis. A correct entry looks like this:

<url>
  <loc>https://example.com/new-page/</loc>
  <lastmod>2026-06-11</lastmod>
</url>

<!-- not the old, redirecting address: -->
<!-- <loc>https://example.com/old-page/</loc> -->

Once the corrected file is live, resubmit it in Google Search Console and Bing Webmaster Tools and request a refresh so the new version is picked up promptly.

Best practice

Treat the sitemap as a living document that should always contain only canonical, indexable, 200-status URLs. Build sitemap validation into your migration checklist so that the moment you add redirects, you also refresh the sitemap to point at the new targets. Schedule a recurring crawl of the sitemap to catch any 3xx or 4xx entries that creep in after slug edits or structural changes. A small, clean sitemap that search engines can trust will always serve you better than a large one full of detours.

FAQ