Search Console Sitemap "Couldn't Fetch" Error: Causes and Fixes

What does the "sitemap couldn't fetch" error mean in Search Console, and what should you do first?

The sitemap couldn't fetch status means Google tried to download your sitemap file and failed. Common causes are a wrong address, a robots.txt rule, or a server that rejects Googlebot. Open the sitemap URL in a browser first, then test it with the URL Inspection tool.

So do not panic. A sitemap couldn't fetch status does not mean Google removed your site. It only says one file could not be read, so the rest of your site stays untouched. Your pages can still reach Google through links. Even so, fixing the cause helps new pages get noticed faster.

Follow this order:

1. First, open the full sitemap address in a private browser window and confirm you see XML.
2. Then, check that you selected the right Search Console property (http, https, www).
3. Next, read your robots.txt file and look for a rule that blocks the sitemap path.
4. After that, run a live test for the sitemap URL in the URL Inspection tool.
5. Also, check server or firewall logs for rejected Googlebot requests.
6. Finally, fix the cause, resubmit the sitemap, and give Google some time.

This article covers one error only. If you need the basics first, read our guide to XML sitemaps.

Is "sitemap couldn't fetch" the same as other sitemap statuses?

No, because each status points to a different problem. According to the official help page, the Sitemaps report shows a few main results. Success, Has errors, and Couldn't fetch. Google may also show an unclear state for files it has not processed yet.

The key difference is simple. With sitemap couldn't fetch, Google could not get the file at all. With Has errors, Google got the file but found problems inside it. So you fix access in the first case and content in the second.

However, interface wording can change over time. Therefore, if your panel shows a similar warning, follow the same steps. So do not rely on one exact label.

Also, what you see depends on your property type and your permission level. Focus on the meaning of the status, not on a screenshot you saw elsewhere.

How do the Sitemaps report statuses differ from each other?

The table below compares the main statuses and shows where to look first.

The fourth row is not one of the main statuses on the official page. You may see a similar message in the details, so do not rely on exact wording.

In practice, the first two rows need no access fix. The last two rows usually do. That is why you should identify the exact status before you change anything.

Should you wait if a new sitemap shows couldn't fetch?

Sometimes, yes. A freshly submitted file can show this status for a while. The official help page says short server problems may resolve on their own. So not every warning is a permanent failure.

Our field experience agrees. For example, sometimes the status turns to Success without any change on your side. However, this is an observation, not a rule, and nobody can promise how long it takes.

A sensible approach looks like this:

• First, confirm the file opens from your browser and from another network.
• Then wait a few days and check the report again.
• If nothing changes, stop waiting and rule out causes one by one.
• Do not delete and re-add the file again and again, because that only restarts the wait.

Also, Google may read a file late when a site is new or has thin content. The official page says higher quality content raises crawl demand. So patience is normal on a new site.

Does the sitemap URL open in a browser?

When you see sitemap couldn't fetch, this is the fastest and most valuable test. First, copy the exact address you submitted and open it in a private window. Instead of errors, you should see XML or a sitemap index. A blank page, an error, a login screen, or a normal web page means you found the problem.

Check these details in the address:

• The protocol must match, so do not mix http and https.
• Your www choice must match your Search Console property.
• The file name must match in upper and lower case.
• The address must not carry a stray space, quote, or line break.

Next, check redirects. A chain of redirects can stop Google from getting the file. Our redirect checker shows where an address leads and in how many steps.

Also test from a mobile network and ask a colleague to open it. This way, you remove local cache and network effects. Do not test while logged in as an admin, because some sites show admins one thing and Googlebot another.

Could robots.txt be blocking your sitemap?

Yes, it can. The official help page is clear: Google respects robots.txt when it fetches sitemaps. If a rule blocks the file, you must remove that rule.

The block is often indirect. For example, a broad rule that blocks a whole folder also covers the sitemap inside it. Some sites keep the sitemap in a plugin folder or a virtual path. So that path can fall under a rule too.

Check it in this order:

1. First, open your robots.txt file in a browser and read the Disallow lines.
2. Then, see whether your sitemap path starts with any blocked path.
3. Next, if it does, narrow the rule or allow the sitemap path as an exception.
4. Finally, after the change, confirm the new robots.txt is live.

We collected frequent mistakes in common robots.txt mistakes and fixes. If you need a fresh file, try the robots.txt generator.

Can the wrong property (http, https, www) cause a sitemap couldn't fetch status?

It rarely causes the error directly, but it creates confusion. Search Console treats http, https, www, and non-www versions as separate properties. A domain property covers all of them. A URL-prefix property covers only its own prefix.

