Between 2026-09-16 and 2026-09-24 we ran four scheduled Search Console checks. Each inspected 20 URLs through the URL Inspection API. Zero pages moved into the index across all four runs. This guide documents the workflow that produced those reports, the exact calls, the coverage states we observed, and the action each state triggers. Run the same workflow on your site and you get the same evidence trail.
How our Google Search Console automation authenticates
Our helper signs its own tokens. No browser OAuth flow, no client library.
1. Create a service account and register it as a verified owner on the Search Console property. Ours works against the sc-domain property for webrecast.com.
2. Sign a JWT with RS256 using the account private key. The claim set carries the webmasters scope, the token endpoint as audience, and an expiry of issue time plus 3600 seconds.
3. POST the signed assertion with the jwt-bearer grant type to the token endpoint.
4. Call the API with the returned access token. The token dies in one hour, so request a fresh one per run.
One detail worth copying. Querying data and mutating data need different scopes. Our snapshot script uses the readonly scope for searchAnalytics queries. The sitemap submitter uses the full webmasters scope. Keeping them separate means the query path can never change anything.
The coverage states a real property produces
Guides list a dozen coverage states. Four weeks of samples on one property produced four.
Submitted and indexed. The homepage held this state in the 2026-09-08 report, last crawled 2026-09-06. No other URL in any of our samples held it.
Crawled, currently not indexed. The dominant state. Between 12 and 16 of every 20 sampled URLs sat here across the four checks. Google fetched the page and declined to index it.
URL is unknown to Google. Between 1 and 6 URLs per sample. These pages sit in the sitemap and have never been crawled.
Server error 5xx. Two to three per sample, all from crawl attempts in May. Live checks on 2026-09-08 returned 200 to Googlebot on every sampled URL, so those states are stale history, not a live outage.
The condition-action table we run against these states:
| Coverage state | Action |
| Submitted and indexed | None. Record the crawl date. |
| Crawled, not indexed | Compare the page against pages already ranking. Rewrite, merge, or improve it. |
| Unknown to Google | Confirm the URL is in the sitemap and linked internally. |
| Server error 5xx | Verify the URL returns 200 live before acting. Stale states clear on recrawl. |
The 20 URL inspection method
Each check follows the same recipe, and that fixed shape is what makes week-over-week comparison meaningful.
1. Fix 10 priority URLs. Ours are the core tool pages, the same ten in every run.
2. Draw 10 random URLs from the sitemap. The draw changes each run, the priority list does not.
3. Record two fields per URL, coverage state and last crawl timestamp.
4. Write everything to a dated file in the audits directory.
5. Compare only against the previous file, never against expectations.
The four summaries read as follows. The 2026-09-16 run returned 16 crawled not indexed, 2 unknown, 2 server error. The 2026-09-18 run returned 12, 6, 2. The 2026-09-21 run returned 16, 1, 3. The 2026-09-24 run returned 12, 6, 2. The priority rows stayed identical across all four. That stability is the finding. Nothing moved, in either direction.
Sitemap resubmission, honestly assessed
The sitemap chronology from our audit files:
- Google last downloaded sitemap.xml on 2026-07-03. Over two months stale.
- We resubmitted it through the API on 2026-09-08 at 06:48 UTC. The call returned HTTP 204 and the status flipped to pending.
- The feed.xml companion sitemap reports 28 URLs submitted, 0 indexed.
- Four checks after the resubmission, zero sampled pages entered the index.
Resubmission makes the file known to Google. It does not schedule a crawl and it does not oblige indexing. Budget one minute for the call and zero certainty for the outcome.
We also pushed all 1495 sitemap URLs to IndexNow, which returned HTTP 200. IndexNow covers Bing, Yandex, Seznam, and Naver. It does not cover Google. Tools that promise Google indexing through IndexNow are misdescribing what the protocol does, so we state the coverage split explicitly.
What the Search Console API cannot do
Request indexing does not exist in the API. The button lives in the Search Console interface only, and our audit log records manual requests for the top 10 priority URLs as a follow-up step. If a service claims automated indexing requests against Google, it is doing something else.
The searchAnalytics endpoint gave us 11 impressions and 1 click for the trailing 30 days as of 2026-09-18, with the single click from Turkey. Small numbers still decide things. That result, plus the fact that our non-English pages ship noindex by design, ended a plan to produce roughly 450 translated pages per language. The measurement cost one API call and cancelled months of planned work.
Limits of this workflow
The URL Inspection API returns a verdict and a coverage string. Most of our rows read NEUTRAL on the verdict, and the useful information sits in the coverage text. Crawl dates can be months old, as our May-dated 5xx rows show. The API reports symptoms on single URLs, while the cause can sit at the site level. Our diagnosis attributes the stall to crawl budget on a new low-authority domain carrying 1495 URLs across 15 language clones. URL Inspection cannot confirm that diagnosis. It can only stay consistent with it, week after week.
Your weekly Search Console checklist
- [ ] Query searchAnalytics for the trailing 30 days. Record clicks and impressions.
- [ ] Inspect 10 fixed priority URLs plus 10 random sitemap URLs.
- [ ] Save coverage state and last crawl per URL to a dated file.
- [ ] Diff against last week. Count state transitions in both directions.
- [ ] Act only through the condition-action table above.
- [ ] Resubmit the sitemap only when its contents changed.
If your samples disagree with ours, the interesting number is which state dominates them. We track ours weekly and the audit files are the source for every figure above. For the on-page half of the work, run your pages through our checker at https://webrecast.com/en/seo-checker and bring the results back. We read every reply.
