Why Search Console says it could not fetch a sitemap that loads fine for you

What the error means

You submitted a sitemap URL and Search Console reports that it could not read it. Opening the same URL in your browser works.

Why Google rejects it

Three causes account for nearly all of it. The submitted path no longer matches what the store serves, so the request 404s. The sitemap is an index whose child sitemaps fail even though the index itself is fine. Or bot protection answers the crawler differently than it answers you — you are a warm browser session, the crawler is a cold request from an unknown network.

How to fix it

1. Submit the exact path the store serves at the root, and submit it without a trailing variant. Guessing a path that used to work is the most common version of this.
2. If the file is an index, open a child sitemap directly. An index that lists dead children reports as unfetchable.
3. Check the response to an outside request, not to your browser. A 403 to a crawler and a 200 to you look the same from your desk.
4. Give it time after fixing. The report keeps the old status until the next fetch, so a fixed sitemap still reads as failing for a while.

Common causes

Wrong sitemap address or host

Search Console fetches the exact address submitted, including protocol, hostname, path, and redirects. A domain property does not make a sitemap on a different host or a retired www/non-www version equivalent. Open the URL from the report and compare it with the live sitemap address on your canonical domain.

A child sitemap fails

A sitemap index can return successfully while one of its listed child files returns an error, redirects to an unrelated page, or is malformed. Open every child address from the index directly. If only one product or collection sitemap fails, check that page type's publishing and routing rather than replacing the working index.

Crawler access is challenged

A browser may have cookies, JavaScript, or a trusted network that Googlebot does not. A CDN, firewall, password mode, or bot challenge can return 403, 429, a login page, or HTML instead of XML to Google. Compare the response from outside the store and inspect security logs around Google's reported fetch time.

Transient origin or DNS failure

The sitemap can fail during a short hosting outage, DNS change, TLS certificate problem, or origin timeout. If the same URL later opens normally, do not rewrite a valid sitemap immediately. Check the hosting and DNS event logs and see whether subsequent Google fetch attempts also fail.

Sitemap is not valid XML or exceeds limits

An HTML error page saved with an .xml URL, invalid XML characters, or a broken index can stop parsing. A single sitemap file must remain within Google's published size and URL limits. A validator and the response content type help distinguish an XML problem from a server-access problem.

Fix it on your platform

On Shopify

1. Open https://your-domain.example/sitemap.xml on the primary public domain. Shopify generates its sitemap automatically; confirm the response is XML and that it links to the product, collection, page, and blog child sitemaps.
2. In Search Console, submit the sitemap for the verified property that matches the canonical host. If multiple Shopify domains are configured for international markets, check each domain's sitemap and whether secondary domains redirect as intended.
3. If the store is in password-protected or private mode, make it publicly accessible before expecting Google to fetch the sitemap. Recheck the exact URL after changing the store visibility.
4. If a custom robots.txt.liquid or CDN rule was added, review it for a sitemap path block or crawler challenge. Restore a known-good version or remove only the rule causing the fetch failure.

On WooCommerce

1. Open the sitemap generated by your active SEO plugin or WordPress core and identify which generator owns it. Common installations expose an index at /sitemap_index.xml or /wp-sitemap.xml; submit the address that actually responds on your site.
2. Avoid running two sitemap plugins that claim the same index URL. In the active SEO plugin, confirm sitemap generation is enabled and that products or pages are not excluded unintentionally.
3. If you changed permalink or rewrite settings, visit Settings > Permalinks and save the current structure to refresh WordPress rewrite rules. Then test the sitemap and a child sitemap again.
4. Check security, caching, and maintenance plugins for rules that require a login or challenge automated requests to XML paths. Purge stale cached sitemap output after changing the generator.

On other platforms

1. Use the platform's SEO or sitemap settings to locate the published sitemap URL rather than guessing a common filename. Make sure it is publicly accessible without a cookie, login, or JavaScript challenge.
2. For Wix, BigCommerce, or Squarespace, confirm the site is published on the intended primary domain and that the generated sitemap is not a preview or staging URL.
3. On custom sites, return UTF-8 XML at the submitted address, use absolute URLs on the correct host, and ensure every sitemap-index child address resolves successfully.
4. Ask the host or CDN administrator to check access logs for Googlebot fetches of the sitemap path, including 403, 429, 5xx, timeout, and TLS failures.

How to confirm it is fixed

1. In the Sitemaps report, open the failing row and note the exact URL and reported error details. Test that exact URL, not a guessed replacement.
2. Use URL Inspection's live test on the sitemap address where available; confirm crawl is allowed and page fetch is successful. A normal browser load alone does not confirm Google can retrieve it.
3. Open the sitemap index and each child sitemap. Validate the XML and check that the response contains sitemap data rather than an HTML challenge or error page.
4. Run the sitemap check from outside your network to inspect the public fetch and sample listed URLs, then resubmit the corrected sitemap in Search Console.
5. Revisit the report after Google retries. A successful fetch means Google read the file; it does not guarantee every listed URL will be crawled or indexed.

A worked example

Hypothetical case: a homewares store moves from a temporary myshopify.com address to its branded domain and submits the old sitemap again under the new Search Console property. The old address redirects through the storefront and presents a consent page to an unauthenticated fetch, while the branded domain serves a clean /sitemap.xml index. The owner confirms the primary domain in Shopify, submits the branded sitemap, and checks each child sitemap directly. The Sitemaps report later records a fresh successful fetch. Product discovery still takes longer because sitemap processing is separate from indexing decisions.

Other errors like this