How to submit a sitemap to Google, and fix "Couldn't fetch"

To submit a sitemap to Google, open your property in Search Console, go to Indexing → Sitemaps, paste the sitemap’s URL into “Add a new sitemap” and press Submit. Google fetches it straight away and reports one of three statuses: Success, Has errors or Couldn’t fetch. A single sitemap can list up to 50,000 URLs or 50 MB uncompressed, so larger sites split it and submit a sitemap index. You can also list the sitemap in robots.txt, which needs no Search Console access at all.

The rest of this post covers what Google accepts, what each status means, and how to fix Couldn’t fetch.

What does Google accept in a sitemap?

Google reads XML sitemaps, plain-text sitemaps (one URL per line), and RSS or Atom feeds. A sitemap index, a sitemap of sitemaps, is accepted too. The rules worth checking first are short:

• Every URL must be fully qualified and absolute: https://example.com/pricing, not /pricing.
• The file must be UTF-8 encoded.
• One sitemap holds at most 50,000 URLs and 50 MB uncompressed. Past either limit, split it and list the parts in an index.
• A sitemap index can list up to 50,000 sitemaps, but it cannot list other index files.
• Google uses <lastmod> when it is consistently and verifiably accurate, and ignores <priority> and <changefreq>.

Google recommends posting the sitemap at the root of the site. It also has to match the property you submit it in: a sitemap for http://example.com will not show in the report for https://example.com, and www versus non-www mismatches produce “Path mismatch” errors. If you are unsure which property type you have, Domain vs URL-prefix properties explains the difference.

How to submit a sitemap in Search Console

1. Check your access. Google’s Sitemaps help says you need owner permissions to submit; its permissions table also lists full users. If the submit box does nothing for you, ask an owner or use robots.txt instead.
2. Publish the sitemap on the site, ideally at the root, for example https://example.com/sitemap.xml.
3. Test it. Paste the sitemap URL into URL Inspection and run a live test; “Page fetch” should be Successful and “Crawl allowed?” should say Yes.
4. Open Indexing → Sitemaps, paste the URL into “Add a new sitemap” and click Submit.
5. Google fetches the file right away. If the status is anything other than Success, click the row for the error details.

Crawling the URLs inside takes longer, and Google is clear that not every URL listed will be crawled. A sitemap is a hint about what exists, not an instruction to index it.

The robots.txt line

Any crawler that reads your robots.txt can find your sitemap from one line:

Sitemap: https://example.com/sitemap.xml

Google picks it up the next time it crawls robots.txt. This is the route to use when you have no Search Console access, and it is worth having even when you do, because Bing and other search engines read the same line. Sitemaps found this way also count as “submitted” in the Page indexing report’s sitemap filter.

The old habit of pinging Google with a URL whenever the sitemap changed is gone: Google announced in June 2023 that the sitemaps ping endpoint was going away. Its current documentation lists three ways in: the Sitemaps report, the Search Console API and robots.txt.

What the sitemap statuses mean

Status	What Google says it means	What to do
Success	The sitemap was loaded and processed with no errors	Nothing. Google will recrawl it periodically
Has errors	The sitemap was fetched but has one or more errors	Open the row and fix the listed errors; URLs Google could parse are still queued for crawling
Couldn’t fetch	The sitemap could not be fetched at all	Work through the causes below, then resubmit

On the top-level list, a sitemap with problems may also show a count such as “Sitemap had 3 errors”. The details page names each one. The errors you are most likely to meet are Parsing error, Invalid URL, Invalid date, Too many URLs, Sitemap file size error, Empty sitemap, Compression error, the two Path mismatch variants, and “Sitemap contains urls which are blocked by robots.txt”.

How to fix “Couldn’t fetch”

Google’s help lists five causes. Check them in this order, because the first three cover most cases.

1. The URL is wrong. A typo, a missing trailing segment, or the sitemap living at /sitemap_index.xml when you submitted /sitemap.xml. Open the URL in a browser; if it returns a 404, that is your answer.
2. robots.txt blocks it. A broad Disallow rule can catch the sitemap itself. Run URL Inspection’s live test on the sitemap URL and check that “Crawl allowed?” is Yes.
3. The server failed. A timeout, a 5xx, or a firewall or bot-protection rule that challenges Googlebot. “Page fetch” in the live test should be Successful. Google notes that transient errors may clear on their own, so wait and see whether it persists.
4. Low crawl demand for the sitemap. Google lists this as a cause in its own words. On a small or new site it usually resolves with time.
5. An unresolved manual action. Rare, but open the Manual actions report and rule it out; it takes ten seconds.

Google retries a failed fetch for a few days, then stops. Once you have fixed the cause, submit the sitemap again as a new request. Google’s Sitemaps report help has the full error list with a fix for each.

Removing a sitemap does less than you think

Open a sitemap’s details, choose the more-options menu and select “Remove sitemap”, and it disappears from the report. Google does not forget it, though: the sitemap and every URL in it stay known. To stop Google visiting the sitemap itself, block it in robots.txt, delete the file, or serve it with a noindex response header. Removing a sitemap from the report is housekeeping, not a de-indexing tool.

What to look at after Success

A successful sitemap shows when Google last read it and how many pages and videos it discovered. Discovered is not indexed. The useful view is the Page indexing report (Indexing → Pages) filtered to that sitemap, using the dropdown above the chart: “All submitted pages” or the specific sitemap URL. That shows how many of the URLs you said matter are actually in the index, and why the rest are not. The Page indexing report explained covers every reason you will see there. Google’s sitemap documentation has the format details if you build sitemaps by hand.

A note on Bing and IndexNow

Bing reads sitemaps too, submitted in Bing Webmaster Tools or found through the same robots.txt line, and its webmaster blog calls <lastmod> “a key signal” for deciding what to recrawl. Bing also supports IndexNow, a protocol for notifying search engines the moment a URL changes. The participating engines listed on indexnow.org are Microsoft Bing, Naver, Seznam.cz, Yandex and Yep. Google is not on the list, so IndexNow does nothing for your Google indexing; your sitemap and robots.txt line do that job.

Where QueryWatch fits

QueryWatch reads your sitemaps from Google’s Search Console API, so on an iPhone or Android phone you can see each sitemap for every property, with when it was last read and its error and warning counts. That list is on the free tier.

Submitting and deleting sitemaps from the phone is Pro. It is also the one moment the app asks Google for write access: the extra permission is requested the first time you submit or delete, never at sign-in. Deleting in the app does exactly what “Remove sitemap” does in Search Console, with the same caveat above. Pro also includes a sitemap error alert, a push when a submitted sitemap’s error count rises or the sitemap disappears from Search Console, which is often the first sign that a deploy broke something. The relay behind it checks every six hours; the alerts page explains how, and the app page covers the rest. QueryWatch is an independent app and is not affiliated with Google.