Sitemap Could Not Be Read or Couldn't Fetch: How to Fix It
When the Sitemaps report in Search Console says Couldn't fetch, or lists the error Sitemap could not be read, Google either failed to download the file or downloaded something it could not parse as a sitemap. Sometimes the status is only a delay on a newly submitted file. Often there is a real fault: a redirect, an HTML page served in place of XML, a stray line before the XML declaration, or a firewall that challenges Googlebot. Until it is fixed, Google cannot use the sitemap to discover your new and updated pages. This guide shows you how to test the sitemap the way Google sees it, find the exact fault, fix it on common platforms and resubmit with confidence.
What the two messages mean
The Sitemaps report in Search Console shows a status for every sitemap you submit. Success means Google read it. Has errors means it read the file but found problems inside it. Couldn't fetch means Google could not get the file at all, or got something it could not use, and the error details often say Sitemap could not be read.
There are two quite different situations behind that status:
- A processing delay. A sitemap submitted minutes or hours ago can show Couldn't fetch before Google has actually tried. If the file is valid and returns 200, this usually clears on its own within a day or two.
- A real fault. The URL redirects, returns an error, is blocked, sends HTML instead of XML, or contains XML that does not parse. These never clear on their own.
The way to tell them apart is to test the file yourself, exactly as submitted, from outside your own network. If every check below passes, give it time. If any fails, you have found the fault.
Common causes
| Cause | What you see when you test | Fix |
|---|---|---|
| Wrong address submitted | 404, or a 301 to the home page or another file | Submit the address your CMS or plugin really uses |
| HTML served instead of XML | Status 200 but Content-Type: text/html and a web page in the body | Fix the rewrite rule or plugin conflict that sends the sitemap URL to the theme |
| Output before the XML declaration | A blank line, a byte order mark or a PHP warning above <?xml | Remove the stray output, often whitespace after a closing ?> in a theme or plugin file |
| Invalid XML | Browser shows an XML parsing error; xmllint reports a line number | Escape & in URLs, close every tag, use UTF-8 |
| Blocked access | 403, a login page, a CAPTCHA or a JavaScript challenge for bots | Allow verified Googlebot; remove password protection from the sitemap path |
| Blocked by robots.txt | URL Inspection says the URL is blocked | Remove the Disallow rule that matches the sitemap path |
| Too large | More than 50,000 URLs or more than 50 MB uncompressed | Split into several sitemaps listed in a sitemap index |
| Slow or failing generation | Timeouts or 5xx on large dynamic sitemaps | Cache or pre-generate the file; split it into smaller pieces |
| Cached broken copy | Fixed at origin but a CDN or plugin still serves the old file | Purge the cache for the sitemap URLs |
How to test the sitemap the way Google sees it
Start with the headers. The status must be 200, with no redirect, and the content type should be XML:
curl -sSI https://example.com/sitemap.xml
HTTP/2 200
content-type: application/xml; charset=UTF-8
content-length: 18342A 301 or 302 means you submitted an old address; follow it with curl -sSIL to see where it ends up and submit that final URL instead. A text/html content type means something other than the sitemap generator answered.
Then repeat the request with the Googlebot user agent, because security tools often treat it differently:
curl -sS -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://example.com/sitemap.xml | head -c 400The first characters must be <?xml or the opening <urlset or <sitemapindex tag. If you see <!DOCTYPE html>, a challenge page or a blank line first, that is the fault.
Check that the XML parses
curl -sS https://example.com/sitemap.xml -o sitemap.xml
xmllint --noout sitemap.xml && echo "valid XML"
grep -c "<loc>" sitemap.xml
head -c 3 sitemap.xml | xxdxmllint prints the line and column of the first parse error, such as an unescaped ampersand. The grep counts URLs, so you can check the 50,000 limit. The last line shows the first three bytes; efbbbf is a UTF-8 byte order mark, and 0a is a stray newline. For a sitemap index, repeat the tests on two or three of the child sitemaps it lists, because one broken child is a common cause.
The robots and sitemap checker runs these tests for you and also checks that the URLs listed inside return 200.
What a valid sitemap looks like
Compare your file with this minimal version. If yours starts differently, has anything before the first line, or uses another namespace, start there.
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://example.com/</loc>
<lastmod>2026-10-17</lastmod>
</url>
<url>
<loc>https://example.com/shop/?type=garden&size=large</loc>
</url>
</urlset>Note the ampersand in the second URL is written as &. A raw & anywhere in a sitemap breaks the whole file. Every loc must be a full absolute URL on the same host as the sitemap, using the protocol your site really uses.
A sitemap index lists other sitemaps rather than pages. It cannot list another index, and each child must obey the same limits:
<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<sitemap><loc>https://example.com/post-sitemap.xml</loc></sitemap>
<sitemap><loc>https://example.com/page-sitemap.xml</loc></sitemap>
</sitemapindex>Make sure the server sends the right content type. On Apache, add this to .htaccess if it does not:
AddType application/xml .xmlOn nginx, the default mime.types file already maps .xml to text/xml; check that a location block is not overriding it with default_type text/html.
Platform notes
- WordPress. Core WordPress serves
/wp-sitemap.xml. Yoast SEO and Rank Math switch that off and serve/sitemap_index.xmlinstead, so a site that changes plugin often ends up with the old address submitted. After changing SEO plugin, save the permalinks screen once to refresh rewrite rules. See WordPress sitemap index fixes. - Shopify. Shopify generates
/sitemap.xmlas an index automatically and you cannot edit it directly. If it fails, check that the store is not password protected and that the primary domain is the one you submitted. See robots and sitemaps in Shopify. - Next.js. An
app/sitemap.tsfile is served at/sitemap.xml. Check that middleware for authentication, redirects or localisation does not intercept that path. See robots and sitemaps in Next.js. - Cloudflare. Check Security Events for challenges on the sitemap path, and purge the sitemap URLs from cache after any fix. A cache rule that caches everything can store an error page under the sitemap address.
A worked example
A site submitted /sitemap.xml two years ago and it showed Success. After a new SEO plugin was installed, the status changed to Couldn't fetch. The header test shows the cause at once:
curl -sSI https://example.com/sitemap.xml
HTTP/2 301
location: https://example.com/sitemap_index.xmlThe new plugin serves its index at /sitemap_index.xml, so the cleanest fix is to give Search Console the address the sitemap really lives at. The owner submits the new address, removes the old one from the report, and adds a line to robots.txt:
Sitemap: https://example.com/sitemap_index.xmlThe new sitemap shows Success later the same day, and the discovered URL count climbs over the next week.
The fix, step by step
Step 1
Test the exact submitted address
Copy the sitemap URL exactly as it appears in the Sitemaps report and request it with curl -sSI. The response must be a direct 200 with no redirect. If you get a 301 or 302, follow it with curl -sSIL and note the final address. If you get a 404, find the address your CMS or plugin really serves. Open the same URL in a private browser window too and confirm you see XML, not a web page.
Step 2
Check the content type and first bytes
Look at the content-type header from the previous test. It should be application/xml or text/xml. Then fetch the body with the Googlebot user agent and look at the first few hundred characters. The file must start with the XML declaration or the opening urlset or sitemapindex tag. A blank line, a byte order mark, a PHP warning or any HTML before it means the output needs fixing at the source.
Step 3
Validate the XML
Save the file and run xmllint --noout on it, or open it in a browser that shows XML errors. Fix the first error reported, usually an unescaped ampersand that must be written as &, an unclosed tag, or text in the wrong character encoding. Check the namespace is exactly the sitemaps.org 0.9 address. Run the validator again until it reports no errors, then test two or three child sitemaps if you use an index.
Step 4
Remove access blocks
Use URL Inspection's live test on the sitemap address to see whether robots.txt blocks it, then check your security plugin, WAF and CDN logs for challenges or blocks on that path. Remove password protection, country blocks and bot challenges from sitemap URLs, and allow verified Googlebot. Confirm the fix by repeating the Googlebot user agent curl test and checking that the live test in URL Inspection reports the URL as available.
Step 5
Check size and split if needed
Count the loc entries in each sitemap file and check its uncompressed size. A single sitemap may hold at most 50,000 URLs and 50 MB. If yours is larger, or slow to generate, split it by content type or date into several smaller sitemaps and list them in a sitemap index. Make sure no index lists another index, then confirm each child returns 200 with an XML content type.
Step 6
Purge caches
Once the source is fixed, purge the sitemap URLs from every cache that might hold an old copy: your caching plugin, the server cache and the CDN. Request the sitemap again with curl and check the response headers for a cache status showing a fresh copy, such as a MISS followed by a HIT with the corrected content. Add a rule so the sitemap is cached for a short time only, or bypassed.
Step 7
Resubmit and add to robots.txt
In the Sitemaps report, remove any old or wrong sitemap addresses and submit the correct index URL. Add a Sitemap: line with the full https address to robots.txt so other crawlers find it as well. If the status shows Couldn't fetch straight after submission, wait a day or two before changing anything, because a new submission often needs time before Google processes it, and repeated resubmission does not speed that up.
Step 8
Confirm it was read
Return to the Sitemaps report after a few days and check the status shows Success, the Last read date is recent and the Discovered pages count looks right for your site. Open the sitemap's details to see whether any URLs inside it have indexing problems. If the status is still Couldn't fetch after several days and every test passes, run the URL Inspection live test again and compare its response with yours.
Edge cases worth knowing
- Couldn't fetch on a file that passes every test. A brand new submission can show this for a day or more. Check again after 48 hours before changing anything.
- Gzipped sitemaps. Google reads
.xml.gzfiles. The 50 MB limit applies to the uncompressed size, and the file must really be gzip, not plain XML with a.gzname. - Sitemaps on another host. A sitemap on a CDN or subdomain can list URLs for your main site only if both properties are verified in Search Console, or the sitemap is referenced from the main site's robots.txt.
- Ping URLs no longer work. Google retired its sitemap ping endpoint in 2023. Use the Sitemaps report and the
Sitemap:line in robots.txt instead. - Read but URLs not indexed. A sitemap that shows Success only helps discovery. If the pages inside are not indexed, the cause is the pages; see Discovered, currently not indexed and sitemap 404s.
Keeping the sitemap readable
Sitemaps break most often after a change you made for another reason: a new plugin, a theme update, a migration or a new security rule. Build a short check into each of those changes.
- After any plugin, theme or server change, run
curl -sSIon the sitemap and confirm 200 and an XML content type. - Keep one sitemap address and list it in robots.txt with a
Sitemap:line, so every crawler finds it. - Submit the index, not each child sitemap, so new children are picked up automatically.
- Exclude the sitemap path from bot challenges and password protection on staging-to-live switches.
- Open the Sitemaps report monthly and look at the Last read date; one that stops moving is an early warning.
A regular site crawl also compares the sitemap with the pages your site really links to, which catches missing and stale entries.
1. Why does Search Console say Couldn't fetch for a new sitemap?
A newly submitted sitemap often shows Couldn't fetch simply because Google has not processed it yet. If the file returns a direct 200, is served as XML and parses without errors, wait a day or two and check again before changing anything. If the status is still the same after that, test the address with curl and URL Inspection, because a redirect, a block or HTML in place of XML is the real cause in most lasting cases.
2. What content type should a sitemap use?
A sitemap should be served with an XML content type, either application/xml or text/xml, usually with charset UTF-8. Most servers do this automatically for files ending in .xml, and sitemap plugins set it themselves. Problems arise when a rewrite rule sends the sitemap address to the theme, or a server block forces text/html, so the browser shows a web page rather than XML. Check the content-type header with curl -I to see what your server really sends.
3. Can a redirect cause Sitemap could not be read?
Yes, a redirect on the submitted sitemap address is one of the most common causes. Search Console expects the address you submitted to return the sitemap directly with status 200. This often happens after changing SEO plugin, moving from http to https, or switching between www and non-www. Find the final address with curl, submit that address in the Sitemaps report, remove the old entry and update the Sitemap line in robots.txt so everything points at one URL.
4. How many URLs can one sitemap contain?
One sitemap file can contain up to 50,000 URLs and must be no larger than 50 MB uncompressed. Sites with more pages split them into several sitemaps and list those in a sitemap index, which can itself list up to 50,000 sitemaps. Splitting by content type, such as products, categories and posts, also makes problems easier to find, because the Sitemaps report then shows which group has errors. Large dynamic sitemaps that are slow to generate are another reason to split.
5. Does a firewall or Cloudflare block my sitemap from Google?
It can, if a security rule challenges or blocks the sitemap path for bots. Googlebot cannot pass a CAPTCHA or a JavaScript challenge, so it receives an HTML page instead of your XML and cannot read it. Check your security logs for events on the sitemap address, confirm the blocked requests come from genuine Googlebot addresses, and exclude sitemap URLs from challenges. Verified search engine crawlers are usually allowed by default, but custom rules can override that.
6. Should I submit every child sitemap or just the index?
Submit the sitemap index and let Google find the child sitemaps from it. This keeps the Sitemaps report tidy, and new child sitemaps that your plugin adds later are picked up automatically. Search Console still shows the children under the index, so you can see which one has a problem. Add the index address to robots.txt with a Sitemap line as well, so other search engines and crawlers that never see your Search Console account can find it.
7. My sitemap shows Success but pages are still not indexed. Why?
A sitemap that Google can read only helps it discover URLs; it does not guarantee they will be indexed. Google still decides for each page whether to crawl and index it, based on quality, duplication, canonical tags, noindex rules and how important the page appears. Check the indexing status of the listed URLs in the Page indexing report, filtered to that sitemap. Make sure the sitemap lists only canonical, indexable pages that return 200, and link to them from your own pages.
The robots and sitemap checker fetches your sitemap as a crawler would, checks the status, content type, XML and size limits, and tests the URLs it lists.
Open Robots and Sitemap Fixes →