Search Console: Sitemaps report
General HTTP error on a sitemap in Search Console
The Sitemaps report shows General HTTP error: Google got an HTTP error fetching the file that has no more specific message. How to find the code.
Google got an HTTP error fetching the sitemap that is not covered by a more specific message, and Google says a 404 can also show this way. Expand the details for the code, fetch the file with a sitemap validator to see what a crawler receives, fix the URL or the server response, then resubmit.
What "General HTTP error" means
Google: "Google encountered another HTTP error not covered by a more specific error listed here. Expand the details to see what kind of error occurred. This can also be caused by a 404 (page not present) error, which is a fetch error." A separate message, "HTTP error [specific code]", covers 400-level errors where Google shows the exact code.
Is it a problem?
Usually a problem
Yes. Until the file returns 200, Google cannot read it, and after a few days of failures it stops retrying.
Causes, most likely first
- The sitemap URL returns 404, often after a CMS or SEO plugin change renamed the file.
- A firewall, CDN or bot protection rule answering Googlebot with 403, 429 or 5xx while browsers get the file.
- An origin error or timeout while generating a large dynamic sitemap.
How to confirm it
- Expand the error details in the Sitemaps report for the code Google recorded.
- Run the sitemap validator on the submitted URL to see the status a crawler receives now.
- Run the crawler versus browser checker on the sitemap URL if a browser can open it but the report still fails.
How to fix it
- Correct the submitted URL, or restore the file at the URL you submitted.
- Allow verified Googlebot through whichever layer is answering with the error.
- For a slow generated sitemap, serve it from cache or split it with a sitemap index.
- Confirm a 200 with the sitemap validator and resubmit.
How long recovery takes
Google "will retry for a few days, and then stop if the sitemap continues to be unavailable". Resubmitting after the fix asks it to fetch again.
Would monitoring have caught it?
A sitemap that stops being fetchable, or whose URL count drops by more than half, is a warning on the next daily sitemap check, and the change history keeps the status and the count we saw. It reads the sitemap as our crawler receives it; it cannot see Google's crawl demand, a manual action, or what Search Console shows.
stillindexed reads each site's sitemap once every 24 hours on every plan, independently of Search Console.
Further reading
Related statuses
Sources
Every claim above about how Google behaves is from Google's own documentation, read on 2026-10-22. If Google has changed a page since, Google's page wins and we would like to know.
- https://support.google.com/webmasters/answer/7451001?hl=en
- https://developers.google.com/crawling/docs/troubleshooting/http-status-codes
- https://developers.google.com/crawling/docs/crawlers-fetchers/verify-google-requests
- https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap
Quotes from Google staff are as reported here, not from Google's documentation: