I run a daily pipeline against the Google Search Console API for a site I maintain. One stage pulls the sitemaps report. It has returned the same thing on every run for four months:
sitemap-index.xml submitted: 39 indexed: 0
sitemap-0.xml submitted: 39 indexed: 0
Zero warnings, zero errors, last downloaded 2026-05-29.
If that is the only coverage number on your dashboard, the site is dead. It is not. On the same run, the URL Inspection stage walked 30 URLs from the same property and came back with this:
PASS Submitted and indexed 23
NEUTRAL Crawled, currently not indexed 3
NEUTRAL Blocked by robots.txt 2
NEUTRAL Excluded by noindex tag 2
Twenty three of thirty pages indexed, with a crawl timestamp from two days earlier. Both numbers come out of the same API, for the same property, in the same run, a few minutes apart.
Which one is lying
Neither, exactly. The indexed field on sitemaps.list is vestigial. I cannot tell you when it stopped meaning anything, only that across every run I have logged it has been 0 while the property was demonstrably indexed. It does not return null, it does not raise, it carries no deprecation flag in the payload. It returns zero.
That last detail is the entire problem. A null would have shown up as a gap in my schema on day one. A zero is a measurement. It sorts, it charts, it fills a column, it survives review, because nothing about it looks broken. The most expensive values in any pipeline are the ones that are wrong in the shape the schema expects.
What changes
One thing is already true and two are now queued, and I want to be exact about which is which, because a writeup that describes a fix in the past tense is its own kind of zero.
Already true: the pipeline does run URL Inspection as a separate stage, which is the only reason I could catch this at all. Thirty URLs per run, walked from the sitemap.
Queued: the sitemaps stage still writes indexed_urls into the coverage table, and it should not. That field belongs in the raw blob where nothing queries it, next to submitted_urls and last_downloaded, which are both real.
Also queued, and the part that generalises past Google: any bare zero from a vendor API needs a second source before it is allowed to become a metric. The failure here was never that a field got deprecated. It was that a single upstream integer became a KPI with no mechanism to notice it had stopped carrying information.
The part I had wrong for four months
last_downloaded on both sitemaps reads 2026-05-29, and I had been filing that as a second symptom of the same upstream problem.
It is not. My index push stage has a diff gate: if the sitemap content has not changed, it does not resubmit. Nothing changed, so nothing was resubmitted, so Google had no reason to refetch. The stale date was correct behaviour from my own code, and I had been reading it as evidence against somebody else.
Both halves of this are the same mistake in opposite directions. One number meant less than I thought, the other meant something different than I thought, and in both cases I had stopped asking what produced it.
If you have a coverage number that has never moved, the useful question is not what it says. It is whether it can say anything else.
Top comments (0)