Search Console Says Sitemap "Couldn't Fetch"? Causes, Checks and When to Wait

On this page

1. What "Couldn't fetch" actually means
2. Search Console sitemap couldn't fetch: checks in order
3. Common causes and fixes
4. WordPress-specific causes
5. Cloudflare and CDN issues
6. Shopify sitemaps
7. Large sites and WooCommerce stores
8. When to simply wait
9. After it shows Success
10. Quick check: check the sitemap
11. When to get help
12. FAQs

When Search Console says your sitemap "couldn't fetch", either Google genuinely could not download it, or the status has simply not updated yet. First open the sitemap URL in a private browser window. If it loads as clean XML, check robots.txt, firewall and CDN rules, and redirects. If everything checks out, especially on a new site or newly submitted sitemap, wait a few days before changing anything.

This guide explains the usual causes, the checks to run in order, fixes for WordPress and Shopify, and how to tell a real problem from a reporting delay.

What "Couldn't fetch" actually means

In the Sitemaps report, each submitted sitemap shows a status: Success, Has errors, or Couldn't fetch. "Couldn't fetch" means Google has not successfully retrieved the file. That can be because the URL returned an error, was blocked, redirected badly, or timed out. It can also appear when Google has not yet tried, which is common for newly submitted sitemaps on new or small sites.

The status alone does not tell you which. That is why testing the URL yourself comes first. If you are unsure what a sitemap is for, see XML sitemaps explained.

Search Console sitemap couldn't fetch: checks in order

1. Confirm the exact URL. Copy the submitted URL from Search Console and compare it with your real sitemap. Common mismatches: sitemap.xml versus sitemap_index.xml, http versus https, www versus non-www, or a missing trailing part.
2. Open it in a private window. It should load as XML listing URLs or child sitemaps, not a 404, a login page, a blank page or your homepage.
3. Check the status code. Use the browser's network tab or an online HTTP status checker. You want 200, not 301, 302, 403, 404 or 500.
4. Check robots.txt. Visit /robots.txt and make sure no rule blocks the sitemap path. Adding a Sitemap: line pointing to the right URL helps.
5. Run URL Inspection on the sitemap URL. Use the live test. If Google can fetch it, the status will usually update on its own.
6. Check the property. The sitemap must belong to the verified property. A sitemap on a different subdomain or protocol than the property can cause problems.

Common causes and fixes

Cause	How to spot it	Fix
Wrong URL submitted	URL gives a 404 or redirects	Remove it and submit the correct sitemap URL
Firewall or bot protection	Loads for you but live test fails, or 403 in logs	Allow verified Googlebot; relax bot challenges on the sitemap path
robots.txt blocking	Disallow rule matches the sitemap path	Remove the rule, add a Sitemap line
Redirect chain	Sitemap URL redirects one or more times	Submit the final URL directly
Cached or broken output	Sitemap shows old content or HTML instead of XML	Exclude sitemaps from page cache, clear cache
PHP errors or whitespace	XML parse error in browser	Find the plugin or theme printing output before the XML
Server timeouts	Sitemap is very slow or huge	Split into smaller sitemaps, improve hosting
Not yet processed	Everything loads fine and live test passes	Wait a few days, then check again

WordPress-specific causes

Which sitemap is active: WordPress has a built-in sitemap at /wp-sitemap.xml. SEO plugins usually replace it with their own, such as /sitemap_index.xml. Submitting the core sitemap after a plugin disabled it, or having two plugins generating sitemaps, causes confusion. Pick one, and submit only that.

Permalinks: if sitemap URLs return a 404, re-save the permalink settings (Settings, Permalinks, Save) to refresh rewrite rules. The guide on fixing WordPress 404 permalink errors covers this.

Caching: a page cache can serve a stale or broken sitemap. Most caching plugins exclude sitemaps, but server and CDN caches may not.

Security plugins and firewalls: some block requests they consider unusual, rate-limit crawlers, or block whole countries. If Googlebot comes from an IP range your firewall blocks, fetching fails. See WordPress firewalls explained.

Maintenance or coming soon mode: if a maintenance plugin is active, Google may get a 503 or a login page.

A blocked sitemap path is a common culprit. Review how robots.txt in WordPress works and make sure it lists the sitemap correctly.

