Google does not promise to read your sitemap. It proved that to us with two
months of silence: our sitemap said lastmod August 16, and Search Console
still showed "last downloaded July 3". Every page we shipped in that window
was invisible to the crawler, and nothing anywhere raised an alarm.
If you publish regularly and your index coverage is frozen, check the
"last downloaded" timestamp before anything else. It is the cheapest
diagnostic in all of technical SEO, and it explains stale coverage more
often than robots rules or canonicals do.
What the timestamps told us
The Search Console sitemaps report shows two dates: last submitted and last
downloaded. Ours read submitted July 2, downloaded July 3. The sitemap file
itself carried a lastmod of August 16, because our build regenerates it on
every deploy.
Google had simply opted out. A sitemap is a discovery hint, not a contract.
With no external links pointing at the new pages and no manual actions,
Google's scheduler had no reason to spend crawl budget re-fetching a file
it already had.
The dead end most guides still recommend
Search for "resubmit sitemap" and half the results tell you to ping Google:
https://www.google.com/ping?sitemap=https://example.com/sitemap.xml
That endpoint is retired. It returns an error page. If your resubmission
playbook starts with the ping URL, your playbook has a dead first step and
you may not have noticed, because nothing fails loudly. You visit the URL,
see a page, and move on assuming it worked.
The fix that took eight seconds
Search Console has an API. The sitemaps endpoint accepts a PUT:
PUT /webmasters/v3/sites/{siteUrl}/sitemaps/{feedpath}
Authentication needs a service account with the webmasters scope, added as a
user on the Search Console property. The call is one line with the API
client libraries, or a signed JWT and a fetch if you have no dependencies.
We ran it once. Submitted 06:48:04. Downloaded 06:48:11. Eight seconds
after two months of nothing.
That speed is the information worth keeping: the ping-style mental model of
"wait for the crawler to notice" is wrong for resubmission. A PUT goes into
the scheduler's queue directly, and the fetch happens in seconds.
What resubmission does and does not do
Be precise about the mechanism, because the misconceptions are expensive:
- Resubmitting queues a fresh download of the sitemap file. That is all.
- It does not queue the URLs inside the sitemap for crawling. Google still
decides per URL whether and when to fetch it.
- It does not reset any penalty or reprocess any indexing decision.
For us, the resubmission restored discovery. Pages that had never been
crawled started appearing in inspections with fresh crawl dates. Pages
already sitting in "crawled, currently not indexed" stayed exactly where
they were. The sitemap got us back into the queue, not into the index.
lastmod discipline matters now
Google states that it uses lastmod when the values are credible. That cuts
both ways:
1. If your build writes today's date into every URL on every deploy, Google
learns the field is noise and ignores it. We stamp lastmod only when a
page's content actually changes.
2. If lastmod is honest, a re-download can prioritize genuinely changed
URLs for crawling.
An honest lastmod plus an API resubmission is a real workflow. An
everything-changed lastmod plus a dead ping URL is theater.
The check to run monthly
Run this against your own property before you trust your publishing loop:
1. Read the sitemaps report in Search Console, or query the API endpoint.
2. Compare lastDownloaded against your most recent deploy date.
3. If the gap exceeds a week, resubmit through the API or the UI button.
4. Confirm the new download timestamp lands within a minute.
5. If it does not, the problem is fetchability, not scheduling: fetch the
sitemap URL yourself, check for redirects, and confirm it returns 200
with no authentication wall.
Do not stack resubmissions. One PUT per genuine change window is plenty.
Repeated pings on an unchanged file train the scheduler to trust you less.
What we changed permanently
The resubmission now runs from the deploy pipeline. Every time the build
produces a sitemap with new lastmod values, the pipeline calls the API once.
No human remembers to press the button, and the two-month silent gap cannot
recur.
We also added the sitemap report to a weekly automated check: submitted
date, downloaded date, warning and error counts, straight into a log file.
Silence was the real failure mode here. The timestamps were always there,
telling us exactly what was wrong.
---
Has your sitemap gone stale without you noticing? Check the last downloaded
date now and leave the gap you find. If you want the endpoint reference for
automating this, our robots.txt and sitemap guide covers the API call in
detail: https://webrecast.com/en/guides
