Sitemap Could Not Be Read in Google Search Console: What It Means and How to Fix It

"Sitemap could not be read" means Google tried to download your sitemap file and failed. It is not a judgment about your pages, and it is not an indexing verdict. It is a delivery problem: the file never reached Google in a form it could use. In the Sitemaps report it usually sits next to the status Couldn't fetch, which Google's own help page defines as "the sitemap could not be fetched for some reason."

That distinction matters, because the fix lives in a different place than most indexing problems. You are not rewriting content or adding internal links here. You are working out why one specific URL — your sitemap's — doesn't return a clean XML file to Googlebot.

What "Sitemap Could Not Be Read" Actually Tells You

The Sitemaps report in Search Console shows one of three statuses for each submitted sitemap:

| Status | What happened | Are the URLs inside used? | | --- | --- | --- | | Success | Google loaded and processed the file with no errors | Yes, queued for crawling | | Has errors | Google fetched the file, but some entries couldn't be parsed | Yes, the parseable ones | | Couldn't fetch | Google couldn't retrieve the file at all | No |

"Sitemap could not be read" is the detail message behind Couldn't fetch. "Sitemap can be read, but has errors" is the detail message behind Has errors. The first one is the more serious of the two, because nothing in the file gets used until the fetch works.

Two things in Google's documentation are worth knowing before you start changing anything:

• Google doesn't try just once. After a failed fetch, Google says it "will try a few more times, but will eventually stop trying to read that sitemap." A brand-new submission showing Couldn't fetch for a few hours is not, on its own, proof of a broken file.
• Fixing the file is not enough on its own. Once Google has given up, you need to fix the cause and submit the sitemap again so Google makes a fresh request.

Why Google Couldn't Fetch Your Sitemap

Google's help page lists a short set of reasons a sitemap fetch fails. In practice, on a blog, they come up in roughly this order.

The sitemap URL doesn't exist where you said it does

This is the least dramatic cause: a 404. Typical causes are a typo in the submitted URL, an SEO plugin that names the file sitemap_index.xml while you submitted sitemap.xml, or a site migration that moved the file. Open the exact URL you submitted in a private browser window. If you see a "page not found" template, that's your answer.

Watch the property, too. The Sitemaps report "shows only sitemaps that are in the current property," and Google warns specifically about mixing up http/https and www/non-www versions. A sitemap submitted at http://example.com/sitemap.xml under an https://www.example.com property is pointing at the wrong place.

robots.txt is blocking it

If your robots.txt disallows the path the sitemap lives on, Google will not fetch it — Google's fix here is simply "You must remove the rule that prevents Google from fetching your sitemap." This can happen by accident when a blanket rule like Disallow: /wp- or Disallow: /*.xml$ was added for some other reason. If you're not sure how to read the rules, our guide on testing your robots.txt file walks through checking a single URL against them.

The server refused or errored

A firewall, security plugin, or CDN bot-protection rule can return a 403 or a challenge page to Googlebot while letting normal browsers through. Server errors (5xx) and timeouts land here too. Google notes these "general" fetch errors may be temporary, but if the status doesn't clear after a few days, assume something is actively blocking Googlebot. The same pattern shows up for regular pages as Blocked due to access forbidden (403), and the diagnosis is the same: look at what your server sends to Googlebot, not to you.

The response isn't a sitemap at all

Google supports XML sitemaps, RSS/mRSS/Atom 1.0 feeds, and plain text files with one URL per line. If the sitemap URL returns an HTML page — a cached copy, a login screen, a cookie banner page, a "not found" template served with a 200 status — Google has nothing it can parse. This is what's behind the "sitemap is HTML" message many bloggers search for. Caching and optimization plugins are worth checking first, because they can serve or rewrite the sitemap as if it were a normal page.

A manual action is unresolved

Google states that it does not read sitemaps while the site has an unresolved manual action. This is rare for a typical blog, but it takes 30 seconds to rule out: check the Manual actions report in Search Console.

Low crawl demand

The least satisfying cause is also on Google's list. Sites with lower crawl demand may simply be fetched less often, and Google ties that directly to quality: "The higher the quality of the site's content, the higher the crawl demand." On a new or small blog, this can show up as a sitemap that sits on Couldn't fetch longer than you'd expect even though nothing is technically wrong.

How to Fix It, Step by Step

Work through these in order. Each step rules out one cause before you move on.

