Sitemap Could Not Fetch in Search Console and How to Fix It

Sitemap could not fetch is the status Google Search Console shows when Google tried to download the sitemap you submitted and failed. The message names the symptom without naming the cause, which could be anything from a mistyped address to a firewall that turns Googlebot away while letting people through. The causes are few and each one can be tested quickly, so the error tends to be one of the simpler fixes in technical SEO for WordPress websites.

The checks below run in the order that usually finds the cause fastest, starting with the address you submitted and finishing with problems that only appear now and then. A sitemap that Google cannot fetch does not remove pages from the index, so there is time to work through each check properly rather than changing several things at once.

What Couldn’t Fetch Means in Search Console

Couldn’t fetch means Google could not retrieve the sitemap file at all, so it never reached the point of reading the URLs inside it. The Search Console help page for the Sitemaps report separates this from a sitemap that was fetched but contains errors, then lists the reasons a fetch can fail.

The same page confirms that a failed fetch does not wipe out what Google already knows. If Google read the sitemap successfully in the past, a later failure does not make it forget that information. Pages it has already found through internal links also keep being crawled as normal.

The table below sets out the causes Google lists alongside the firewall problem that often sits behind its general error. Each row shows the quickest way to confirm the cause and what fixes it.

The first three rows can be ruled out in a few minutes each, so they are the place to start. Low crawl demand is different, because it reflects how much Google wants to crawl the website rather than a fault that can be switched off.

Check the Sitemap Address and the Property

The first check is whether the address you submitted is the address where the sitemap lives. Open the exact URL from the Sitemaps report in a private browser window, character for character. A typo or an old filename left behind by a plugin change will return a 404 error, which Google reports as Couldn’t fetch.

The property matters as well. Search Console treats the http and https versions of a domain as separate properties, along with the versions with and without www. Submit the sitemap under the property that matches the address visitors see, using the full https URL rather than one that redirects to it.

A browser test also shows whether the file is a usable sitemap. The sitemap protocol requires the file to be UTF-8 encoded, with every URL written in full including the protocol. Watch for any of these in place of the XML.

• A login screen or a maintenance page
• An HTML error page or a redirect to the homepage
• An empty response or a sitemap that lists no URLs
• A security challenge asking the visitor to prove they are human

Each of these loads something in the browser while giving Google nothing it can read as a sitemap. The guide to what a sitemap is and how it works covers how the different sitemap files fit together.

Test the Sitemap With the URL Inspection Tool

The URL Inspection tool shows what Google receives when it requests the sitemap, which a browser test cannot. Google’s help page for the URL Inspection tool explains that a live test reports whether crawling is allowed and whether Google could get the page from your server. The Sitemaps report help recommends the same check for a sitemap URL that will not fetch.

A live test that fails while the browser loads the file cleanly points to something between Google and your server treating automated traffic differently. A live test that passes while the report still shows Couldn’t fetch usually means the status is out of date, which the section on resubmitting covers.

Look for Robots.txt Rules and Firewall Blocks

Robots.txt rules and firewalls are the two blocks that stop Google without affecting your own browser. Google respects robots.txt when it fetches sitemaps, so a Disallow rule covering the sitemap path stops the fetch even though the file opens normally for you. The introduction to robots.txt on Google Search Central explains what the file controls and where its limits lie.

Firewalls, CDN bot protection and WordPress security plugins are the quieter cause. They can challenge or block automated requests while serving people normally, which is why the browser test passes and the live test fails. Google’s guidance on verifying requests from Google crawlers explains how to confirm through a reverse DNS lookup or Google’s published IP ranges that a request really came from Google.

Server or CDN logs settle the question when the settings look correct. Look for requests to the sitemap URL from Googlebot and check the status code each one received, since a 403 error or a challenge page in place of the XML shows the block in action.

Fix Server Errors and Oversized Sitemap Files

Server errors and timeouts make a fetch fail even when nothing is blocking Google. Google’s documentation on HTTP status codes and network errors explains that a 5xx response or a 429 makes its crawlers slow down and that any content returned with a 5xx code is ignored. An overloaded server can therefore fail the sitemap request one day and pass it the next.

Large sitemaps built at the moment they are requested are a common source of timeouts, particularly on shared hosting. Each request makes WordPress query the database and assemble the file, so a sitemap listing thousands of URLs can take longer to generate than Google is prepared to wait. Hosting that drops out under load has the same effect, which is one reason WordPress hosting uptime matters for search as well as for visitors.

Size is the other limit to check. Google’s guidance to build and submit a sitemap limits a single sitemap to 50MB uncompressed or 50,000 URLs. Anything larger has to be split into several files.

A sitemap index file lists those smaller sitemaps so they can be submitted together. Smaller files are also quicker for a slow server to deliver, well before the size limit comes into play.

WordPress Settings and Plugins That Break Sitemaps

WordPress sitemaps fail in a few predictable ways, because the file is generated on request by WordPress core or by an SEO plugin. The WordPress core announcement of XML sitemaps explains that WordPress has published its own sitemap index since version 5.5, without any plugin. The same announcement confirms that sitemaps are switched off when the reading setting that discourages search engines from indexing the website is ticked, which is easy to leave behind after a development build goes live. The same setting is one of the first checks when a website is not showing up on Google at all.

SEO plugins usually replace the core sitemap with their own, often at /sitemap_index.xml. Problems start when two plugins generate sitemaps at the same time, when a plugin update changes the address or when the sitemap is switched off in the plugin settings. Submit the file that the active SEO plugin produces and remove old submissions that point at addresses which no longer exist.

Security plugins deserve a look at the same time, since some block requests that look automated or limit how often one visitor can request pages. Check their logs for blocked requests to the sitemap and add an exception for verified Googlebot traffic rather than switching the protection off.

Resubmit the Sitemap and Watch the Last Read Date

Once the cause is fixed, resubmit the sitemap in the Sitemaps report and judge success by the Last read date rather than the status on the day. Google retries a failed sitemap for a few days and then stops, so a sitemap that has been failing for a while will not be fetched again until it is resubmitted.

The Last read column only fills in when Google has fetched the file, which makes it a cleaner signal than the status label. Check it again over the following week. If it stays empty after a successful live test, return to the checks above and work through them again.

Submitting the same file under a new address, for example with a query string added, is a common workaround for a status that will not clear. It can prompt a fresh fetch, but it does nothing for a sitemap that is still blocked or failing, so it belongs after the fix rather than in place of it.

When the Error Keeps Coming Back

A Couldn’t fetch error that keeps returning usually points to the hosting or security setup rather than the sitemap itself. Intermittent server faults, bot protection that tightens after a traffic spike and sitemaps generated on underpowered servers all produce a file that works when you test it and fails when Google calls.

The pattern is the diagnosis, so note the dates the error appears and compare them with server logs for the same days. A guide to log file analysis for SEO shows how to read Googlebot requests and the responses they received, which turns an occasional error into a record of when and why it happened.

Recurring fetch problems rarely stop at the sitemap, because whatever turns Googlebot away there is usually affecting normal page crawling too. A wider review of common technical SEO issues is worth running once the sitemap is fixed, so the same fault does not resurface somewhere less visible.