"Sitemap could not be read" and "Couldn't fetch": causes and fixes

An unread sitemap removes one of the main ways Google discovers new and updated URLs, for search and for the AI answers built on its index. This guide covers Google's definitions, the causes, how to confirm them, commands we ran to validate a live sitemap, the fix, and when to push URLs.

What does "Sitemap could not be read" mean?

"Sitemap could not be read" means Google's last attempt to fetch your sitemap file failed, so it read no URLs from it. As of October 2026, Google's Sitemaps report help gives three top-level statuses: "Success: The sitemap was fetched and read without any errors", "Couldn't fetch: Google couldn't fetch the sitemap", and "Sitemap had X errors: The sitemap could be fetched and partially read, but encountered some errors" (Sitemaps report help).

The wording differs between the report table and the details page:

Google's advice for the fetch failure is: "Try to fix the problem and resubmit the sitemap to the report." The report only tracks sitemaps submitted there or through the API, in the current property, so if one is missing, Google says to check "you're not confusing http/https, or www/non-www properties."

Is "Couldn't fetch" a problem?

"Couldn't fetch" matters most when the sitemap is how Google finds pages that few others link to, and it gets worse because Google stops trying: "If a sitemap fetch fails, either from the first request or after a later scheduled recrawl, Google will retry for a few days, and then stop if the sitemap continues to be unavailable or has critical errors."

Two things soften it:

• Earlier reads still count. Google says "A later failure or success to read a sitemap will not cause Google to "forget" the information from previous reads."
• Small and hosted sites may not need one. Google's help says a site of "about 500 pages or fewer" where every page is reachable by links "probably don't need a sitemap", and that hosts "such as Squarespace or Wix" "probably manage your sitemap for you." See where Wix publishes and manages its sitemap and how Squarespace handles sitemaps and indexing.

If you manage dozens of client sites and want to know which sitemap URLs Google has actually indexed while you fix this, check your sitemap URLs free.

What causes "Sitemap could not be read"?

"Sitemap could not be read" has five causes in Google's own list, given under "Sitemap fetch errors" in the Sitemaps report help as of October 2026:

Three related rules from the same help page catch people out:

• No logins. "The sitemap must be accessible to Googlebot and must not be blocked by any login requirements." A bot challenge on the path has the same effect.
• No redirects. For the submitted Sitemap URL, "Redirects are not followed." Submit the final address.
• robots.txt applies to the sitemap itself: "Google respects robots.txt when fetching sitemaps." See editing the WordPress robots.txt safely, and what "Blocked by robots.txt" means for individual pages.

Wrong-URL cases often come from platform defaults, such as a sitemap that moved when you changed SEO plugins. Check where WordPress puts its sitemap, how a Next.js app generates sitemap.xml, and Shopify's sitemap and Search Console setup.

How do you confirm the cause with URL Inspection?

Confirm a fetch failure by running a live test on the sitemap URL itself in Search Console's URL Inspection tool. Google's debugging steps, as of October 2026, are:

1. Click the sitemap in the Sitemaps report, then click the error name for details.
2. Copy the sitemap URL from the details page.
3. Paste it into the URL Inspection bar and press Enter.
4. Click Live test (labelled Test live URL).
5. Expand Page availability. Google says "basically you want to see Crawl allowed? = "Yes", Page fetch = "Successful.""

The URL must belong to the property you're in. Our step-by-step guide to the URL Inspection tool explains each field.

How do you validate a sitemap from the command line?

You can validate a sitemap yourself with curl and xmllint (the XML checker that ships with libxml2) against the official schemas from sitemaps.org. FreshlyCited doesn't offer a hosted sitemap validator; these are the commands we ran on October 17, 2026, against our own live sitemap index:

SITEMAP=https://freshlycited.com/sitemap.xml
HOST=https://freshlycited.com

# 1. Status code, content type and size, fetched with Googlebot's user agent
curl -sS -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  -o sitemap.xml -w "%{http_code} %{content_type} %{size_download} bytes\n" "$SITEMAP"

# 2. The official schemas
curl -sSO https://www.sitemaps.org/schemas/sitemap/0.9/sitemap.xsd
curl -sSO https://www.sitemaps.org/schemas/sitemap/0.9/siteindex.xsd

# 3. Well-formed XML that matches the schema (use sitemap.xsd for a urlset)
xmllint --noout --schema siteindex.xsd sitemap.xml

# 4. Count <loc> values that are NOT absolute URLs on this host (want 0)
grep -o '<loc>[^<]*</loc>' sitemap.xml | grep -vc "<loc>$HOST/"

# 5. Is the sitemap listed in robots.txt?
curl -sS "$HOST/robots.txt" | grep -i '^sitemap:'

The output we got:

200 application/xml; charset=utf-8 226 bytes
sitemap.xml validates
0
Sitemap: https://freshlycited.com/sitemap.xml

We then broke three copies on purpose to see what each mistake looks like. Each maps to an error in Google's report:

broken.xml:4: parser error : EntityRef: expecting ';'
    <loc>https://example.com/shoes?color=red&size=9</loc>

baddate.xml:5: element lastmod: Schemas validity error : ... '17/10/2026' is not a valid value of the union type '{http://www.sitemaps.org/schemas/sitemap/0.9}tLastmod'.

badns.xml:2: element urlset: Schemas validity error : Element '{http://www.sitemaps.org/schemas/sitemap/.9}urlset': No matching global declaration available for the validation root.

• The unescaped & is Google's "Parsing error": "Often, this problem is caused by an unescaped character in the URL". Write &.
• The day-first date is "Invalid date": dates "must use W3C Datetime encoding", such as 2005-02-21.
• The .9 namespace is the mistake Google names: the namespace "must be "http://www.sitemaps.org/schemas/sitemap/0.9" (not .9)."

Two limits. The schema accepted a relative <loc>/blog/launch</loc> without complaint, which is why step 4 exists. And a spoofed user agent isn't Googlebot: a firewall that checks Google's IP addresses can treat curl differently, so the URL Inspection live test is the final word. A URL that returns an HTML 404 page fails at step 1; that's the wrong-URL cause, not a broken sitemap.

Which sitemap rules does Google enforce?

Google applies the sitemaps.org protocol plus a few rules of its own. As of October 2026, Google's build guide says "All formats limit a single sitemap to 50MB (uncompressed) or 50,000 URLs", "The sitemap file must be UTF-8 encoded", and "Use fully-qualified, absolute URLs in your sitemaps" (Build and submit a sitemap).

The index rules come from Google's sitemap index guide; the Sitemaps report help adds that an index "can't list other sitemap index files, only sitemap files."

How do you fix "Sitemap could not be read"?

Fix this status by making the sitemap URL return a valid XML file with a 200 status to Googlebot, then resubmitting it.

1. Open the sitemap URL in a private browser window. If it 404s or redirects, find the address your CMS or plugin actually publishes.
2. Check robots.txt for a Disallow rule matching the sitemap path, and remove it.
3. Check the Manual actions report. Google says "Sitemaps are not read when a site has an unresolved manual action."
4. Remove logins, IP blocks and bot challenges for Googlebot on the sitemap path.
5. Validate the file with the commands above, or your platform's own checker. Split files over 50MB or 50,000 URLs into a sitemap index.
6. Submit the exact final URL under Add a new sitemap in the property it belongs to. You need owner permission to submit; without it, Google suggests listing the sitemap in robots.txt instead.
7. Add a Sitemap: line to robots.txt so Google can still find it if the report isn't used. Google says "there's no limit to the number of sitemaps you can include in your robots.txt file."

Don't "ping" Google with your sitemap. Google retired that endpoint in 2023: requests to it "will result in a 404 error" (Google Search Central Blog, June 26, 2023).

How do you check the fix worked?

Check the fix by resubmitting the sitemap and confirming the status changes to Success with a fresh Last read date; resubmitting is the request. Google says the sitemap "should be fetched immediately", though crawling its URLs takes longer.

• Discovered pages counts the URLs Google parsed. Google adds: "There is no guarantee that a page URL discovered in a sitemap has been or will be crawled or indexed by Google."
• Temporary error needs no action at first. Google says "If the error still exists after several hours, try resubmitting your sitemap."
• Then filter the Page indexing report by that sitemap to see how many of its URLs are indexed. URLs stuck as discovered - currently not indexed are the next thing to work on.

When should you push sitemap URLs for a recrawl?

Push individual URLs only after the sitemap reads successfully and only for important pages Google still hasn't indexed. A working sitemap is a hint, not an order: Google says it "doesn't guarantee that Google will download the sitemap or use the sitemap for crawling URLs on the site".

• A few pages: use Request indexing in URL Inspection. Google says "there's a quota for submitting individual URLs and requesting a recrawl multiple times for the same URL won't get it crawled any faster" (Ask Google to recrawl).
• Many pages: keep accurate <lastmod> dates on the pages that really changed, and wait. Google says crawling "can take anywhere from a few days to a few weeks."
• Bing: Microsoft recommends keeping sitemaps and adding IndexNow (an open "this page changed" notice that Bing and other participating engines accept; Google doesn't use it) for changes (Bing Webmaster Blog, July 2025).

Our comparison of the ways to submit a URL to Google covers each route, and how Google crawls and indexes pages gives the bigger picture. FreshlyCited can check which sitemap URLs Google has indexed in one list, then push only the ones Google can't see and re-check them on days 1, 3 and 7; an index credit is used only if the link gets indexed, and comes back after the day-7 re-check if it isn't (exclusions apply, such as pages that return an error or carry noindex). The recipe for pushing unindexed sitemap URLs runs it through the API or an AI assistant. Google still decides what it indexes.

Sitemap reading again? Check your sitemap pages free to see which URLs are seen by Google, push only the invisible ones, and get them re-checked.