For example, here is a scenario. Your property is https://www.example.com/. You submit https://example.com/sitemap.xml. That address may redirect, may not exist, or may return a different response. In the end, you sent Google an address it cannot use.

If you recently installed an SSL certificate or moved to a non-www version, this mistake is easy to make. As a result, the old sitemap address now leads somewhere else.

The fix is simple:

• Pick one preferred version of your site.
• Write every URL inside the sitemap with that version.
• Submit the sitemap address with the same version.
• Redirect the other versions permanently to the preferred one.

The official documentation also says Google expects fully qualified, absolute URLs. Relative paths, however, do not work. So keep the protocol and domain consistent inside the file.

Can a server or firewall block Googlebot from your sitemap?

Yes, and it is a common cause of a sitemap couldn't fetch report. A firewall, bot protection, or a very strict rate limit can reject Googlebot requests. You see the file in your browser, but Google gets a 403 or a similar response.

Typical signs are these:

• The file opens in your browser, yet Search Console says couldn't fetch.
• Server logs show 403, 429, or 5xx responses for Googlebot requests.
• The problem appears only at certain hours or under heavy traffic.
• You tightened bot protection rules recently.

First, verify that the request really comes from Googlebot, because fake bots use the same name. Our guide on how to verify Googlebot explains this step. Then allow the sitemap path for real Googlebot in your firewall.

For firewall-related 403 errors, see our ModSecurity and 403 errors guide. Also note that the official page says sitemaps are not read while an unresolved manual action exists. Therefore, check the manual actions report for that.

Why does the sitemap URL return a web page instead of XML?

Some sites return a normal HTML page at the sitemap address. You see something in the browser, but Google cannot read it as a sitemap. In the details you may see a similar warning.

The most common causes are these:

• The address redirects to a login page or the home page.
• A cache or optimization plugin also wraps the output.
• The sitemap plugin is off, so the server shows a 404 page.
• The server sends the error page with a 200 status code.
• You submitted a visitor-facing HTML sitemap page instead of an XML file.

The last point matters most, because many people confuse the two files. A sitemap page built for people is not the same as the XML file you submit. Google accepts XML, RSS, mRSS, Atom, or plain text files.

The official documentation also says the file must use UTF-8 encoding. Tag values must be escaped properly. Broken characters can stop Google from reading the file. That case, however, is closer to Has errors.

What happens when your sitemap is too large?

However, large files can cause trouble. The official documentation limits each sitemap to 50 MB uncompressed or 50,000 URLs. Limits can change over time, so check the current values on the official page.

If you exceed the limit, split the file into parts. Then list the parts in a sitemap index file. This way you submit one address and cover everything.

Watch for these signs on big files:

• The file takes very long to open in a browser.
• The server hits a memory or time limit and returns a partial response.
• The site builds the file again on every visit and runs slowly.

In addition, dynamic generation is risky. If the server times out while Googlebot fetches the file, you see couldn't fetch. Splitting the file and caching the output usually lowers the load.

As your page count grows, one big file gets harder to manage. Separate files for products, categories, and posts also show you which section has the problem. Our XML sitemap generator is a quick start for small sites.

Did you set up the sitemap index file correctly?

A sitemap index lists several sitemaps in one file. The official documentation says an index can list up to a fixed number of sitemaps, and a site can have more than one index file. Therefore, check the current limits on the official page.

Index mistakes also cause fetch problems:

• Child sitemap addresses inside the index return 404 or redirect.
• Child files are not in the same directory as the index, or lower.
• Child addresses mix http and https.
• A second index file sits inside the first one.

However, the location rule matters. Sitemaps listed in an index must be in the same directory as the index file, or lower in the hierarchy. Otherwise Google may treat them as out of scope.

To check, open the index and test every address inside it in a browser. If even one fails, then the real problem may be there. An index can look fine while a child file still fails.

How do you test the sitemap with the URL Inspection tool?

URL Inspection shows whether Googlebot can really reach an address. The official documentation points to this tool for fetch issues. Paste the sitemap address into the search bar and start a live test.

Look at these results:

1. First, could Googlebot reach the address, or did it get an access error?
2. Then, does robots.txt block the page?
3. Next, is the returned content the XML you expect, or a different page?
4. Finally, does the live result match what you see in the browser?

If the live test passes, the problem is probably temporary or left over from an old attempt. If it fails, however, the tool hints at the type of cause. Then return to the matching section and fix robots.txt, the server, or the redirect.

