Sitemap Could Not Be Read: Fix the General HTTP Error (2026)

"Sitemap could not be read" means Google fetched your sitemap URL and did not get usable XML back. Nine times out of ten the file is not broken at all: the URL returned a 404 after a CMS or theme change, the server answered with a 5xx while Googlebot happened to ask, a security layer or CDN challenged the bot, or robots.txt is blocking the path. The page loads perfectly in your browser, which is exactly why the error is so confusing. The fix is to request the sitemap the way a crawler does, read the status code you actually get back, and work from that.

Search Console words this error in a few different ways and they all land in the same place. You may see "Sitemap could not be read", "General HTTP error", "Couldn't fetch", or an HTTP error code next to the sitemap in the Sitemaps report. Google is telling you it tried, and it did not get a clean XML response at that address. It is not a judgment on your content, and on its own it does not deindex anything. What it does mean is that your discovery channel is switched off until you fix it, and on a large or fast-publishing site that gets expensive quietly.

What "sitemap could not be read" actually means

Google splits sitemap problems into two stages, and knowing which stage you are in narrows the search enormously.

Fetch stage. Google requests the sitemap URL. If it cannot get the file at all, you get "Couldn't fetch" or a general HTTP error. Nothing inside the file has even been looked at yet, so no amount of editing the XML will help.

Parse stage. Google got the file, but it could not read it as valid sitemap XML. This is where you see parsing errors, invalid dates, unsupported formats and "Invalid XML: too many tags". Here the file really is the problem.

"Sitemap could not be read" with a general HTTP error is a fetch-stage failure. That single distinction saves most people an hour of pointlessly reformatting XML that was fine all along.

The seven causes, in the order worth checking

How to fix it, step by step

1. Request the sitemap URL and read the status code. This is the whole diagnosis in one step and almost everyone skips it, because the browser shows the file and that feels like proof. It is not. Fetch the URL from a command line or an external checker and look at the raw status. A 200 with XML means Google's error was transient or something is answering crawlers differently. A 404, 403 or 500 tells you precisely what to fix.

2. Fetch it as Googlebot. If the browser gets 200 but the error persists, request the same URL with a Googlebot user agent from an IP outside your own network. When those two responses differ, you have found it: a WAF rule, a rate limiter, a country block, a "verify you are human" challenge, or a host-level bot filter is intercepting crawlers. Managed hosting and CDN bot protection are the usual culprits, and this is the single most common cause of a sitemap that "works fine" but cannot be read.

3. Check robots.txt. Read the live file at /robots.txt and look for any Disallow that matches the sitemap path. A disallowed sitemap simply cannot be fetched, and the error will never clear. While you are there, add a Sitemap: line pointing at the file, which is a supported way to advertise it to any crawler. Our robots.txt guide covers the syntax rules that decide which directive wins.

4. Confirm it is really XML. Open the raw response, not the browser's pretty rendering. You want a urlset or sitemapindex element and one loc per entry. If you see an HTML error page, a login form, a maintenance notice or a CDN challenge page, that is what Google received too.

5. Check the size and the entry count. A single sitemap is capped at 50,000 URLs or 50MB uncompressed. Past either limit you need to split the URLs across multiple files behind a sitemap index. Large catalogs cross this line without anyone noticing, usually right after a bulk import.

6. Look for unescaped characters. If the fetch is fine and the error is a parsing failure, a raw ampersand in a URL is the classic offender. Every tag value has to be entity escaped, and the file has to be UTF-8. One product URL with a query string can invalidate an otherwise perfect file.

7. Resubmit and give it time. Once the URL returns clean XML with a 200 to a crawler, resubmit it in the Sitemaps report. Google re-fetches on its own schedule, so the status may sit on the old error for a day or two before it updates. If nothing was actually wrong and the file has been fine for a week, the error was almost certainly a transient fetch failure that has already resolved.

Why the sitemap works in your browser but not for Google

