The “Sitemap Couldn’t Fetch” status in Google Search Console looks alarming, but most of the time it points to something small: a wrong URL, a redirect, a sitemap that does not exist yet, or simply a status Google has not finished processing. The exotic server problems people chase are rarely the cause.
Here is what the message actually means, the handful of causes that explain almost every case, and exactly how to fix each one (including the times when the right move is to wait).
Key Takeaways
- “Couldn’t fetch” means Google could not access or read the file at the sitemap URL you submitted, not that your site is broken.
- The most common cause is a wrong or redirected URL: submitting sitemap.xml when your real one is sitemap_index.xml, or a http to https redirect on the path.
- “Couldn’t fetch” is often just a pending status; Google frequently re-fetches and flips it to Success within a day or two with no action from you.
- Only dig into robots.txt, server, or SSL issues once you have confirmed the sitemap opens correctly in a browser.
What “Sitemap couldn’t fetch” actually means
When Search Console shows this status, it is saying that Googlebot tried to download the file at the exact URL you submitted and did not get back a clean, valid XML sitemap. That is the whole message. It does not mean your pages are deindexed, your site is penalised, or your content is invisible; it means one request to one file did not succeed.
This matters because the fix depends entirely on why that request failed, and the reasons fall into a short, predictable list. Work through them in order of likelihood and you will solve it far faster than by jumping to server logs and packet captures.
What causes the Sitemap Couldn’t Fetch error
Before anything else, open the submitted URL in a private browser tab. If a valid XML sitemap loads, the file is fine and the problem is either the URL you gave Google or simple timing. If it does not load, you have found your cause already.
1. The wrong URL or a redirect on the path
This is the cause I see most. On WordPress, the real sitemap usually lives at sitemap_index.xml (the path your SEO plugin generates), not the plain sitemap.xml a lot of people type from habit. Submit the wrong path and Google fetches a 404, which reads as “couldn’t fetch.” The same thing happens when the path redirects, for example submitting the http version when the site forces https, or a www to non-www redirect; Google does not always follow the hop the way a browser does, so give it the final, canonical URL.
2. The sitemap does not exist yet
Sometimes there is simply no sitemap to fetch. A fresh install with no SEO plugin, or a plugin whose sitemap feature is switched off, leaves nothing at the URL. Confirm one exists by visiting it directly; if it does not, generate one with your SEO plugin (or build a sitemap manually for a small or custom site), then submit that real URL.
3. The sitemap is served as HTML, not XML
If your URL returns a styled page or an error page instead of raw XML, Google rejects it. This often shows up as a separate “appears to be an HTML page” message, which I cover in detail in this guide to that exact error. The usual culprits are a caching or security plugin intercepting the request, or a redirect landing on a normal page.
4. robots.txt or server access is blocking Googlebot
Less often, the file exists and loads for you but Googlebot is being turned away. Check that your robots.txt does not disallow the sitemap path, and that a firewall or security plugin is not blocking Google’s crawler. A clean fix is to add a Sitemap: line to robots.txt pointing at the full URL, which also helps Google find it. Genuine SSL or server-timeout problems sit at the bottom of this list precisely because they are the rarest, so only investigate them after the four above are ruled out.
5. The fetch is simply pending
This one frustrates people the most. “Couldn’t fetch” is frequently a temporary state right after submission; Google queues the sitemap, has not fetched it yet, and shows the status in the meantime. If the file loads cleanly in a browser and the URL is correct, the honest answer is to wait, because it often flips to Success within a day or two on its own.
Match the symptom to the cause (diagnostic table)
| What you see | Likely cause | What to do |
|---|---|---|
| URL opens as valid XML for you | Wrong URL given to Google, or just pending | Submit the canonical URL (often sitemap_index.xml); otherwise wait a day or two |
| URL shows a 404 | No sitemap there, or wrong path | Generate the sitemap and submit the correct URL |
| URL shows a styled page | Served as HTML, plugin or redirect interfering | Disable the interfering plugin rule; serve raw XML |
| Loads for you, fails for Google | robots.txt or firewall blocking Googlebot | Allow the path; add a Sitemap line to robots.txt |
How to fix Sitemap Couldn’t Fetch, step by step
Run these in order and stop at the one that resolves it. First, open the submitted URL in a private tab and confirm a valid XML sitemap loads. Second, check the path is the canonical one with no redirect, and re-submit the exact final URL in Search Console. Third, if the file does not load or shows a page, generate a proper sitemap and clear any caching or security rule sitting on that path.
Fourth, confirm robots.txt allows the path and add the Sitemap: directive. Finally, if everything checks out and the file is clearly valid, give Google a day or two before touching anything else; re-submitting repeatedly does not speed it up. You can sanity-check the file structure against the official sitemaps.org protocol and Google’s own guidance on building and submitting sitemaps.
So how worried should you be about “couldn’t fetch”?
In my experience, most of the time, not very. When the sitemap opens cleanly in a browser and the URL is right, this status is almost always a wrong path or a pending fetch, and both clear quickly. The cases that need real troubleshooting, blocked crawlers, broken SSL, plugins serving HTML, are the minority, and they announce themselves the moment you open the URL yourself.
So resist the urge to overhaul your server over one status line. Verify the file, give Google the exact canonical URL, and only escalate if the URL itself is genuinely failing. That order will save you a lot of wasted effort.
Update Logs
02 Jul 2026
- Clarified the section headings so each names its subject and is clear on its own.
28 Jun 2026
- Reworked the guide around the causes that actually explain most cases, added a diagnostic table, and made clear when the status simply clears on its own.
Want our posts to show up more often on Google?
One step & Google will surface this site in your Top Stories.