1. Open the submitted sitemap URL yourself. Copy it exactly from the Sitemaps report and open it in a private window. You should see raw XML (or a styled XML view) that lists URLs — not your blog's theme, not an error page, not a login prompt.
2. Check the status code. A browser hides this. Use any HTTP header checker, or run curl -I against the URL, and confirm it returns 200 with an XML content type rather than a 404, 403, 5xx, or a redirect chain. If it redirects, submit the final URL instead; long hops cause their own problems, as covered in our redirect chain checker guide.
3. Run a URL Inspection live test on the sitemap URL. This is the step Google itself recommends. Paste the sitemap URL into the URL Inspection tool, click Live test, then expand Page availability. You want "Crawl allowed?" to read Yes and "Page fetch" to read Successful. If either fails, the panel tells you why — blocked by robots.txt, a 403, a server error — which is far more specific than the Sitemaps report.
4. Check robots.txt. If the live test says crawling isn't allowed, find and remove the rule that matches the sitemap path. Adding a Sitemap: line to robots.txt is also one of Google's three documented ways to tell it where the file is (alongside the Sitemaps report and the Search Console API).
5. Fix the format if the file isn't valid XML. The file must be UTF-8 encoded and use fully qualified absolute URLs (https://example.com/post, not /post). Keep each file under 50 MB uncompressed and 50,000 URLs; above that, split it and use a sitemap index. If your plugin produces the file, regenerating it — or excluding the sitemap path from your caching plugin — usually solves this.
6. Resubmit. In the Sitemaps report, submit the URL again. Google says it "will try to crawl a sitemap as soon as you submit it," so once the file is fixed, you don't have to wait for a scheduled recrawl.

If you're on a CDN or managed host, step 3 is where the answer usually appears. A sitemap that loads fine in your browser but fails the live test usually points to a bot-protection or firewall rule treating Googlebot differently from you.

Couldn't Fetch on a Brand-New Sitemap: Should You Wait?

A fair question, because two different situations look identical in the report.

If you submitted the sitemap minutes or hours ago, and the URL loads correctly in your browser and passes the live test, give it a little time. Google retries a failed fetch for a few days, so a temporary hiccup at the moment of submission can clear on its own. Resubmitting the same working file over and over adds nothing — Google's guidance is to resubmit after you've fixed something or made big changes to the sitemap.

If the live test fails, don't wait. Google will eventually stop retrying, and nothing will change until you fix the cause and resubmit.

A quick way to tell which situation you're in:

• Live test passes, status still Couldn't fetch → most likely timing. Check again in a day or two.
• Live test fails → a real fetch problem. Fix it using the steps above.
• Live test passes, status stays Couldn't fetch for more than a week → look at the property (http/https, www) and whether you submitted the same URL the live test used.

What a Working Sitemap Does (and Doesn't) Do

Getting the sitemap to Success is worth doing, but keep expectations honest. Google is explicit that a sitemap only tells it what exists: "There is no guarantee that a page URL discovered in a sitemap has been or will be crawled or indexed by Google." A clean sitemap gets your URLs in front of Google. Whether they're indexed is a separate decision, made page by page. (Once Google can read the file, what goes inside it matters too — which URLs to list and which fields Google actually uses are covered in our sitemap best practices guide.)

That's why a common next step after fixing this error is a new question: the sitemap reads fine, so why are only some of its URLs indexed? We cover that gap in Google not indexing all your sitemap URLs, and the two statuses you'll most often see for those missing pages in Discovered vs. Crawled — Currently Not Indexed. If you just published a post and it hasn't appeared yet, why your new blog post isn't showing up in Search Console is the more relevant read.

Noticing When Something Like This Breaks

The frustrating part of a sitemap fetch error is how easy it is to miss. It's easy to open the Sitemaps report once, see Success, and never look again — so a plugin update or a new firewall rule can quietly stop Google from reading the file for weeks before anyone checks.

The sitemap status itself lives in Search Console. What you can watch more easily is the effect downstream: Traffic Monitor doesn't read the Sitemaps report, but it pulls your Search Console clicks and impressions per post every day, so newly published posts that never start picking up impressions stand out instead of hiding in a report you open once a month. If that's useful, you can connect your blog with read-only Search Console access.

Whichever way you monitor it, the fix for "Sitemap could not be read" is usually mechanical: confirm the URL, confirm Googlebot is allowed to fetch it, confirm it returns real XML, and resubmit.