Sitemap Checker: Test If Google Can Read Your XML Sitemap

"Couldn't fetch" and "Sitemap could not be read"

The Sitemaps report in Search Console gives each submitted sitemap one of three statuses: Success, Has errors or Couldn't fetch. Open a sitemap with Couldn't fetch and the detail usually says "Sitemap could not be read". It means Google did not manage to download or parse the file on its last attempt. It does not say why.

There are two very different causes behind that message. One is timing: a freshly submitted sitemap often sits on Couldn't fetch for a day or two and then flips to Success without any change. The other is a real defect that will keep failing: the URL returns an error or an HTML page, a firewall blocks Googlebot, or the XML is broken. This checker separates the two. If every file here loads with 200 and valid XML, the problem is timing, and resubmitting every hour will not speed it up. If something fails here, Google sees the same failure. I walk through each cause and its fix in how to fix the sitemap temporary processing error.

What the checker reads

Enter a sitemap URL and it reads that file. Enter only a domain and it looks for Sitemap: lines in robots.txt first, then tries /sitemap.xml, /sitemap_index.xml (Yoast and Rank Math) and /wp-sitemap.xml (WordPress core). It understands regular URL sets, sitemap indexes, gzipped files, plain text sitemaps and RSS or Atom feeds, which Google also accepts.

From a sitemap index it follows up to 10 child sitemaps per run. Then it takes up to 30 URLs spread across those files and requests each one: a HEAD request first, a normal GET when the server does not support HEAD, and a short GET to read the meta robots tag. That sample answers the question the XML cannot: are the URLs you submit actually live, final and indexable?

The limits and format rules Google applies

A sitemap index can list up to 50,000 sitemaps, but it cannot list another index. Google ignores <priority> and <changefreq>, so the checker does not grade them.

lastmod: useful only when it is honest

Google has said it uses <lastmod> when the dates are consistently and verifiably accurate. A plugin that stamps every URL with today's date, or dates in the future, teaches Google to ignore the field for your whole site. The checker shows the share of URLs with a lastmod, the oldest and newest dates, and flags future dates and malformed values. If your newest lastmod is months old on a site you update weekly, the generator is not updating it.

Only list URLs you want indexed

A sitemap is a list of canonical, indexable URLs that return 200. Every redirect, 404 or noindexed URL in it is a small contradiction: you ask Google to index something you have also told it not to index, or that no longer exists. Google copes, but the Page indexing report fills with "Page with redirect" and "Excluded by 'noindex' tag" rows for submitted URLs, and the real problems are harder to spot. The sample table shows these per URL; download it as CSV and clean the generator settings, not the file by hand.

Fixes for the errors I see most

The sitemap URL returns HTML. A 404 template that returns 200, a maintenance plugin, or a page cache serving the home page. Exclude the sitemap URLs from the cache and check the URL in a private window.

Leading whitespace. Almost always a WordPress theme or plugin file with a blank line before <?php or after a closing ?>. Switch plugins off one by one and recheck here until the error disappears.

It loads for you but Google cannot fetch it. A firewall or bot protection is challenging crawlers. If this checker is blocked too, that is the likely cause; allow Googlebot in the firewall rules rather than turning protection off.

The wrong address was submitted. http instead of https, www instead of non-www, or an old path. The checker shows the redirect; submit the final URL and remove the old entry.