If Google Search Console says your sitemap “Couldn’t fetch”, start with the sitemap file itself. Rewriting your service pages or submitting every URL again will not tell you why that request failed.
Google’s Sitemaps report guidance separates retrieval failures from errors processing a fetched file.
For a business launching a new product range or adding important service pages, the useful questions are straightforward: can Google retrieve the current sitemap, does it contain the right URLs, and what happens to those pages afterwards?
First, separate sitemap access from page indexing
A sitemap helps search engines discover pages. It is not an instruction to rank them, and a failed sitemap request does not establish that every page has disappeared from Google. Google can also discover pages through links. Its sitemap introduction explains both the discovery benefit and the limits: inclusion does not guarantee crawling or indexing.
Keep three checks separate:
- Retrieval: can Google obtain the sitemap file?
- Processing: can it read the file and extract the URLs?
- Page indexing: what does Google do with an individual URL?
Work through them in that order. Otherwise, you risk fixing page content while the website is still returning the wrong file.
1. Record the exact failure before changing anything
Open the affected sitemap’s details in Search Console. Record the submitted address, status, last-read date where shown, and expanded error.
Also note when the problem first appeared. Compare that with website releases, a change of SEO plugin, hosting moves and security-rule changes. This is a way to narrow the investigation, rather than evidence that the most recent change caused the fault.
Ask whoever manages the site to confirm the sitemap address currently produced by its software. Avoid guessing a familiar filename or copying an address from the previous website. Keep a copy of the original error so that everyone tests the same URL.
2. Check the response, not just what your browser displays
Open that exact address while signed out of the website. If it redirects, record the destination. Then ask your developer or hosting provider to check the HTTP status and actual response body.
Google’s current HTTP status documentation explains why the response matters: content returned with most 4xx errors is not processed, while 429 and 5xx responses signal server trouble. A successful status alone is not proof that the correct content was supplied.
| Response observed | Next check |
|---|---|
| 404 Not found | Confirm the current sitemap address and whether the website generates that file. |
| 401 or 403 | Ask which authentication or access rule rejected the request. |
| 429 or 5xx | Ask the host to investigate request limits, availability and failures at the recorded time. |
| 200 with a login, challenge or ordinary webpage | Trace why the sitemap request receives that content instead of the sitemap. |
Send the host the complete URL and the time of your test, including the time zone. Request the response evidence and the rule or application responsible. “It opens for us” leaves the original failure unexplained.
3. Test current access through Search Console
Google recommends live URL inspection for sitemap fetch errors. In the availability details, look for Crawl allowed? Yes and Page fetch: Successful.
Use the live test deliberately. The initial inspection result shows Google’s stored information, whereas the live test checks the current response. Google’s URL Inspection documentation also explains that a successful live test does not guarantee indexing or cover every indexing condition.
If the browser check succeeds but the live fetch fails, ask the host to correlate the test time with its access and security logs. Keep the repair targeted to the demonstrated cause. Replacing several plugins or removing site-wide protections makes it harder to establish which change helped.
4. Check robots.txt and access restrictions separately
Review the robots.txt file on the affected website host. Under Google’s robots.txt rules, a Sitemap entry identifies the file’s full address; it does not override a rule disallowing access. Rules also have a defined scope based on the host, protocol and port.
Ask your developer to check the rules that apply to the exact sitemap path and relevant crawler. Correct a confirmed block narrowly. Do not replace the whole file with an unrestricted version simply to make the error disappear.
Login requirements and hosting security controls need their own investigation; changing robots.txt does not resolve those restrictions. Also check Search Console’s Manual actions report: Google lists an unresolved manual action among the reasons it will not read sitemaps.
5. If the file is fetched, investigate XML errors
Once retrieval works, move to the reported processing error. For an XML sitemap, the Sitemaps protocol specifies the structure, namespace, UTF-8 encoding and escaping of data values. A file can look readable to a person while failing those requirements.
Ask the developer to validate the response actually served publicly, including any line and column identified in the error. Check for an HTML error page, application warnings mixed into XML, malformed entries or an incorrectly escaped character. If a sitemap index points to several child files, test the affected child as well.
Repair the generator or response responsible. A manually corrected download is useful for diagnosis, but it does not prove that the website will serve a valid version after the next product import or content update.
6. Check that the repaired sitemap contains useful URLs
Take a small sample from the sitemap: an established service page, a recent addition and, for a shop, a newly published product. Confirm that these are the public addresses you intend customers to find.
Google’s current sitemap construction guidance calls for complete, absolute URLs and the preferred canonical versions. It also limits each sitemap to 50,000 URLs or 50 MB uncompressed; larger collections need splitting. Where last-modified dates are supplied, they should reflect significant updates accurately.
For example, a retailer might restore access successfully but discover that the product sitemap still contains addresses from its previous catalogue. Fixing retrieval and fixing that list are separate jobs. Test both before calling the work complete. If the new range is present in the file but absent from Search, stop treating the sitemap as the only suspect. Give your SEO specialist the affected product URLs and their inspection results, so the next investigation addresses those pages.
If the page is accessible but Google chooses another canonical, move to our guide to Google choosing a different canonical. Repeated sitemap submissions will not explain that separate decision.
7. Verify the repair and leave a clear handover
Fix and resubmit a persistently failing sitemap. Google retries failures but can eventually stop; check the later result.
Ask for a short completion record containing:
- The original error and the cause supported by the investigation.
- The public sitemap URL and evidence of the corrected response.
- The successful fetch or processing result, with its date.
- A sample of important URLs confirmed in the file.
- An owner and next review date for any remaining page-indexing issues.
For individual pages needing follow-up, use URL Inspection. Google’s recrawl guidance says crawling can take days to weeks, repeated requests do not accelerate it, and a request does not guarantee inclusion.
The commercial priority is to restore a dependable discovery route, then investigate the pages that matter to enquiries and sales. If you need help joining up the website, hosting and Search Console evidence, talk to BuzzBoost about a technical SEO review.
Featured image: AI-generated editorial artwork, not a photograph of a real BuzzBoost office, client or result.
