When Google Search Console says your sitemap "Couldn't fetch", Google either could not download the file or has not processed it yet. Right after a first submission it often just means "pending", so wait a day or two; if the status stays, the sitemap URL is answering Googlebot with an error, a redirect, an HTML page or a block (robots.txt, a firewall, a password). This guide shows how to tell which in a few minutes, how to fix each cause, and how to fix the errors Google reports once it can read the file. For what a sitemap should contain in the first place, see the XML sitemap guide.
Quick answer
- Just submitted? "Couldn't fetch" is often a pending status. Check again after 24-48 hours before debugging.
- Still failing? Open the sitemap URL in a private window and with
curl. It must answer 200 with XML directly: no redirect, login page, 404 or challenge page. - Run the sitemap URL through URL Inspection → Test live URL. It tells you whether Googlebot itself can fetch it, and whether robots.txt blocks it.
- Check the usual blockers: a
Disallowthat matches the sitemap path, a firewall or bot-protection rule, a password on the site, a sitemap on a different host or protocol than the property. - "Sitemap could not be read" or Has errors means Google downloaded the file but could not parse all of it: fix the XML, dates and URLs.
- Run the sitemap checker to test fetch, format and a sample of listed URLs in one pass.
What the sitemap statuses mean
The Sitemaps report (Search Console → Indexing → Sitemaps) shows one of three statuses per file:
| Status | What happened | What Google does with the URLs |
|---|---|---|
| Success | Downloaded and parsed without errors | Uses them for discovery |
| Has errors | Downloaded, but some entries or the whole file could not be parsed | Uses the entries it could parse |
| Couldn't fetch | Not downloaded, or not processed yet | Nothing, until a fetch succeeds |
Clicking a row shows details. "Sitemap could not be read" usually appears alongside "Couldn't fetch" as the explanation, and does not by itself mean the XML is broken: it means Google has nothing to read yet. Specific parse errors such as "Invalid date", "Invalid URL" or "Parsing error" appear under "Has errors".
How to fix "Couldn't fetch"
Work through these in order; each step rules out a cause.
1. Rule out "pending"
A sitemap submitted in the last day or two regularly shows "Couldn't fetch" with an empty "Last read" column while it waits in Google's queue. Search Console has shown this for years; it is not an error yet. If "Last read" is still empty after about a week, keep going.
2. Fetch the file yourself
curl -sI https://example.com/sitemap.xml
# HTTP/2 200
# content-type: application/xml; charset=utf-8What you want: 200, an XML content type (application/xml or text/xml), and the body starting with <?xml or <urlset. What breaks it:
301or302. Google follows redirects, but submit and declare the final URL so there is no doubt./sitemap.xmlredirecting to/sitemap_index.xmlis common on WordPress; submit the second.404. The file is elsewhere, or the rewrite rule that serves a generated sitemap is missing. On WordPress, saving Settings → Permalinks once regenerates the rules. Plain permalinks break generated sitemaps.5xxor a timeout. A dynamic sitemap that queries 50,000 products on every request can take longer than Googlebot waits. Cache it or generate it to a static file.200with HTML. A 404 page or a login page served with the wrong status. The validator reports this as "The URL returns an HTML page, not XML".
3. Test as Googlebot
Paste the sitemap URL into URL Inspection and choose Test live URL. If the page fetch fails, the result says why: "Blocked by robots.txt", a server error, or a redirect. Your browser can succeed while Googlebot fails, because firewalls treat them differently.
4. Check robots.txt
A rule like Disallow: /*.xml$ or Disallow: /wp- can match the sitemap path. Test the sitemap URL in the robots.txt tester, and allow it explicitly if needed:
User-agent: *
Allow: /sitemap_index.xml
Disallow: /*.xml$
Sitemap: https://example.com/sitemap_index.xml5. Check bot protection and passwords
Security plugins, WAF rules, "bot fight" modes and rate limits can answer Googlebot with 403, 429 or a JavaScript challenge. Look for the sitemap requests in your server or CDN logs and at what they returned. A site behind a password, including a Shopify store before launch, answers every request with the password page; see Shopify sitemap.
6. Check the property
A sitemap is only accepted for the property it belongs to. Submitting http://example.com/sitemap.xml in an https://www.example.com/ URL-prefix property, or a staging hostname, fails. A Domain property covers every protocol and subdomain.
7. Resubmit
When the file fetches correctly, submit it again in the Sitemaps report. Some site owners report that a stuck status clears only after submitting the file under a new URL (for example sitemap-2.xml); try it if the status stays wrong for weeks while the live test succeeds.
How getReport checks it
The report finds sitemaps the way crawlers do: the Sitemap: lines in robots.txt (up to three) and the default /sitemap.xml. Each is fetched (the first 5 MB are read), gunzipped if it is a .xml.gz file, and parsed with a strict XML parser, so a stray & or an unclosed tag is reported instead of being silently skipped.
Then up to 25 listed URLs, spread evenly across the file, are requested to see whether they answer 200 without redirecting, and the page you tested is looked up in the file:
The checker fetches from getReport's servers, not from Google's, so a firewall that blocks only Googlebot passes here and fails in Search Console. Step 3 above catches that case.
Sitemap errors once Google can read the file
"The XML is not well-formed" (Parsing error)
The parser stopped at a syntax error. Usual causes: an unescaped & in a URL (write &), HTML printed into the file by a template, a PHP warning or blank line before <?xml, or two plugins writing to the same URL. Most browsers show the line of the first error.
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://example.com/shop/?cat=shoes&sort=price</loc>
<lastmod>2026-09-20</lastmod>
</url>
</urlset>Wrong root element or namespace
An RSS feed at the sitemap URL, or a template that forgot the namespace. The root must be <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">, or <sitemapindex> with the same namespace for an index file.
Relative or other-host URLs ("Invalid URL", "URL not allowed")
Every <loc> is absolute, with the scheme. URLs on another host or protocol (http:// on an https:// site, the staging domain after a migration) are not accepted unless that host's robots.txt declares the sitemap. Regenerate the file after changing the site address and clear the plugin's sitemap cache.
Invalid date
01/09/2026, Sep 1, 2026 and Unix timestamps are invalid. Use 2026-09-01 or 2026-09-01T09:30:00+02:00. Sitemap priority, changefreq and lastmod covers which date to use.
Too many URLs or too large
Each file holds at most 50,000 URLs and 50 MB uncompressed. Above that, split it and list the parts in a sitemap index.
Duplicates and empty files
Duplicates usually come from two plugins or a page reachable under two paths. An empty sitemap is often a cache created before anything was published.
"Sitemap contains URLs which are blocked by robots.txt"
This was the older Search Console wording; today the Page indexing report, filtered to a submitted sitemap, lists the same URLs under "Blocked by robots.txt". Either you are listing pages you blocked on purpose (remove them from the sitemap: it is for pages you want indexed), or a Disallow rule is broader than you meant (narrow it). The Blocked by robots.txt guide goes through both.
"Indexed, not submitted in sitemap"
This is not an error. It means Google indexed a URL it found by links that your sitemap does not list; the current Page indexing report shows these with the "Unsubmitted pages only" filter. If the URL is a page you want in search, add it to the sitemap: usually a post type or taxonomy the generator excludes. If it is a parameter URL, a tag archive or a duplicate, fix it at the source with a canonical or noindex rather than leaving it.
Common mistakes
- Debugging a sitemap submitted an hour ago. Wait a day or two first.
- Testing only in your browser. Googlebot meets firewalls and bot rules that you do not. Use URL Inspection's live test.
- Submitting the redirecting URL. Submit and declare the final sitemap address.
- Listing redirects, 404s and
noindexpages. The sitemap is for canonical pages that answer 200. - Two sitemaps from two plugins, each declared somewhere. Keep one, remove the other in Search Console and on the site.
- Leaving the staging domain in the file after go-live. Regenerate and clear the cache.
Questions people ask
How do I fix "Couldn't fetch" for a sitemap in Search Console?
First open the sitemap URL in a browser: it must answer 200 with XML, not a redirect, a login page or a 404. Check that robots.txt does not block it and that no firewall or security plugin blocks Googlebot. If it loads fine, the status is often just delayed, since newly submitted sitemaps can show Couldn't fetch for days; resubmit it and look again later.
What does "Sitemap could not be read" mean?
It means Google has no readable copy of the file yet, usually because it could not download it; it is shown with the Couldn't fetch status. It rarely points at a broken XML file, which Google reports as "Has errors" with specific messages. Check that the sitemap URL answers 200 with XML to Googlebot using URL Inspection's live test, then resubmit.
Does Google use a sitemap that has errors?
Partly. When the status is Has errors, Google could download the file and uses the entries it was able to parse, while skipping the broken ones. A file that is not well-formed XML may yield nothing at all. Fix the errors listed in the report so every URL you want found is read, then resubmit.
What does "Indexed, not submitted in sitemap" mean?
It means Google found and indexed a URL through links, but your sitemap does not list it. It is not an error. If the page should be in search, add it to the sitemap, often by including a post type or taxonomy the generator skips. If it is a duplicate or a parameter URL, fix it with a canonical or noindex instead.
Why does Search Console say my sitemap has URLs blocked by robots.txt?
Because a Disallow rule in robots.txt matches URLs your sitemap lists, so you are asking Google to find pages it may not fetch. Either remove those URLs from the sitemap, if they are meant to stay uncrawled, or narrow the rule if it blocks pages you want in search. Test a few of the URLs against your live robots.txt to see which line matches.
Why are pages in my sitemap not indexed?
A sitemap tells Google a page exists; it does not make Google index it. Common reasons are thin or duplicate content, a canonical pointing elsewhere, a noindex tag, a redirect or error on the listed URL, or Google not having crawled it yet. Check a few of the URLs with URL Inspection in Search Console, which says why each one is excluded.