The Search Console URL Inspection API returns a coverageState string for each URL, and
the two most common values on a young site are "Discovered - currently not indexed" and "URL is
unknown to Google". Those read like different situations. Tracking the split between them looks like a
reasonable way to measure whether a site is being discovered.
It is not, and this is the test that shows it. Two complete censuses of the same 141 URLs were run on 2026-09-09, fifteen minutes apart, with the same service account key against the same verified property, and compared per URL:
| Result | URLs |
|---|---|
| Compared | 141 |
Changed coverageState between the two passes | 82 (58%) |
| "Discovered - currently not indexed" becoming "URL is unknown to Google" | 76 |
| "URL is unknown to Google" becoming "Discovered - currently not indexed" | 6 |
in_google_index differing between passes | 0 |
ever_crawled_by_google differing between passes | 0 |
Nothing changed on the site in those fifteen minutes. No deploy, no sitemap edit, no robots change. The API changed its mind about 82 URLs on its own.
Two fields were identical across both passes, and both were 1 out of 141: whether the URL is in the index, and whether Google has ever crawled it. Those are the fields to track, and they are the ones that answer the question anyone actually has.
coverageState is worth reading once for a single URL you are debugging, where the
verdict and the last crawl time give context. It is not worth trending, and a report that says
discovery rose or fell between two runs is measuring the API's variance rather than your site.
This is inference and it is labelled as such: the values that flipped are the two that both mean "not indexed", and the ones that held are the ones with a durable record behind them. That is consistent with the states being served from a cache or an index shard whose freshness varies per call, rather than from a single authoritative record. Nothing in Google's documentation promises stability here, and nothing observed from outside can confirm the cause.
The site is a documentation subdomain created 2026-09-02 with 141 sitemap URLs. In the same seven days, ClaudeBot fetched 140 of those URLs and Googlebot fetched 2, which is the separate measurement that made the index question worth asking at all. A site with more history and more indexed pages may see a lower flip rate, because more of its URLs would sit in states with a durable record.
Source: two passes of
POST https://searchconsole.googleapis.com/v1/urlInspection/index:inspect, one call per
URL, 141 URLs each, run at 08:45 and 09:00 UTC on 2026-09-09 against a verified
sc-domain property with the same service account. Both passes and the per-URL comparison
are recorded in data/indexation.json in this repository.
It is undocumented behaviour rather than an obvious defect, and the API does not promise that coverageState is stable. The practical response is to stop depending on it rather than to wait for it to change.
Yes, and it is the reason to design the census carefully. The URL Inspection API is rate limited per property, so running everything twice doubles a budget you may not have. Sampling half the URLs twice is a reasonable compromise for the stability check.
Verdict was not part of this comparison, so nothing is claimed about it. If you rely on it, run the same two-pass test before trusting a trend, which is the general lesson rather than a finding about one field.
Unmeasured here. Both passes used the same domain property, so the comparison is internally consistent and says nothing about other property types. Do not mix scopes in one census.
It answers a different question. The Indexing API asks Google to crawl and is limited to specific content types; URL Inspection reports state. Neither makes a page get indexed, and on a new domain the constraint is authority rather than notification.
All MCP servers and prices · All guides · Buy the bundle $39