Google re-reads sitemaps without a resubmit: two timestamps in Search Console

My deploy notes had a rule: Google won't come back to a sitemap just because its contents changed, so resubmit it through the Search Console API after every deploy. The basis was one observation on August 23, 2026: a site's live sitemap had 129 URLs while Search Console still recorded 95.

But pulling the status of all 23 sitemaps I have access to at once, "no resubmit means no new download" doesn't hold: plenty hadn't been resubmitted in months, and Google still downloaded them last week. This note is about what two timestamps in the Search Console API can and can't tell you. Five questions, in order: what the two timestamps are, whether unsubmitted sitemaps get downloaded, what happened after a resubmit, what you still can't see after a download, and where ping and IndexNow fit.

Two timestamps

The Search Console API's sitemaps.list (GET /webmasters/v3/sites/{siteUrl}/sitemaps, with siteUrl percent-encoded) returns several fields per sitemap. The ones this note uses:

lastSubmitted: when it was last submitted
lastDownloaded: when it was last downloaded
isPending: in the documentation's words, "If true, the sitemap has not been processed."
contents[].submitted: the number of URLs of that content type; everything here is web

This site's own row (pulled 2026-10-12 16:37 UTC, rearranged one field per line):

sc-domain:baobaolin.com  https://baobaolin.com/sitemap.xml
  lastSubmitted  2026-07-31T17:13:18Z
  lastDownloaded 2026-10-06T16:39:08Z
  isPending      false
  contents       web submitted=50

baobaolin.com isn't in my resubmit script, and the API's last submission time is still July 31, yet Google downloaded it on October 6. The 50 URLs it recorded match the <loc> count I got with curl from the live sitemap the same day (this site's latest batch of entries isn't deployed yet).

Not resubmitted, still downloaded

Of the 23, 13 were last submitted more than 14 days before the snapshot (about 15.8 to 192.3 days, plus one at about 555.5 days). Their lastDownloaded:

Since last submit	Since last download	Sitemaps
About 15.8–192.3 days	2.3–9.0 days	12
About 555.5 days	About 550.2 days	1

All 12 were downloaded within 9 days of the snapshot. For the exception, my curl to its URL that day got no response within 10 seconds. The Search Console help says that when a sitemap fetch keeps failing, Google retries for a few days and then stops; that fits this one, but I don't have its error history, so it's an inference. Three of these 13 are feeds (Google accepts RSS and Atom as sitemaps).

So Google does come back to read sitemaps without a resubmit. The Search Console help (Sitemaps report) says the same: a successfully crawled sitemap is recrawled periodically, at a pace unrelated to the site's regular crawl, with no promised interval, and you might resubmit after big changes. This is one snapshot. It shows how long ago the last download was, not the gap between downloads, so I can't derive a frequency from it. The 95-versus-129 gap in August may have been Google not having re-downloaded the new version yet, but I didn't record lastDownloaded back then, so I can't tell.

What happened after a resubmit

A resubmit is one PUT with no body on the same sitemap (my script logs 204 on success):

PUT https://www.googleapis.com/webmasters/v3/sites/sc-domain%3Abaobaolin.com/sitemaps/https%3A%2F%2Fbaobaolin.com%2Fsitemap.xml
Authorization: Bearer <access_token>

It needs the OAuth scope https://www.googleapis.com/auth/webmasters; the read-only scope can't submit. The round at 15:49 UTC on October 11 submitted 9 sitemaps across 5 sites. Their state at snapshot time:

Result	Sitemaps
Last download 27 min 27 s to 32 min 27 s after the submit	7
Still `isPending: true` about 24 h 49 min after the submit	2

Seven were downloaded within the same five-minute window, which I take to mean the submit triggered it; that's an inference, though, and with no "didn't submit" control I can't say how much later they would have come otherwise. The other 2 show lastDownloaded at 15:30:46 the same day, before the 15:49 submit; the API keeps only the latest time, so what happened in between isn't visible. Separately, a new site's sitemap submitted October 10 still had no download time in the API about 47.5 hours later.

Google's "Build and submit a sitemap" is blunt: submitting a sitemap is merely a hint, with no guarantee that Google will download it or use it to crawl URLs. This round agrees: 7 of 9 had a new download about half an hour later, 2 didn't, and how long they wait isn't guaranteed.

What the API doesn't show after a download

A download record doesn't mean those URLs were crawled or indexed. The API's contents[].indexed looks like an index count, but it is "0" for all 21 sitemaps that report URL counts (the other 2 came out as empty lists in my output). The documentation says one thing about it: "Deprecated; do not use." To check whether a given URL is indexed, use the URL Inspection API one URL at a time, or the URL Inspection tool in Search Console by hand.

Google's June 26, 2023 blog post says it uses lastmod as a signal for scheduling recrawls, provided it consistently matches the page's real significant changes. This site's sitemap is generated at build time: an entry's lastmod comes from its declared modification date, falling back to the publish date, and the home page follows the newest entry. Whether the dates are right still depends on me updating the declared date when I revise an entry.

Ping is gone, and IndexNow doesn't include Google

The same 2023 post deprecated sitemap ping, saying the endpoint would stop working in six months and requests would then get a 404. I tried it while writing this (first line is the command, second the output):

curl -s -o /dev/null -w '%{http_code}\n' 'https://www.google.com/ping?sitemap=https://baobaolin.com/sitemap.xml'
404

IndexNow is a separate route: submit to any participating endpoint and it's shared with the other participants. As of writing, its site's searchengines.json lists Bing, Yandex, Seznam, Naver, Yep, Internet Archive and Amazonbot, and not Google. So on my other sites the tail of a deploy is two independent jobs: IndexNow for the Bing group, the Search Console PUT for Google, and neither replaces the other. (This site's deploy script does neither yet.)

The check I plan to add: PUT after deploying, then later GET and see whether lastDownloaded is later than lastSubmitted and whether contents[].submitted equals the live sitemap's URL count. Both matching is a sign that Google downloaded the new version, not proof: a different version with the same count, or processing not yet finished, can match too. Whether a new post was crawled still means checking it with URL Inspection. A temporary pending can wait; if the report shows fetch errors, fix them and resubmit.

If you remember one thing

Google re-reads a sitemap without a resubmit, just not on your schedule. The first half of the rule at the top has to go. I still follow the second half and resubmit after a deploy, since it costs one PUT; in this round 7 sitemaps had a download about half an hour later, but whether that gets new posts crawled or indexed sooner is a question this data can't answer. To tell whether a sitemap has been downloaded, look at lastDownloaded, not indexed.