This is the part that wastes the most time, so it is worth being explicit. Your browser request and Googlebot's request are not the same request. Yours comes from a residential or office IP that has visited the site before, carries browser headers and cookies, and often arrives from a country your firewall trusts. Googlebot's arrives from a Google IP range with a bot user agent and no session at all. Any rule that treats those differently, and bot protection exists precisely to treat them differently, can serve you a file and serve Google a challenge page.

The same mismatch shows up with staging protections left on after launch, IP allowlists, aggressive rate limits triggered by a crawler fetching many URLs quickly, and geo-blocking. In every case the sitemap file itself is perfect. The only reliable test is to make the request the way a crawler makes it and compare the two responses side by side.

Does this error hurt your rankings?

Not directly. A sitemap is a discovery aid, not a ranking factor, and Google can and does find pages through internal links, external links and previous crawls. Pages already in the index stay indexed while your sitemap is broken.

The damage is slower than that. New pages take longer to be discovered, and on a site publishing at any volume that delay compounds into real lost traffic. Updated pages get re-crawled later. And you lose the diagnostic value: the Sitemaps report is the only place that compares what you submitted against what Google discovered, so while the file cannot be read you are working blind. On a 200-page site that is an inconvenience. On a 40,000-URL catalog it is the difference between knowing your coverage and guessing at it.

Stopping it from happening again

Sitemap errors are almost always regressions from an unrelated change: a plugin update, a new firewall rule, a platform migration, a rewritten robots.txt. Three habits catch them early.

Check the sitemap URL like any other critical endpoint. Whatever monitoring you already run against your production URLs should include the sitemap, checked as a bot rather than a browser, alerting on anything that is not a 200 with XML.

Watch the URL count, not just the status. A sitemap that returns 200 but silently drops from 40,000 entries to 12 passes every uptime check while being completely broken. If the file is produced by a build step or a data pipeline, this is the same class of problem as any other dataset losing rows overnight, and the same volume and freshness anomaly checks that catch a broken pipeline will catch a broken sitemap. A simple assertion in your build that fails when the count moves more than a set percentage does the job too.

Verify the URLs inside, not just the file. The Sitemaps report going green tells you the XML parsed. It does not tell you whether the pages listed inside it are in the index, and that is the number that actually matters. Our XML sitemap checker reads the URLs in your sitemaps and returns a per-URL index status for Google and Bing, with a plain-English reason for each gap, then resubmits the missing pages through the official Indexing API and IndexNow. If you want the submission side handled on a schedule, the sitemap submission tool covers that too.

Frequently asked questions

Why does Google Search Console say my sitemap could not be read? Because Google requested the sitemap URL and did not receive valid XML with a 200 status. The usual causes are a 404 at the submitted address, a 5xx server error at the moment of the fetch, robots.txt blocking the path, or a firewall or CDN serving Googlebot a challenge page instead of the file. Check the status code a crawler receives, not what your browser shows.

What is a general HTTP error on a sitemap? It is Google's catch-all for a fetch that failed at the HTTP level, without a more specific code to report. Treat it as "I could not retrieve this file" rather than "your XML is wrong". Look at server logs, security rules and the response your host actually returns to bot user agents.

How long does it take for the error to clear? Once the URL returns clean XML, the status usually updates within a few days, on Google's own re-fetch schedule. Resubmitting in the Sitemaps report nudges it along. If the underlying problem was intermittent, it can clear on its own without any action.

Should I delete and resubmit the sitemap? Only after the URL genuinely returns valid XML with a 200. Removing and re-adding a sitemap that is still broken changes nothing and loses the historical data in the report. Fix the response first, resubmit second.

Can I have more than one sitemap? Yes, and on any site of size you should. Split URLs by content type across multiple files and reference them from a sitemap index, which keeps you under the 50,000 URL limit and makes it obvious which section of the site has a coverage problem instead of averaging it away.

If the file reads cleanly and pages still are not showing up, the problem has moved downstream from discovery into indexing itself. That is a different diagnosis, and why a page is not indexed walks through the reasons Google reports, while the page indexing report guide explains what each status in Search Console is really telling you.