What "Sitemap could not be read" and "Couldn't fetch" really mean, and when to wait

What the error means

Search Console reports that it could not read the sitemap you submitted. Sometimes the reason is "General HTTP error"; often the status simply reads "Couldn't fetch" with 0 discovered URLs, even though the file opens in your browser.

Why Google rejects it

The status appears for two different reasons. Either Google really could not fetch or parse the file (a block, an error, invalid XML), or it has not processed a newly submitted sitemap yet and shows a placeholder status. The second case is common on new properties and clears without changes.

How to fix it

1. Open the submitted sitemap URL in a private window and confirm it returns XML starting with <urlset or <sitemapindex.
2. Check what an outside request receives, not your browser: a 403 or challenge page to crawlers produces this status.
3. If the sitemap is an index, open one child sitemap too; a failing child can make the set unreadable.
4. If everything returns 200 and valid XML, wait several days before changing anything. Newly submitted sitemaps often show Couldn't fetch until Google processes them.
5. Do not keep deleting and resubmitting. Submit the correct URL once and check the Last read date.

Common causes

Sitemap is not yet processed

A newly submitted sitemap or a property with little history may show a placeholder or zero discovered URLs while Google has not completed a read. Check Last read and fetch details before changing a valid file. Repeatedly deleting and re-adding the sitemap can make diagnosis harder.

Google receives an error or challenge

A sitemap that opens in a logged-in browser may return 403, 429, 5xx, or a login page to Google. Robots rules can also block the sitemap itself. Test the exact submitted URL from outside the store and inspect edge logs.

Sitemap XML cannot be parsed

A response may contain HTML, invalid XML, an unescaped ampersand, or text injected before the XML declaration. If the submitted URL is an index, inspect child sitemaps too; one broken child can explain a partial read.

Wrong URL or stale sitemap host

Google fetches the exact address submitted. A sitemap on an old host, wrong protocol, or guessed path can fail even while a different sitemap works. Verify the live URL advertised by the platform or robots.txt.

Fix it on your platform

On Shopify

1. Open the primary storefront domain's /sitemap.xml in a private window. Shopify generates it automatically and lists child files; do not upload a replacement file unless you understand the platform behavior.
2. Submit the sitemap that matches the verified Search Console property and primary domain. Check that storefront password mode is off for public crawling.
3. Open child sitemap URLs from the index and confirm each returns XML. Review CDN or security app rules if public requests differ from your browser.
4. If the file is valid and accessible but just submitted, check Last read later rather than repeatedly resubmitting.

On WooCommerce

1. Identify the active sitemap generator: WordPress core commonly uses /wp-sitemap.xml, while SEO plugins may publish a sitemap index. Submit the live address that actually responds.
2. Avoid conflicting sitemap plugins. Inspect the index and child files for PHP notices, invalid XML, HTML error pages, or stale URLs.
3. If virtual sitemap paths return 404 after a permalink change, save the existing Settings > Permalinks configuration to refresh rewrite rules.
4. Check cache and security plugins for blocks or stale output on XML routes, then retest as an anonymous request.

On other platforms

1. Locate the published sitemap URL in the platform's current SEO settings or generated robots.txt file; avoid guessing a conventional filename.
2. Confirm the sitemap is publicly available on the canonical host and returns XML rather than preview, login, or challenge HTML.
3. On custom sites, validate UTF-8 XML and verify every child sitemap in an index. Keep individual files within Google's size and URL limits.
4. Check robots.txt and firewall rules for blocks on both the sitemap and the crawler requests to its children.

How to confirm it is fixed

1. Open the exact sitemap URL from Search Console's details page and confirm its response and XML structure.
2. If it is an index, test each child file directly and check that all listed URLs use the preferred host and protocol.
3. Run the sitemap check from outside your network, then resubmit only after correcting a concrete fetch or parse issue.
4. Check Last read and discovered URL count after Google processes it; successful processing does not guarantee crawling or indexing of each URL.

A worked example

Hypothetical case: a Shopify merchant submits a sitemap under an old www hostname after switching the store's primary domain. The old address opens in the owner's browser because it redirects, but a CDN rule challenges crawler requests to the child sitemap paths. Search Console reports Couldn't fetch with no useful discovery count. The owner confirms the live /sitemap.xml on the primary domain, removes the obsolete submission, and checks each child URL without cookies. They also narrow the CDN challenge for verified search crawlers. A later Last read date confirms Google fetched the sitemap; the merchant tracks indexing in the Page indexing report separately.

Other errors like this