XML Sitemap Errors: What Each One Means and How to Fix It

XML sitemap errors are problems that stop Google from downloading, parsing or using the URLs in your sitemap file. Search Console reports them in the Sitemaps report. Nearly all of them come down to one of three causes: the file can't be fetched, the XML is invalid, or the URLs inside it break the rules. Each cause has a specific fix.

This guide covers the error messages one by one. If you need the basics first (what a sitemap should contain and how to submit one), start with our XML sitemap guide.

Where do XML sitemap errors show up?

They show up in Search Console under Indexing → Sitemaps. Every submitted sitemap gets one of three statuses there: Success, Has errors or Couldn't fetch. Click a sitemap to see the individual errors, and the report usually names the line or URL that triggered each one.

Google's Sitemaps report documentation defines the statuses this way:

• Success: the sitemap "was fetched and read without any errors." Its URLs are queued for crawling.
• Has errors: the file was downloaded, but it contains one or more parsing errors. Google can still use the entries that parsed correctly.
• Couldn't fetch: Google couldn't download the file at all.

Two limitations are worth knowing before you start debugging. The report only lists sitemaps submitted through Search Console or the API, not ones Google found through robots.txt. And a Success status doesn't promise indexing: Google states that "there is no guarantee that a page URL discovered in a sitemap has been or will be crawled or indexed."

XML sitemap errors at a glance

The table lists the errors that general websites see most often, with the fix for each, based on Google's error reference.

Why does my sitemap say "Couldn't fetch"?

"Couldn't fetch" means Googlebot never got a usable file. The causes are usually a wrong URL, a 404 or 5xx response, a robots.txt block, or a firewall or bot protection that challenges Googlebot. Open the sitemap URL in a private browser window and check the HTTP status before you change anything else.

Google's documentation lists these causes for the status:

1. The file is blocked by robots.txt. Remove the Disallow rule that matches the sitemap path. Our robots.txt guide explains how to test rules.
2. Wrong URL (404). This is common after a CMS or SEO plugin switch, when /sitemap.xml becomes /sitemap_index.xml or the other way round. Submit the URL that actually exists.
3. Server problems. Timeouts and 5xx errors are often temporary, and Google retries on its own.
4. A manual action on the site, which you resolve in the Manual Actions report.

Newly submitted sitemaps sometimes show "Couldn't fetch" for a short time before the first real attempt. If the file returns 200 with valid XML in your browser, wait a few days before you assume something is broken. If the status stays, look at your CDN or WAF logs for blocked Googlebot requests. Security rules that send a JavaScript challenge to unknown clients are a frequent hidden cause.

How do you fix a sitemap parsing error?

A parsing error means Google downloaded the file but couldn't read it as XML. The usual cause is an unescaped special character in a URL, most often a raw & in a query string. Other causes are stray whitespace before the XML declaration, curly quotes, a wrong namespace, or an HTML page served where the XML should be.

Google's documentation asks you to escape five characters as entities. A valid entry looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://www.example.com/shop?color=blue&amp;size=m</loc>
    <lastmod>2026-10-20</lastmod>
  </url>
</urlset>

Check for these related problems at the same time:

• Leading whitespace. A blank line or a byte-order mark before <?xml triggers its own error. It often comes from a PHP file with a newline after its closing ?>.
• Curly quotes. These creep in when someone edits the file in a word processor. Google recommends straight quotes only.
• HTML instead of XML. Some caching plugins, maintenance modes and "page not found" templates return an HTML page with a 200 status. Google reports this as Unsupported format. Open the file and confirm it starts with <?xml or <urlset.
• Encoding. Google's sitemap build guide says the file "must be UTF-8 encoded."

Paste the file into any XML validator before you resubmit. It catches all of these problems in seconds.

What does "URL not allowed" mean in a sitemap?

"URL not allowed" means the sitemap lists URLs that sit outside its scope. They are either on a different host or in a folder above the sitemap's location. If a sitemap lives at /blog/sitemap.xml, it can't list /products/ pages. The fix is to host the sitemap at the site root or list only URLs inside its folder.

Google's build guide puts it this way: unless you submit through Search Console, "a sitemap affects only descendants of the parent directory." For that reason, Google recommends the site root as the best location. The same scope rule applies to index files: Google's large sitemaps page says the referenced sitemaps "must be in the same directory as the sitemap index file, or lower in the site hierarchy," and on the same site unless you set up cross-site submission.