Cloudflare and CDN issues

Cloudflare and similar services can challenge or block automated requests. Features like bot fight modes, strict security levels or country blocks may stop Googlebot. Verified search engine crawlers are usually allowed, but custom rules can override that. Check the security events log for blocked requests to the sitemap URL, and add a rule to skip challenges for that path if needed. The Cloudflare WordPress setup guide covers cache and security rules.

Shopify sitemaps

Shopify generates /sitemap.xml automatically, with child sitemaps for products, collections, pages and blogs. Fetch problems on Shopify are less common. When they happen, check that you submitted the primary domain, that the store is not password-protected, and that the domain is connected correctly. Shopify stores still in password mode cannot be crawled. The Shopify SEO checklist covers other setup points.

Large sites and WooCommerce stores

Stores with thousands of products, variations and images can produce very large sitemaps. A single sitemap file is limited to 50,000 URLs and a maximum file size, so SEO plugins split them into several child sitemaps under one index file. Problems appear when generating those files takes too long on shared hosting, and the request times out before Google receives anything.

Signs of this include a sitemap that loads slowly or only sometimes, or server error logs showing memory or time limit errors. Fixes include reducing the number of URLs per child sitemap in the plugin settings, excluding things that should not be indexed (attachment pages, empty tags, filtered URLs), using object caching, and moving to hosting with more resources. Cleaning up old revisions, expired transients and leftover plugin tables in the database also helps, because sitemap generation queries the same tables as the rest of the site. After any of these changes, open the sitemap index again, time how long each child file takes to load, and run a fresh live test in URL Inspection before resubmitting.

On multilingual sites, check that each language's sitemap is listed and that hreflang plugins are not generating separate, conflicting sitemaps. On sites that changed domain, make sure the new property has the new sitemap and that the old one is not still submitted in the wrong property.

When to simply wait

If the sitemap loads as valid XML, returns a 200 status, is not blocked by robots.txt, and the URL Inspection live test succeeds, there is usually nothing to fix. Google processes sitemaps on its own schedule, and the report can lag. This is especially common on new sites with few pages and little history.

While you wait, you can still request indexing for important pages through URL Inspection, and make sure they are linked from your homepage and menu. The guide on getting a website indexed faster lists what actually helps. Avoid deleting and resubmitting the sitemap every day; it does not speed anything up.

After it shows Success

A successful fetch does not mean every URL will be indexed. Open the sitemap in the report to see discovered URLs, then check the Pages report for excluded URLs and reasons. Make sure the sitemap only lists pages you want indexed: no redirects, no 404s, no noindex pages, no thin tag pages. The guide on page indexing errors explains each status.

Keep an eye on the sitemap after any big change: a redesign, a domain or hosting move, a new SEO plugin, or switching on a CDN. These are the moments when a working sitemap most often breaks. A quick check of the sitemap URL and the Sitemaps report after each change takes a minute and catches problems before they affect indexing.

Quick check: check the sitemap

1. Open the sitemap address in a private window and check it loads as XML.
2. Paste the address into the URL Inspection bar at the top of Google Search Console for the sitemap address and run Test live URL.
3. Check the address you submitted in Indexing > Sitemaps matches your domain exactly, with or without www.

When to get help

Get help when the sitemap stays "Couldn't fetch", or when pages are not getting indexed. WordPress SEO services covers this kind of work, with a written scope before anything starts. You can also send the details through the contact form.

FAQs

Why does Search Console say sitemap couldn't fetch?

Either Google could not download it because of a wrong URL, block, redirect or server error, or it has not processed it yet. Test the URL and run a live URL Inspection test to tell which.

How long does it take for a sitemap status to update?

It varies. On new sites it can take days. If the file loads correctly and the live test passes, give it time before changing anything.

Should I submit sitemap.xml or sitemap_index.xml?

Submit whichever your active SEO plugin or platform generates. Submitting the index file is enough; you do not need to submit every child sitemap.

Can Cloudflare cause sitemap couldn't fetch errors?

Yes, if security settings challenge or block Googlebot. Check the security events log and allow the sitemap path.

Does a sitemap error stop my site being indexed?

Not by itself. Google can find pages through links, but a working sitemap helps it discover new and updated pages more reliably.