# Google Search Console API: The Dashboard Said 82, the API Said 25

By Luke Sidney (https://lukesidney.me) · 16 Oct 2026 · updated 17 Oct 2026
Source: https://flowingkhaos.com/column/search-console-api-in-my-os

> Using the Google Search Console API to read per-URL index status: why the dashboard counted 82 not-indexed pages while the URL Inspection API found 25.

## Read the API, Not the Dashboard: 82 Versus 25 on the Same Day

The google search console api lives in my operating system because the dashboard and the API gave me two different numbers on the same afternoon, and only one of them was something I could act on. On 2026-10-15 the Page indexing dashboard for clevrstart.com counted 82 pages not indexed. The same day, a script of mine asked the URL Inspection API about each of the 105 URLs in the sitemap and got 25. Am I being too harsh on the dashboard? Probably. But 82 against 25 is not a rounding error, and the 25 came with a verdict, a last crawl date and a chosen canonical per URL.

```chart
{"title":"Not indexed on the same day: dashboard 82, API sitemap read 25","unit":" URLs","data":[{"label":"Dashboard, not indexed","value":82},{"label":"API, sitemap not indexed","value":25,"highlight":true}],"source":{"label":"Our own measurements"}}
```

What the API exposes is narrower than people expect. Google's [Search Console API overview](https://developers.google.com/webmaster-tools/about) lists four services: Search Analytics for clicks and impressions, Sitemaps, Sites, and URL Inspection for the index status of one URL at a time. According to the [API reference](https://developers.google.com/webmaster-tools/v1/api_reference_index), the caller needs owner, full or read permission on the property, and I read that as the whole access model: a service account added as a user in Search Console, nothing more exotic. There is no "index this" call for a normal page; I come back to that.

So the API is not a magic fix. It gives me a verdict on 105 URLs, not the reason. The reason I still have to find, and the fix I still have to make. What it changes is the order of work: I stop guessing from a total and start from a per-URL list.

## Why the Dashboard and the API Disagree: Table 1 and the Named Causes

I run clevrstart as a domain property, sc-domain:clevrstart.com. ppc.land's explainer on Search Console points out that [a domain property covers every protocol, host and subdomain](https://ppc.land/search-console), while a URL-prefix property covers one exact prefix, and suggests choosing the type that simplifies things. I disagree that either choice simplifies the reading. A domain property means the dashboard counts rows I never submitted; a prefix property means it misses hosts I care about. Either way the per-URL read is what tells me which rows are mine.

| Source, 2026-10-15 | What it counts | Not indexed | What the rows were |
|---|---|---|---|
| Page indexing dashboard | Every URL Google found on sc-domain:clevrstart.com, refreshed every few days | 82 | noindex 12, redirect 4, redirect error 2, not found 1, crawled not indexed 29, discovered not indexed 34 |
| URL Inspection API, via search-read.ts | The 105 sitemap URLs, live, one call each | 25 | discovered 16, crawled 5, unknown 4 |

The named causes behind the 57 extra rows, measured with curl the same day: bookings.clevrstart.com answers 200 with a robots meta of noindex, nofollow, nocache; agents.clevrstart.com answers 200 with noindex; the ian and cms subdomains answer 307 to a login; clevrstart.com and http:// answer 308 to https://www; /en is 404 because English lives at the root. The old sitemap addresses, /sitemap-index.xml, /fr/sitemap.xml and /sitemap-0.xml, all answer 404 and still show up in PostHog hits, so something out there still asks for them.

None of those rows are a problem. All of them inflate a number that looks like a verdict. The dashboard refreshes on Google's schedule, every few days; the API answers for the page as Google holds it now. That gap, the population and the refresh, is the whole disagreement.

## What My Google Search Console API Script Reads and Writes: pages.csv, index.csv and the Ten-Minute Run

The script is search-read.ts, in KhaordicOS, the monorepo I run my businesses from. It has three modes and it writes CSVs into my vault, under raw/keywords/track, one folder per site per month.

pages mode joins three sources into one row per page: Search Console (clicks, impressions, click-through rate, position), Bing Webmaster Tools, and PostHog, my product analytics, with the site's own events. The header is host, path, clicks, impressions, ctr, position, bing_clicks, bing_impressions, bing_position, pageviews, visitors, booking_clicked, form_started, form_sent, call_booked, pdf_downloaded. One line per page tells me whether Google showed it, whether anyone came, and whether they booked.

index mode makes one URL Inspection call per sitemap URL and writes index.csv with url, verdict, coverage, last_crawl, google_canonical, user_canonical. A run over 105 URLs takes about ten minutes. On 2026-10-14 a single API 500 killed a run ten minutes in with no CSV written; on 2026-10-15 I added a retry-once-then-skip, commit 5af09df7. Google's documentation sets the quota at 2,000 inspections per property per day, which is plenty for a site of 105 pages read weekly. The [client libraries page](https://developers.google.com/webmaster-tools/v1/libraries) lists official clients in several languages; I call the REST endpoints directly from a Bun script, which is less code than a library and the same four calls.

status mode prints what the last run did. The script reads and writes. It does not click Request Indexing; I do that, by hand, one URL at a time, and I write down when.

Two limits I found by running it, not by reading the docs. The performance API lags about three days. And it omits the query for roughly half of clicks, so pages.csv is the truth and queries.csv is a sample. seotistics' comparison of the two consoles reports that [Search Console anonymises a share of queries while Bing does not](https://seotistics.com/gsc-vs-bwt-differences), and I concede the point: Bing is in my CSV as a second source for exactly that reason, with no claim about conversions attached.

## The Reads: clevrstart 19 to 80, and flowingkhaos's Sitemap Correction

Two sites, two shapes, both from the same CSV.

```chart
{"title":"clevrstart submitted and indexed, 2026-10-07 versus 2026-10-15","unit":" URLs","data":[{"label":"2026-10-07 indexed","value":19},{"label":"2026-10-15 indexed","value":80,"highlight":true}],"source":{"label":"Our own measurements"}}
```

| clevrstart, read (UTC) | URLs | Indexed | Discovered, not indexed | Crawled, not indexed | Unknown |
|---|---|---|---|---|---|
| 2026-10-07 18:21 | 103 | 19 | 64 | 5 | 15 |
| 2026-10-15 16:37 | 105 | 80 | 16 | 5 | 4 |

Zero rows on either read where google_canonical differs from the page's own canonical, on a bilingual site with self canonicals and reciprocal hreflang. On or about 2026-10-07 I clicked Validate Fix on 77 URLs; I did not note the time, so that date is my recollection. The recrawls in the second read are dated 2026-10-12 to 2026-10-15. I will not say the click caused the rise, because I changed dates, canonicals and links in the same window. Performance for context: September, 10 impressions and 0 clicks; October 1 to 7, 15 impressions and 3 clicks, all on the home page for "skedual", a product name.

| flowingkhaos, read (UTC) | Sitemap | Indexed | Duplicate without user-selected canonical | Unknown |
|---|---|---|---|---|
| 2026-10-07 22:13 | 26 slash addresses | 1 | 21 | 4 |
| 2026-10-08 00:22 | 26 slashless addresses | 24 | 0 | 2 |
| 2026-10-15 17:10 | 36 | 34 | 0 | 1 (+1 discovered) |

The six-hour jump was not a recrawl; the crawl dates were September's. It was a sitemap correction. Every page answered at /column and /column/, joined by a 307 from Cloudflare's assets layer; Google chose slashless, the sitemap submitted slash. I wrote up the repair in [the Astro trailing slash fix](https://flowingkhaos.com/fixes/astro-trailing-slash-cloudflare-sitemap-duplicates), and the data there shows a 301 at the zone did what three code commits could not. The [investigation page](https://flowingkhaos.com/fixes/astro-trailing-slash-cloudflare-sitemap-duplicates/investigation) shows the attempt that failed first, with the curl output. Ten pages published after the fix were all indexed by 2026-10-15. Impressions for context: September, 25 and 0 clicks; October 1 to 15, 74 and 1 click. On 2026-10-14 the same column pair caught four legal pages on clevrstart emitting a relative canonical, fixed in 605cba5.

## The 2026-10-15 Loop, Timed: Table 4 and the Request Not Yet Made

I ran the loop on one day, and here it is with the clock from git and the deploy log.

| Time (UTC), 2026-10-15 | Step | Evidence | Status |
|---|---|---|---|
| 16:37 | Inspection read finished, 105 URLs | index.csv | Done |
| Same afternoon | Link crawl: home, /tools, /info, /about, /work carry zero links to service pages; /services 2 each, /pricing 1 each, /industries 1 | curl + grep | Done |
| Within the hour | Footer Services list on every page, 7 EN and 8 FR links | commit 694d211, Vercel build, verified live | Done |
| Not yet | Request Indexing on the five EN service pages and /fr/services/referencement-local | URL Inspection, by hand | Pending |

The five pages are /services/ai-agent, /services/chatbot, /services/booking-software, /services/blog and /services/professional-website: "Crawled, currently not indexed" on both reads, last crawled 2026-08-28 or 29, never fetched again, while their French twins are indexed. Googlebot's crawl stats for 2026-09-25 to 10-03 say why nothing moved: 2 visits in 9 days, 10 and 19 requests, 96.5 percent refresh, 3.5 percent discovery. Google was re-reading old pages, not finding new ones, and these five had no inbound link from any indexed page.

From read to live fix took under an hour. The index result takes days, and the dates go into the next read. Semrush's Search Console guide points out that [Request Indexing does not guarantee indexing](https://www.semrush.com/blog/google-search-console), and I agree; that is why the request is the last step and the footer links came first. webaloha's index checker lays out a fix order, [non-2xx status, noindex, canonical, sitemap, then inspect and request](https://webaloha.co/tools/google-index-checker), which matches the sequence I ran, and the reason it matches is that there is only one sensible order. The whole method, from the first read to that request, is what SEO in the age of AI: get your pages indexed, from the API shows step by step, with the same CSV columns and the data from both sites.

## Indexed View Versus Live Test, and Why Validate Fix Does Not Help on Crawled Not Indexed

URL Inspection has two views, and the script reads only one. The indexed view is Google's last recorded verdict for the URL: what it crawled, when, what it decided. "Test live URL" is a separate fetch of the page as it is right now. The script reads the verdict, because the verdict is what Search shows. The live test is what I run by hand after a fix, to see whether the fixed page is fetchable before I ask Google to come back.

For "Crawled, currently not indexed", Google has fetched and judged the page. Validate Fix asks it to re-check that judgement. Without a change to the page or its links, the re-check returns the same verdict, which Google's Page indexing report help says in its own words: the page may or may not be indexed in the future, no need to resubmit. That is why I did not validate the five service pages. I changed what linked to them, and the request comes next.

Bing deserves one line here. Impression's guide to Bing Webmaster Tools shows that it now [reports crawl requests and indexed pages](https://www.impressiondigital.com/blog/guide-to-bing-webmaster-tools) in its own console, and I read it for the same reason I read Google's: a second per-page verdict, no conversion claims attached. The open-source category is wide too: the [indexing-api topic on GitHub](https://github.com/topics/indexing-api?o=asc&s=updated) lists command-line clients, an MCP server for Search Console and "auto indexing" scripts. Most of them show a status. Few record the interval to the next read, which is the number I want. A commercial connector such as Databloo's will pipe Bing data into an assistant for you; I would rather keep the CSV. And the Indexing API is not part of this loop at all: it is restricted to job postings and live events, so for a service page the request still happens in the console.

## What I Have Not Measured, and the Next Read

I have one dated example of the loop. Calling it a track record would be generous. Here is what I still have not measured, in the record's own words.

The request-to-index interval: not measured on these sites. My 48-hour figure for a clean page is an estimate from other sites, and "real rankings in two to five weeks" is expectation, not data. The cause of the 19-to-80 change: coincided with Validate Fix and three other changes; not attributed. The footer fix's effect on indexing or rankings: only shown live, nothing measured yet. PostHog conversions against Google traffic: joined in one CSV, no attribution claimed. A/B tests on page formats: running with PostHog events, no comparison exported. Bing against Google conversions: not compared.

The five English service pages are the live test. The next read happens after I click Request Indexing, and the dates land in [how long does it take google to index a page](https://flowingkhaos.com/column/how-long-to-get-indexed), which shows the two measured shapes so far and leaves the five pages as pending rows. Why I ended up building this instead of buying it is a longer story, and [How I learned SEO the hard way](https://lukesidney.me/blog/how-i-learned-seo-the-hard-way) tells it, including the 2024 experiment I would not repeat.

What I will claim today is smaller and, I think, more useful: one script, one CSV per site per month, every page's verdict next to its traffic and its events, read by an agent that can edit the code. The data, the fix and the request go through one door. That is the whole reason the API lives in my operating system, and the next read is the only thing that can tell me whether it earned its place.

## Sources

- [Overview  |  Search Console API  |  Google for Developers](https://developers.google.com/webmaster-tools/about)
- [API Reference  |  Search Console API  |  Google for Developers](https://developers.google.com/webmaster-tools/v1/api_reference_index)
- [Libraries  |  Search Console API  |  Google for Developers](https://developers.google.com/webmaster-tools/v1/libraries)
- [Explaining Search Console](https://ppc.land/search-console)
- [Guide to Bing Webmaster Tools (2026 Update) | Impression](https://www.impressiondigital.com/blog/guide-to-bing-webmaster-tools)
- [Google Search Console VS Bing Webmaster Tools - All The Differences](https://seotistics.com/gsc-vs-bwt-differences)
- [Google Search Console: the ultimate guide for 2026](https://www.semrush.com/blog/google-search-console)
- [Google Index Checker: Test URL Indexability Signals](https://webaloha.co/tools/google-index-checker)
- [indexing-api · GitHub Topics · GitHub](https://github.com/topics/indexing-api?o=asc&s=updated)
- SEO in the age of AI: get your pages indexed, from the API
- How long my sites take to get indexed, with the dates
- How I learned SEO the hard way
- [Astro trailing slash on Cloudflare: fix the 307 and sitemap duplicates](https://flowingkhaos.com/fixes/astro-trailing-slash-cloudflare-sitemap-duplicates)
- [Astro trailing slash on Cloudflare: fix the 307 and sitemap duplicates — flowingkhaos](https://flowingkhaos.com/fixes/astro-trailing-slash-cloudflare-sitemap-duplicates)
- [Investigation — Astro trailing slash on Cloudflare: fix the 307 and sitemap duplicates](https://flowingkhaos.com/fixes/astro-trailing-slash-cloudflare-sitemap-duplicates/investigation)

## Questions, answered

### What services does the Google Search Console API offer?

It offers four services: Search Analytics for clicks and impressions, Sitemaps, Sites, and URL Inspection for the index status of one URL at a time. There is no "index this" call for a normal page.

### Why did the Page indexing dashboard show 82 not-indexed pages while the API showed 25?

The dashboard counts every URL Google found on the domain property and refreshes every few days, while the API reads only the 105 sitemap URLs live, one call each. The extra dashboard rows included subdomains with noindex robots tags, redirects to logins, and 404s.

### How many URL Inspection API calls can you make per day?

Google sets the quota at 2,000 inspections per property per day. A run over 105 sitemap URLs took about ten minutes.

### Does Request Indexing guarantee indexing?

No, Semrush points out it does not, and the article agrees. That is why the request is the last step, after fixes like adding footer links to the unindexed pages.

### Does the performance API data lag behind?

Yes, the article found the performance API lags about three days. It also omits the query for roughly half of clicks, so the per-page CSV is treated as the truth and queries.csv as a sample.