Closely related are the path mismatch errors. If the sitemap is at https://example.com/sitemap.xml but lists https://www.example.com/... URLs, Google flags the mismatch. Pick your canonical host and make the sitemap URL, every <loc> and your redirects all agree on it. The same applies to http vs https. Our canonical tag guide covers how to choose a preferred URL version.

Which sitemap size and date limits cause errors?

Size errors appear when a single sitemap has more than 50,000 URLs or more than 50 MB uncompressed. Date errors appear when <lastmod> isn't in W3C Datetime format. Both are easy to fix: split large files with a sitemap index, and output dates as 2026-10-20 or 2026-10-20T14:30:00+00:00.

The limits from Google's documentation:

• Per sitemap: 50,000 URLs or 50 MB uncompressed. Exceed either and you get Too many URLs or a file size error.
• Per sitemap index: up to 50,000 <loc> entries, and you can submit up to 500 index files per site in Search Console (large sitemaps).
• No nesting: "A sitemap index file can't list other sitemap index files, only sitemap files" (Sitemaps report help).

For Invalid date, the usual cause is a template that outputs a local format such as 20/10/2026 or October 20, 2026, or a timestamp with no timezone. Fixing the format clears the error, but the date also needs to be accurate. Google uses <lastmod> only when it is "consistently and verifiably accurate" and reflects significant updates. A changed copyright year doesn't count. A sitemap that stamps today's date on every URL is valid XML, but it gives Google nothing it can use. Google ignores <priority> and <changefreq> completely, so errors in those tags aren't worth much of your time.

What sitemap problems does Search Console not flag as errors?

The most damaging sitemap problems often come with a green Success status. Search Console accepts a sitemap full of redirected, 404, noindexed or non-canonical URLs, because the XML itself is valid. These entries waste crawl attention and send mixed signals about which pages matter. You find them by crawling the URLs in the sitemap, not by reading the report.

Look for these four content problems:

• Redirected URLs. Old URLs left in the sitemap after a migration. Replace them with the final destination. Google also lists URLs not followed for redirect chains.
• 404 and 410 pages. Deleted products or posts that the generator didn't remove.
• Noindexed pages. A sitemap says "index this" while the page says "don't." Fix whichever signal is wrong.
• Non-canonical URLs. Parameter, filter or trailing-slash variants whose canonical tag points somewhere else.

To check, open Search Console's Page indexing report, filter it to your sitemap, and look at the reasons pages aren't indexed. Our guide to fixing website indexing problems explains each reason. For a URL-by-URL view, crawl the sitemap with a crawler and compare each listed URL's status code, robots directives and canonical. A free SEORecheck audit does this for you: it lists sitemap URLs that redirect, return errors, are noindexed or point their canonical elsewhere, with example URLs from your own site.

How do you confirm a sitemap error is fixed?

Fix the file, load it in a browser to confirm it returns 200 and valid XML, then resubmit it in the Sitemaps report. The status and the Last read date update after Google fetches the file again. Content problems take longer to clear, because Google has to recrawl the affected pages.

Google's guidance on resubmitting is to resubmit after fixing errors or making big changes, and otherwise to let Google follow its normal schedule. A sitemap that has been read successfully is recrawled periodically on its own.

A short verification routine:

1. Validate the XML and check the HTTP status and Content-Type.
2. Resubmit in Search Console and note the date.
3. Check the status and the Last read date over the following days.
4. Watch the Page indexing report, filtered by sitemap, over the next few weeks.
5. Add a check to your release process. Many sitemap errors return after plugin updates or deploys, which is what SEO regression testing is for.

Deleting a sitemap from the report doesn't make Google forget its URLs. To stop crawling, Google points to robots.txt rules, removing the pages, or noindex.

Key takeaways

• XML sitemap errors fall into three groups: the file can't be fetched, the XML can't be parsed, or the URLs break the rules.
• "Couldn't fetch" is usually a wrong URL, a robots.txt block, a server error or a firewall. Test the URL yourself first.
• Parsing errors usually come from an unescaped &, leading whitespace or HTML served in place of XML.
• Keep each sitemap under 50,000 URLs and 50 MB uncompressed, and never nest index files.
• Use W3C Datetime for <lastmod>, and only update it when the page really changes.
• A Success status can still hide redirects, 404s, noindexed and non-canonical URLs. Crawl your sitemap to find them.