For a wider view of the tool, read what Google Search Console is and how to use it. The official URL Inspection help page gives more detail.

How do you resubmit the sitemap after fixing the problem?

First, make sure you really fixed the cause. The address should open in the browser, URL Inspection should pass, and the robots.txt block should be gone. Only then resubmit the file in the Sitemaps section.

Follow these steps:

1. First, open the right property in Search Console and go to the sitemaps screen.
2. Then, check that the sitemap address did not change.
3. Next, submit the same address again, or add the new address if it changed.
4. After that, check the status again after a few days.
5. Finally, if nothing changes, read the detail row, because it may come from an old attempt.

Submitting the same file many times in a row does not help. That happens because Google reads the file on its own schedule. So fixing the cause and waiting is more efficient than resubmitting.

After success, also keep the file fresh. To set modified dates correctly, read our guide on the sitemap lastmod tag.

Which causes are most common on WordPress and other CMS platforms?

On most sites, a plugin or a CMS feature builds the sitemap. So most problems start in plugin settings. Here is an example scenario: you update the plugin, the permalink structure changes, and the old sitemap address starts returning 404.

The table below groups frequent causes.

If the address returns a 500 error, your site may have a wider PHP problem. In that case, our guide on the WordPress critical error message helps.

Before you change anything, find the exact plugin that causes the issue. Still, turning off one plugin and retesting is often enough.

Why are pages still not indexed after the sitemap error is fixed?

A successful sitemap read does not guarantee that every page gets indexed. In other words, a sitemap only gives Google a hint. Choosing which pages to index is a separate decision.

Common reasons pages stay pending after success:

• The content is thin or very similar to other pages.
• The page has a noindex tag or a wrong canonical address.
• No internal links point to the page, so crawl priority stays low.
• The site is new, so crawl demand is still low.

We cover this in a separate guide, how to find unindexed pages in Search Console. It explains each status, so we do not repeat it here.

What matters is the order. Google reads the sitemap first, then crawls pages, and finally decides on indexing. If you fixed the first link in this chain, inspect the next links one by one.

Which wrong fixes should you avoid?

Under stress, people often rush, so they make things worse. Some moves do not solve the problem and may even make it worse. Avoid these mistakes.

• Deleting and re-adding the same file many times in one day.
• Switching off the firewall completely. Instead, add a narrow exception for real Googlebot.
• Deleting all rules in robots.txt. Find the wrong rule and fix it.
• Moving the sitemap to another domain to dodge the problem.
• Trusting anyone who sells instant indexing for money.

The last one, however, is especially risky. Nobody can guarantee when Google reads a file. Such promises often rely on methods that break the rules and can hurt your site.

Instead, the right approach is to find the cause with evidence. First comes the browser test, then URL Inspection, then server logs. Each step also rules something out. It feels slow, but in the long run it is the fastest path.

When should you ask an expert for help?

If you tried the steps above and nothing changed, an outside view can help. This is especially true because you may not have access when you cannot reach server logs, firewall rules, or redirect chains. A technical review then saves time.

Consider help in these cases, for example:

• The sitemap has shown couldn't fetch for weeks.
• You suspect a server or firewall rule that blocks Googlebot.
• Your setup has many languages or subdomains.
• The problem started right after a big migration of domain, CMS, or protocol.

As Talha Aslan and team, we handle such technical checks routinely. We give no guarantees, because we cannot control when Google reads the file. However, we have a systematic method to find the cause and apply the right fix.

You can look at our SEO consulting service for technical audits and monitoring.

What checklist keeps this error from coming back?

In short, prevention is cheaper than repair. A short check before you publish the sitemap and after every big change is enough. This list turns the check into a routine.

1. First, open the sitemap address in a private window and confirm you see XML.
2. Then, write every URL inside with your preferred protocol and domain.
3. Next, confirm robots.txt does not block the sitemap path.
4. After that, confirm your firewall lets real Googlebot reach the sitemap.
5. Also, compare file size and URL count with the official limits, and use an index file if needed.
6. Then, select the right property in Search Console and submit the sitemap from it.
7. Finally, make sure the sitemap refreshes automatically as the site changes.

Run this list monthly, and also run it after changes. Moreover, run it again right after a design, CMS, or hosting change.

Finally, keep a short note about the cause you found and the fix you applied. If the problem returns, you do not start from zero.

Note: this article is general information. Search Console screens and official rules can change, so always verify. Always check current wording on the Sitemaps report help page and the sitemap build documentation. For index file rules, see the large sitemaps page.