You open Google Search Console to check indexing, navigate to the sitemap report, and see the status "Couldn't fetch." Sound familiar?

This error can cause panic: it seems like Google can't see your site at all and all pages are about to drop out of the index. In practice, the situation is almost always resolved in 10-15 minutes, and in half the cases the problem isn't even on your end.

Below is a proven algorithm: from diagnosis to complete resolution. No fluff, with specific steps and real screenshots of the Search Console interface.

💡 Quick overview:

• Check if the error is real: often it's a Google glitch, and you just need to wait or request a new crawl
• Test sitemap accessibility via URL Inspection and Live Test: this takes a minute and immediately shows whether Google can see your file
• If the error is real, go through the checklist: XML validation, robots.txt, plugins, server response
• In complex cases, use third-party diagnostic tools and resubmit the sitemap through the Search Console interface

Why Google can't fetch the sitemap

The root of the problem should be split in two: an error on Google's side and an error on your side. The difference is fundamental because in the first case you don't need to do anything at all.

Search Console glitch. Since the major Search Console interface update, situations have become more frequent where the "Couldn't fetch" status is false. Google attempts to load the sitemap, something goes wrong within the system itself, and the report shows an error even though the file on the server is perfectly fine. Google engineers are aware of this issue, and the official documentation states directly: if fetching fails, the system will retry within several days, and only after a series of failures will it stop checking.

Actual unavailability. The sitemap physically isn't being served: broken XML, incorrect Content-Type, blocking in robots.txt, a security plugin rejecting Googlebot requests, a misconfigured CDN or firewall. This also includes expired SSL certificates on the domain, which prevent Google from establishing a secure connection.

Indirect causes. Some WordPress plugins (especially security and caching ones) may accidentally block the Googlebot User-Agent. Sometimes the culprit isn't the plugin you'd first suspect; the problem manifests as a cascade: a cache plugin generates a static copy of the sitemap page, while a security plugin blocks requests to that copy.

How to check if the sitemap is accessible

The fastest way to distinguish a Google bug from a real problem is the URL inspection tool right in Search Console. It shows what Googlebot sees when accessing the file.

Step 1. Open Search Console, paste the full sitemap URL into the inspection bar at the top of the interface, and press Enter.

Step 2. If the URL isn't indexed (this is normal for sitemaps since they typically have noindex), click the "Test live URL" button. Search Console will perform a Live Test, access the file in real time, and show the result.

Step 3. Scroll down the Live Test page to the "Page fetch" section. If it says "Successful," Google can see the file, and the "Couldn't fetch" error in the sitemaps report is a bug on Search Console's side. Do nothing: the status will update during the next check cycle, or resubmit the sitemap via the button in the Sitemaps report.

If Page fetch shows an error, proceed to the next section.

Step-by-step fix: five-point checklist

When the live test confirms that Google truly can't fetch the sitemap, go through the points in order. Each next step applies only if the previous one didn't solve the problem.

1. Check XML validity

Open the sitemap URL in your browser. If you see clean XML with <urlset> and <url> tags, the structure is fine. If the page is blank, throws a PHP error, or shows a white HTML page, the sitemap is broken.

For deeper verification, use XML Sitemap Validator, a free online tool that shows formatting errors, broken URLs within the sitemap, and non-compliance with the Sitemap Protocol standard. It will also tell you if the 50,000 URL per file limit is exceeded (in which case you need a sitemap index).

2. Check robots.txt and server headers

Googlebot must have access to the sitemap file. Open yoursite.com/robots.txt and make sure there's no line like:

1
Disallow: /sitemap.xml
2

Also check that the Googlebot User-Agent itself isn't blocked with a line like User-agent: Googlebot followed by Disallow: /.

The server response Content-Type header should be application/xml or text/xml. If the server serves the sitemap as text/html, Google may not recognize the file. You can check headers via Fetch & Render from TechnicalSEO, which shows the page through Googlebot's eyes with all HTTP headers.

3. Check WordPress plugins

Security plugins (Wordfence, Solid Security, Sucuri) and caching plugins (WP Rocket, W3 Total Cache, LiteSpeed Cache) are the main suspects. Algorithm:

• Cache plugins. Clear the cache, temporarily exclude sitemap.xml from caching. In WP Rocket there's a "Never cache URLs" field; in LiteSpeed Cache, the "Excludes" tab. After excluding, clear the cache again.

