Fixing “Couldn’t Fetch” for Your Sitemap in Google Search Console

Google Search Console (GSC) shows this error on the Sitemaps page when Googlebot tried to request your sitemap URL and didn’t get back a valid, parseable response in time. It’s a GSC-side report about the last fetch attempt. It doesn’t necessarily mean the sitemap is broken right now. Work through the causes below in order. They’re listed by how often they turn out to be the actual cause.

Before You Start: Confirm the Sitemap Loads Right Now

Open the sitemap URL directly in a private/incognito browser tab:

https://yoursite.com/sitemap_index.xml

That’s the default URL. SureRank does not use /sitemap.xml or /surerank-sitemap.xml. (You can change the slug via the surerank_sitemap_slug filter, so if the customer says they customized it, use their real URL.)

• Loads and shows XML: the live sitemap is fine right now. The GSC error is most likely stale (Cause 1) or was a transient blip (Cause 2). Skip to the “Remove-and-Resubmit” procedure.
• 404: different bug, not “Couldn’t fetch.” Send the customer to [[Troubleshooting Sitemaps]] (“Sitemap Returns 404”) instead.
• Times out or 500s: continue to Cause 3/4.
• Loads but is empty: check the response headers (Cause 2) before assuming it’s broken. An empty index can be a normal, temporary “still building” response.

Cause 1: GSC Has the Wrong (or an Old) URL on File

The most common reason for a persistent “Couldn’t fetch” that never clears on its own and is fully within the customer’s control.

How it happens: SureRank redirects legacy/competitor sitemap URLs (/sitemap.xml, /wp-sitemap.xml, /index.xml) to the real sitemap URL with a 302. If a customer migrated from Yoast/Rank Math/SEOPress and GSC still has that old plugin’s URL submitted, every fetch now hits a redirect instead of the XML directly, a common source of “Couldn’t fetch.”

Fix:

1. In GSC → Sitemaps, check the exact URL submitted.
2. Compare it to the site’s actual sitemap URL.
3. If they don’t match: remove the old submission, then add the correct URL.

Cause 2: A Temporary “Cache Is Rebuilding” Response (Usually Not a Bug)

When SureRank’s sitemap cache is completely empty (right after activation, or after a full reset) and no stale backup exists, it deliberately serves an empty index with HTTP 503 and a Retry-After header (300s default), plus X-Robots-Tag: noindex, telling Googlebot “come back shortly” so it doesn’t start dropping indexed URLs mid-rebuild.

What this means: a single 503 that clears within a few hours is expected, not a defect. GSC’s status can lag the site’s real state by a day or more. Re-verify against the live URL first. If the 503 doesn’t clear after several hours, go to Cause 3.

Quick check: inspect the response headers of the sitemap URL. HTTP/1.1 503 plus Retry-After confirms this is the self-healing path.

Cause 3: The Site Can’t Reach Itself (Stalls the Rebuild)

If the cache never finishes rebuilding, the most common root cause is that the server can’t make a loopback request back to itself, which SureRank relies on to keep the cache current. If blocked, the rebuild falls back to a slower synchronous process; the sitemap still updates, but freshness may lag.

Usual blockers: a security plugin (Wordfence, iThemes Security, WP Ghost) renaming/restricting the admin path; a hosting firewall/WAF blocking self-requests; a host with loopbacks disabled outright.

How to check:

1. Tools → Site Health → Status in WP admin.
2. Look for the SureRank loopback test. A failure will call out a security plugin, firewall, or host-level restriction.
3. If flagged, this is a hosting/security-plugin config issue. Have the customer/host whitelist the site’s own admin-ajax path, or confirm loopbacks are enabled.

Cause 4: A Firewall/WAF Is Blocking Googlebot Specifically

(This is the manual WAF check support already does, codifying it here.) Different from Cause 3: the site can talk to itself fine, but an external firewall (Wordfence, Sucuri, Cloudflare Bot Fight Mode, or a hosting WAF) is blocking Google’s crawler from reaching the sitemap from outside. SureRank has no visibility into this. It’s entirely a hosting/security config matter.

How to check:

1. Check the firewall/security plugin’s block log (Wordfence Live Traffic, Sucuri firewall log, Cloudflare Security Events) for blocked requests with a Googlebot user agent or Google’s crawler IP ranges around the time of the fetch failure.
2. If Cloudflare is in front of the site: confirm Bot Fight Mode isn’t over-aggressive and no custom WAF rule matches the sitemap path.
3. Whitelist Googlebot’s user agent/IP ranges if a block is found.
4. There’s no SureRank-side fix here. The customer/host must adjust their own firewall.

Cause 5: robots.txt Is Blocking the Sitemap or the Site

Less common, but check if robots.txt was hand-edited:

1. Open /robots.txt, confirm no blanket Disallow: / (common leftover from staging-site copy-paste).
2. Confirm a Sitemap: the line points to the correct URL. SureRank only auto-adds this when no custom robots.txt content is saved. Customers with custom content are responsible for including it themselves.
3. Fix via SureRank → Advanced → Robots.txt Editor.

Pro-Specific Note: Video, News, and Author Sitemaps

These are separate modules with their own rewrite rules:

• Enabling/disabling one requires a permalinks flush, same as the core sitemap. Otherwise the URL 404s instead of erroring.
• They don’t share the core sitemap’s 503/retry self-healing. If their data hasn’t built yet, they typically return a valid-but-empty 200 rather than a retryable error, so “Couldn’t fetch” on these is more likely a URL/permalink issue or Cause 3/4 than a “still rebuilding” state.

Standard Remove-and-Resubmit Procedure

1. Confirm the live sitemap URL loads cleanly (200, valid XML).
2. In GSC → Sitemaps, remove the old/broken entry.
3. Submit the current, correct URL.
4. Set expectations: GSC re-fetches on its own schedule, typically 24 to 72 hours. Checking again within minutes will still show the old status.

When to Escalate

• Live sitemap returns a 500/fatal error (not 503). This is a bug, not expected rebuild behavior.
• Loopback passes, no WAF/firewall block found, robots.txt is clean, submitted URL is correct, but “Couldn’t fetch” persists across multiple days of GSC attempts.
• A Pro video/news/author sub-sitemap returns malformed (not just empty) XML.