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:
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:
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.
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.
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 indexedurls into the coverage table, and it should not. That field belongs in the raw blob where nothing queries it, next to submittedurls and lastdownloaded, 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.
lastdownloaded 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.