• Security plugins. Check the plugin logs for blocked requests to sitemap.xml from User-Agent Googlebot. Wordfence shows such blocks in real time under "Tools → Live Traffic."

• SEO plugins. Sometimes the problem lies in the sitemap generator itself. Yoast SEO, Rank Math, All in One SEO, each has its own handler. Try regenerating the sitemap: in Yoast SEO this is done via "Settings → Site features → XML sitemaps" (toggle off-on); in Rank Math, via "Sitemap Settings → Save changes."

4. Rule out hosting and CDN blocking

Some hosting providers and firewalls (Cloudflare, Sucuri WAF) may block Googlebot requests by IP or User-Agent. Check:

• Cloudflare. In the "Security → Events" section, look for blocked requests to sitemap.xml. If found, create a WAF rule allowing User-Agent Googlebot for URLs containing sitemap.

• Hosting firewall. Some control panels (cPanel, ISPmanager) have built-in ModSecurity rules that falsely trigger on XML files. Check Apache/NGINX logs for 403 errors when accessing sitemap.xml.

5. Resubmit the sitemap

After fixing the cause, return to Search Console → Sitemaps → paste the sitemap URL in the "Add a new sitemap" field → Submit. The system will attempt to load the file immediately. If the status changes to "Success," the problem is solved.

Important note: even after successful sitemap loading, Google doesn't guarantee indexing of all URLs listed in it. Indexing speed and completeness depend on site size, authority, and content update frequency.

Diagnostic tools

In addition to Search Console's built-in tools, keep three external tools handy; they cover virtually all diagnostic scenarios:

• Online validator from XML-Sitemaps, a structure validator. Checks syntax, URL count, nested sitemap indexes, and compliance with the Sitemaps.org standard. Free, no registration required.

• Fetch & Render, a Googlebot emulator. Shows how Google sees the page: HTTP headers, status code, rendered HTML. Useful when you need to understand whether the server is substituting content for different User-Agents.

• PageSpeed Insights, an indirect but important tool. If the server responds slowly (TTFB over 1-2 seconds for a static XML file), Google may drop the connection when attempting to load a large sitemap.

⁉️🤔 Frequently asked questions

Why does the "Couldn't fetch" error appear and disappear without any action on my part?

This is classic behavior for a bug on Google's side. The system periodically rechecks the sitemap on its own schedule, and at certain moments an internal glitch causes a false error. The next automatic check often succeeds, which is why the status flickers. If the sitemap is physically accessible (verified via Live Test), ignore the flickering; it doesn't affect indexing.

How often does Google check the sitemap after successful loading?

The recheck schedule isn't tied to regular site crawling. Google doesn't disclose the exact frequency, but in practice for active sites it ranges from several times a week to once every few days. If you've made major changes to the sitemap and want to speed up processing, resubmit it via the Submit button in the Sitemaps report.

Could the error be related to sitemap size?

Yes. The limit is 50,000 URLs and 50 MB per file. If the sitemap exceeds either limit, Google may fail to process it. The solution is a sitemap index: one parent XML that references several child files, each within limits. Most WordPress SEO plugins do this automatically when the threshold is exceeded.

Should I add the sitemap to robots.txt?

Strongly recommended. Add the directive Sitemap: https://yoursite.com/sitemap.xml to robots.txt; this gives Google a second path to discover the file. Even if submission through the Search Console interface fails, Google can find the sitemap when crawling robots.txt.

Does a sitemap fetch error affect rankings?

Not directly. Google doesn't impose penalties for sitemap unavailability. Indirect impact is possible: without a sitemap, new or rarely updated pages may wait longer for indexing, especially on large sites with complex structures. For small sites with good internal linking, the absence of a sitemap is practically unnoticeable.

Sitemap unavailable: what to do right now

The algorithm comes down to three steps that cover the vast majority of cases:

• Live test. Paste the sitemap URL into the Search Console inspection bar → click Live Test. "Page fetch: Successful" → the error is false, do nothing. "Failed" → proceed further.

• Server-side diagnosis. Open sitemap.xml in your browser; do you see clean XML? Check robots.txt for Disallow? Clear cache and check security plugin logs? Run the file through XML Sitemap Validator?

• Resubmission. Fix the cause → return to Sitemaps → Submit. Status changed to "Success"? Done. If not, return to point 2 and check server headers via Fetch & Render.

If you approach diagnosis systematically and don't skip steps, the problem is resolved in one check cycle. And false Search Console errors, which account for a good half of inquiries on this topic, don't require any intervention at all.