For twenty-five days, Google Search Console showed the same three words next to my sitemap: Couldn't fetch. No last-read date, no error detail — just a status that never changed. The site is a plain GitHub Pages site with 289 URLs, and I'd done the obvious things wrong exactly zero times: every URL returned HTTP 200, nothing was noindex, the XML validated. Bing, handed the identical file, crawled it without complaint. So the problem was never the sitemap — it was one crawler's relationship with one host, which is a different kind of debugging than fixing your own code.
"Couldn't fetch" with a blank last-read date is a specific state, not a generic error: Google has your sitemap URL on file but has never completed a successful fetch-and-parse. It isn't "3 invalid URLs" (that reports as a parse result with a count). It's the null state — registered, never processed — and on GitHub Pages it's sticky. Mine sat there 25 days across several resubmits. The GitHub community forums have people watching it far longer: a 2026 thread stuck for months, older reports past a year, all on sites with nothing wrong.
Rule your own site out completely, so you stop chasing a bug that isn't there. The audit is mechanical:
noindex. Check the X-Robots-Tag header and <meta name="robots">. One stray noindex explains a lot.<link rel="canonical"> self-referential, not accidentally aimed at another origin.sitemap.xml with a plain client: 200, served as XML, actually parses.Mine came back 289 URLs, zero noindex, zero canonical mismatches, all valid. That earns you the right to stop suspecting yourself — the problem is downstream of your site, not in your bytes.
Search Console's Crawl Stats report (Settings → Crawl stats) is the most under-read page in the console. Three signals:
The synthesis: a new site, essentially no backlinks, on a shared host that once hiccuped, visited rarely by a low-trust crawler. That's a low-crawl-budget profile — a links-and-time fix, not a config bug.
This is what turns panic into patience: it's the platform, not you. Every *.github.io site shares IP space and crawl infrastructure across a huge number of repos, and "Couldn't fetch" recurs on new-but-healthy Pages sites. The GitHub community discussions carry running threads on exactly this — one from 2026 stuck for months, an older one pairing the symptom with the workaround below — plus a Google Search Central help thread. The consistent shape: the site is fine, Bing is fine, and Google's sitemap fetch is stuck for reasons no one outside Google can resolve. So stop trying to force the sitemap, and route around it.
The single most useful fact here: indexing does not require the sitemap. A sitemap is a hint for bulk URL discovery, not the gate to the index. Google will index a URL it found via a link, or one you hand it directly, regardless of the sitemap.
The proof was in my own coverage report: of 289 URLs, Google had recognized just 11 — 7 already indexed (each discovered through a link, since the sitemap was never read once) and 4 crawled but not yet indexed. Link discovery was working — just slowly.
To push it directly, use the URL Inspection tool's Request indexing button: paste a URL, Google live-fetches, and an indexable page drops into a priority crawl queue — independently of the stuck sitemap. The catch is a quota of roughly ~10 requests per property per day. Tiny against 289 pages, but you don't need them all at once. And it's documented in the same thread as the problem: a user in the identical state made about 11 requests a day and got 200+ pages indexed while the sitemap never recovered. The playbook:
The reframe: separate the channel you can't control (sitemap fetch) from the one you can (manual requests + links), and stop letting the broken one hold the working one hostage.
JobPosting and BroadcastEvent (livestream) structured data — not general web pages. Pointing it at notes or blog posts is off-label; Google won't honor it, and the integration is wasted effort.google.com/ping?sitemap=... to force a re-fetch was removed in 2023 — Google no longer processes those pings and the endpoint is gone. Any tutorial telling you to ping your sitemap is out of date. Resubmitting in Search Console is the only supported signal, and it won't unstick "Couldn't fetch" any faster.Neither applies. The supported path is manual requests plus patience — and, if it persists, a structural move off the shared github.io infrastructure onto a custom domain, which has un-stuck sitemap fetches for others (at the cost of a 301/canonical migration).
The Google/Bing split matters more than a normal SEO writeup would tell you: in 2026 the engine that indexes you increasingly decides which AI assistants can cite you, and the two ecosystems are asymmetric.
So the order of operations flips from the old SEO instinct. Bing is the cheap, fast lane to AI citations; Google is the gated one you unlock slowly through manual requests and links. Honest caveat: Bing read my sitemap once then went quiet — its re-crawl cadence is slow, so a frequently-updated site wants IndexNow (which Bing supports) for freshness. But if your goal is to be quoted by assistants, not just ranked, getting cleanly into Bing is worth as much as fighting Google's sitemap — so check Bing's AI reports before concluding you're invisible.
When Google shows "Couldn't fetch" on a GitHub Pages (or any low-authority) sitemap:
noindex, canonicals correct, XML valid and reachable.The sitemap will likely un-stick on its own eventually, or after a move to a custom domain. Until then, the site gets indexed anyway — because a sitemap was always a hint, and the index was never waiting on it.
Q. Why does Google say "Couldn't fetch" for a GitHub Pages sitemap when every URL returns HTTP 200?
Because that status, with a blank last-read date, is a null state — the sitemap is on file but was never successfully fetched-and-parsed — not a verdict on the URLs inside. On GitHub Pages it's a common pattern that lasts weeks or months on perfectly healthy sites: a transient host hiccup at submission time can poison the first fetch, and the shared github.io infrastructure plus a new site's low crawl budget stop Google retrying cleanly. Nothing in your sitemap causes it.
Q. My GitHub Pages sitemap says "Couldn't fetch" in Google but Bing crawls it fine — is my site broken?
No. Bing crawling the identical file is strong evidence the file and server are fine — the problem is specific to Google's fetch state for that property. Audit to be sure (every URL 200, no noindex, canonicals correct, valid reachable XML); if that's green, it's downstream in Google's crawler, not your bytes.
Q. How do I get GitHub Pages indexed when Google won't read the sitemap?
Use the URL Inspection tool's "Request indexing" button — it hands a URL to Google's priority crawl queue independently of the sitemap. The quota is ~10 per property per day, so request your hubs first (homepage, section indexes) and let their links seed the rest, then spend the quota on your best pages a few a day. It's proven: people in the same state have indexed 200+ pages this way while the sitemap stayed stuck.
Q. Does the Google Indexing API work for regular GitHub Pages content?
No. The Indexing API only covers JobPosting and BroadcastEvent (livestream) data, not general pages, so it's off-label for blog posts or notes and Google won't honor it. Sitemap "ping" URLs are dead too — removed in 2023. The only supported nudges are resubmitting in Search Console (no faster) and manual "Request indexing."
Q. Why does it matter that Bing indexes me if Google won't — isn't Google all that counts?
For AI search, a lot. Bing's index feeds Microsoft Copilot and part of ChatGPT's web results, so Bing can get you cited fast — my first pickup was four Copilot citations via Bing, no Google involved. Google indexing is a necessary condition for Google's own AI surfaces (AI Overviews, Gemini): if it can't crawl you, you're not eligible. A stuck Google sitemap doesn't mean nothing works — Bing may be citing you already.