Search Console Says “Couldn’t Fetch” Your Sitemap—How to Find the Failure

Google Search Console says it “Couldn’t fetch” your sitemap, but the same XML file opens in your browser. That does not prove the sitemap is healthy. Your browser may be using cached DNS, trusted cookies, a logged-in session or a nearby CDN location while Google’s sitemap fetch received a timeout, redirect problem, security challenge or invalid response.

The fastest fix is not to delete and resubmit the same sitemap repeatedly. First establish whether Google can retrieve the exact submitted URL, then separate a delivery failure from an XML parsing failure. Those are different problems and require different evidence.

What “Couldn’t fetch” actually means

In Search Console’s Sitemaps report, “Couldn’t fetch” means Google could not retrieve the sitemap file itself. It is different from a sitemap that was downloaded successfully but contains invalid XML, unsupported tags or problematic child URLs.

A sitemap helps search engines discover URLs; it does not guarantee that every listed page will be crawled or indexed. Fixing the fetch status restores discovery data, but it will not override noindex directives, weak internal linking, duplicate canonicals or low-value pages.

Start with the exact submitted URL

Copy the sitemap URL from Search Console instead of typing what you think it should be. Small differences matter: HTTP versus HTTPS, www versus non-www, uppercase characters, a missing path, an old staging hostname or submitting a child sitemap that later moved.

1. Open the exact URL in a private browser window while logged out.

2. Confirm the final response is HTTP 200—not a branded error page returning 200.

3. Record every redirect and make sure it ends at an XML file on the intended verified property.

4. Check the Content-Type header and confirm the body is XML rather than HTML, a login page, CAPTCHA or firewall challenge.

5. Repeat the request from another network or region if your CDN uses geographic rules.

6. Compare the result with Search Console’s last-read date before assuming the current response reproduces the earlier failure.

If the response is 401, 403, 429 or another client error, use Webcurry’s other-4xx crawl-access guide. If it is 500, 502, 503 or 504, follow the Search Console server-error workflow.

Confirm Google receives XML, not something that only looks correct

A browser can display an XML tree even when the server response is unstable. Inspect the raw response. A valid sitemap uses the sitemap protocol, is UTF-8 encoded and contains either a URL set or a sitemap index with supported namespaces.

• The first meaningful element should be urlset for a URL sitemap or sitemapindex for an index.

• Each URL belongs inside a loc element and should use a fully qualified absolute URL.

• Special characters in URLs must be XML-escaped.

• The file must not contain application error messages, HTML templates or debug notices before the XML.

• A single uncompressed sitemap must stay within Google’s limit of 50 MB and 50,000 URLs.

• Child sitemaps referenced by an index must also be fetchable and normally belong to the same site unless cross-site submission is configured.

Do not add optional fields merely to make the file look more complete. Incorrect last-modified dates are less useful than leaving them out, and priority or change-frequency values do not solve a fetch failure.

Trace the delivery path

A sitemap request may travel through DNS, a CDN, bot protection, a web application firewall, a reverse proxy, the hosting server and application code. Locate the layer that generated the failure.

1. Check DNS for both IPv4 and IPv6. A broken AAAA record can fail for some fetchers while your own connection succeeds over IPv4.

2. Review CDN and firewall event logs around Google’s last fetch. Look for rate limits, bot challenges and country restrictions.

3. Check origin logs. If no request reached the origin, the edge layer blocked or failed first.

4. Inspect redirects for loops, long chains, protocol switching or movement to another hostname.

5. Test cache behaviour. A stale edge can serve an old error after the origin has recovered.

6. Confirm the sitemap remains available without cookies, JavaScript, authentication or a browser challenge.

Never allow requests simply because the user-agent says Googlebot. User agents can be spoofed. If a security rule needs a crawler exception, verify Google’s identity using reverse DNS or its published crawler IP ranges and scope the rule narrowly.

Why a sitemap opens for you but fails for Google

• Your browser has a trusted security cookie or administrator session.

• The CDN serves different edge locations or IP families.

• Google hit a temporary timeout or maintenance response.

• A firewall rate limit affected crawlers but not a single manual visit.

• The submitted URL redirects differently for Googlebot, HTTP or another hostname.

• The response body is an HTML challenge even though the URL ends in .xml.

• The file was fixed after Google’s recorded fetch, so the report is stale.

Platform-specific checks

Wix

Wix generates and updates the sitemap automatically. The normal sitemap index is available at the site’s root, and Wix resubmits it during the SEO setup process. Do not upload a competing manual sitemap merely because Search Console shows a temporary error.

Confirm the custom domain is connected, the site is published and the submitted URL uses the preferred live domain. If an external proxy or security service sits in front of Wix, test that layer. Once the Wix sitemap is healthy, publishing new pages updates it automatically, so routine resubmission is unnecessary.

WordPress

Identify which component owns the sitemap: WordPress core, an SEO plugin, a dedicated generator or custom code. Avoid running multiple sitemap systems with conflicting routes. Temporarily test the suspected plugin conflict in staging, refresh permalink rules if appropriate, and clear page, object, server and CDN caches.

Look for PHP warnings, memory failures or database errors inserted into the XML. Large taxonomies can generate slow child sitemaps that time out even when the index loads quickly. Test every child URL listed by the sitemap index.

Shopify

Shopify generates sitemap.xml at the root domain and automatically links child sitemaps for products, collections, pages and blog posts. Submit the sitemap for the active primary domain. If the store recently changed domains or international-market settings, make sure Search Console is checking the matching property and the submitted hostname does not redirect unexpectedly.

Do not confuse fetch success with indexing success

A processed sitemap can still show zero indexed pages if its URLs are new, noindexed, duplicated, redirected or not considered useful enough to index. Once Google can retrieve the file, inspect individual important URLs instead of repeatedly editing the sitemap.

For pages that Google discovered but has not crawled, see Webcurry’s Discovered—currently not indexed guide. If pages are excluded by a hidden directive, use the noindex troubleshooting workflow.

A safe recovery sequence

1. Make the exact submitted sitemap URL return stable HTTP 200 with valid XML to anonymous requests.

2. Fix DNS, redirects, firewall rules, timeouts or application errors at the layer that caused them.

3. Validate the sitemap format and test every child sitemap in an index.

4. Remove obsolete sitemap submissions that point to retired domains or paths.

5. Submit the correct root sitemap or sitemap index once.

6. Wait for Search Console to fetch and process it, then monitor the last-read date and discovered URL count.

7. Inspect high-priority page URLs separately; a successful sitemap does not guarantee indexing.

When you should not resubmit

Do not resubmit when the existing sitemap is already processed, current and error-free. Wix and Shopify update generated sitemaps automatically, and most WordPress sitemap systems do the same. Resubmission does not make Google index new pages instantly and can distract from the actual page-level issue.

Likewise, do not submit every child file if a working sitemap index already references them. A single clean index is easier to maintain unless separate submissions are deliberately used for monitoring.

The practical conclusion

Treat “Couldn’t fetch” as a delivery investigation. Verify the exact URL, status code, response body, redirects and access controls. Then validate the XML and child sitemaps. Correct the narrow failure, submit once, and use page inspection for any remaining indexing problem.

If Search Console, your browser, the CDN and the origin all report different results, request a technical sitemap review from Webcurry. The disagreement usually reveals the failing layer faster than rebuilding the XML.