Couldn't fetch: troubleshoot your sitemap in GSC
Read the conclusion first
For ‘Couldn't fetch’, first identify the exact file Google tried to read and what was delivered. Separate network/access failure from XML parsing failure. A browser's 200 response can still contain a challenge or HTML error; repeated submission does not repair either problem.
Applicable conditions
Applies to could not fetch, parse failures, and CDN protection blocks.
Before you open the report
The final sitemap response, content type, raw body and any firewall or challenge behavior.
Use one concrete URL or report first. Keep account credentials and private visitor data out of shared notes.
Steps and verification
Inspect the submitted address and response
Copy the complete sitemap address from native GSC, including its property prefix. Fetch that address without login and retain time, status, redirects, final URL, headers and body. If it is an index, test the child file named in the error too.
Confirm you obtained the expected sitemap rather than an application fallback, login form or CDN challenge. If no XML arrived, investigate routing and access first. If XML arrived but is malformed, preserve the parser error and fix its generation source.
Investigate Google's access using real evidence
Use available native live-fetch evidence and the server/CDN logs around the reported failure. Check robots restrictions and security rules for this file. Verify crawler identity when attributing a log request to Google; merely spoofing a Googlebot user agent does not establish Google's actual access.
A browser, Inspection Tool and crawler may take different paths through protection rules. Keep that distinction in the record. Correct the verified narrow rule or routing fault without disabling site-wide protection, and retest both the sitemap and ordinary public/private routes.
Resubmit the repaired file and track reading
After the exact address delivers valid content and access checks pass, submit the repaired sitemap where appropriate. Record the next processing timestamp, status and error text. A remaining old error is not proof that Google tested the new version.
Keep file availability, Google read success and listed-page indexing as separate outcomes. If reading still fails, compare new evidence with the original fault rather than changing filenames repeatedly. Finish with the failing layer, fix and observed processing state, including any state not yet confirmed.
Common mistake: Treat inability to crawl as a format issue
First determine whether the XML was actually retrieved, then decide whether to fix format or network access.
How to decide when you encounter different situations
Match your actual observation to a row before changing the page. If it does not match, collect the missing evidence first.
| What you see | Next step | How to confirm |
|---|---|---|
| 200 returns a challenge page | Check protection rules and actual body content | Confirm Google can read the XML |
| 404 or incorrect redirect | Correct the deployment path | Final response is correct |
| XML fixed but report unchanged | Record time and observe | Do not repeatedly rename and bombard submissions |
A 200 response can still contain the wrong document
Teaching scenario. Names, URLs and numbers illustrate the method; they are not customer or measured site results.
- What you observe
- Example: /sitemap.xml returns 200, but the body is an HTML login or security challenge rather than XML.
- What it establishes
- HTTP success confirms transport only. It does not establish a parseable sitemap or that Google received the same response.
- What to do next
- Fetch the exact public URL and inspect the root XML element and loc values. Diagnose the responsible routing or protection rule; avoid disabling site-wide security just to fix one public document.
What counts as a checked result
Confirm a valid XML body and correct final URL after deployment. Record Google’s later fetch state separately; a local parser cannot prove Google access.
If a required check fails, keep the error and return to the matching decision branch. A blank record means unverified, not passed.
Leave with a checked result, not another vague instruction
- Your deliverable
- A precise failure-layer record and a retest of the same repaired file.
- Stop and resolve this first
- Do not disable the whole site’s protection without evidence of the affected rule.
Record missing evidence in the worksheet below. An unresolved test is useful information; a blank field is not a pass.
Checklist for this page
Fill in your own check results, then decide the next step. Blank means not yet verified, not normal. Content is saved only in the current local session and is not submitted to the server or AI.
Frequently asked questions
Can I finish after passing a browser test?
No, also verify the actual read status in GSC.
Should I resubmit repeatedly while the old error remains?
First confirm the actual response is repaired, record the time, and inspect the detailed error. Repeating unchanged submissions is not diagnosis.
Official materials and usage boundaries
This page provides operational judgment and checking methods, and does not show customer success cases. Calculation examples and request samples are teaching materials, not actual website metrics. Google's reports, conditions, and interfaces may change; please refer to the current official documentation.
Read the corresponding Google official documentationContinue with the relevant tool
Once the sitemap URL responds, inspect the returned XML with this tool. A successful local parse cannot prove that Google can fetch that URL.
See how it works →