Sitemap "Couldn't Fetch" in GSC: Diagnose Before Panicking
A red "Couldn't fetch" status in GSC does not mean your sitemap is 404. Here is the server-side diagnosis order.
TL;DR
Status "Couldn't fetch" di GSC bikin panik, padahal pengecekan manual via curl membuktikan semua 147 URL sitemap mengembalikan HTTP 200. Cloudflare juga bersih karena log Security Events hanya mencatat request yang diblokir, bukan yang lolos. Sesuai dokumentasi Google, pesan itu cuma berarti fetch terakhir gagal alias antrian crawler, jadi cukup tunggu beberapa hari sebelum cek ulang.
That afternoon, on September 3, 2026, I opened Google Search Console to check on the blog. My eyes locked onto one line that made my heart skip: the sitemap https://adityo.web.id/sitemap.xml had a glaring red status saying "Couldn't fetch".
The first assumption is always the cliché: the sitemap is 404, or the server is down. Rather than overthinking, dissect it from the server side.
Server autopsy: from curl to 147 URLs
First step, check the HTTP status of the main sitemap with curl.
curl -sS -o /dev/null -w "%{http_code} %{content_type}\n" https://adityo.web.id/sitemap.xmlResult: 200 application/xml. The sitemap is alive, containing a valid sitemap index pointing to two child sitemaps (pages.xml and articles-1.xml). Both children also returned HTTP 200.
To be extra sure, I checked all 147 URLs inside the sitemap with parallel HEAD requests:
grep -oE '<loc>([^<]+)' sitemap.xml | sed 's/<loc>//' | xargs -P 10 -n 1 curl -I -sS -o /dev/null -w "%{http_code} %{url}\n"The result? Zero non-200s. All 147 URLs healthy.
I also refetched with the Googlebot User-Agent, python-requests, even a generic checker. All returned 200. Cloudflare blocked nothing. When I checked the Cloudflare Security Events log, the only request to /sitemap.xml that appeared was my own curl request, and its status was "Not mitigated" (meaning it passed, not blocked).
The "Couldn't fetch" mystery and Google's queue
If the file is healthy from every angle, why did GSC say it couldn't fetch it?
According to Google's official documentation on the Sitemaps report, the message "Couldn't fetch: Google couldn't fetch the sitemap" purely means Google failed to pull the data at the time of their last attempt. It is not a verdict that your file is 404.
Google does write that "The sitemap should be fetched immediately. However, it can take some time to crawl the URLs listed in a sitemap". If the first fetch fails (a timeout, or a crowded crawler queue), Google retries over the next few days.
One thing that often surprises people, from the Google crawlers overview: "Google egresses primarily from IP addresses in the United States". So if your server access log shows many requests from US IP addresses, don't panic about a foreign bot attack. That is purely Googlebot.
The fastest way to make sure your sitemap is truly readable by Google: use URL Inspection in GSC, enter the sitemap URL, click Test live URL. If the result is green, the issue is purely queueing.
When to suspect Cloudflare
So when should we start investigating the firewall or Cloudflare side? The answer: when there is authentic proof (say, from the server access log) that requests with the Googlebot User-Agent return 403 or 5xx.
If you open the Security Events dashboard in Cloudflare, remember that it only shows requests that were actioned or flagged by their security products. For free plan users, log retention is only the last 24 hours, using sampled logs.
Which means: if you see no events there, that does not mean Google never came. It means Googlebot's requests passed (not blocked, not challenged), so nothing was recorded.
That afternoon's diagnosis ended with one decision: wait. The sitemap is healthy, the server is fine, Cloudflare is not in the way.
If you hit the same thing, don't panic and don't resubmit the sitemap repeatedly on the same day. Forcing a resubmit does not cut the crawler queue. Give it a few days, then check again. If after a week the status is still red and Test live URL fails too, then dig deeper. Until then, let Google work through its queue.