Search Console API: No Way to List All Indexed Pages
By Ugur Saritepe · September 8, 2026
Search Console's UI shows every indexed page in one report, so you assume the API returns the same list. It does not. We read the API's own discovery document on 7 September 2026: 11 methods, and not one of them lists indexed pages in bulk. Here is what works, the quota math, and the sweep we built around the gap.
Four dead ends, verified against Google's own API surface
This started as a feature request on our own dashboard. The Pages view was inspecting URLs while the page loaded, and it was slow, so the obvious question was whether we were missing a bulk call:
When I logged in gsc console it actually shows all the indexed pages in one place I suspect they might have api or call for it to get batch
Reasonable suspicion. The discovery document, the machine-readable description of the Search Console API, settles it. Checked 7 September 2026:
- URL Inspection takes exactly one URL. The request type has a single required string field,
inspectionUrl. There is no array form and no batch method. - The Sitemaps endpoint's indexed count is dead. The field that once reported how many sitemap URLs were indexed is marked "Deprecated; do not use." in the live schema. On our domain properties it reads 0 regardless of reality.
- No coverage resource exists. The whole API is 11 methods across search analytics, sitemaps, sites, and URL Inspection. Nothing corresponds to the Page indexing report.
- The BigQuery bulk export will not help either. Its per-URL table carries clicks, impressions, and position. No index state.
The list you see in the UI reads an internal endpoint Google has never exposed, and the UI's own export caps at 1,000 rows per category. Every bulk-inspection tool you have heard of, Screaming Frog's included, queues one call per URL against the same limit; their own tutorial prescribes crawling 2,000, waiting 24 hours, and re-spidering the next 2,000.
The real constraint is latency, not the 2,000-a-day quota
Google's usage limits give URL Inspection 2,000 calls per day and 600 per minute, per property. That sounds tight and mostly is not: we track 526 pages across three sites (game-scout.app, ohhi.nl, traffictriage.com, counted 7 September 2026), so 2,000 a day is roughly four full passes. A site under a few hundred pages fits its whole sitemap in one day's quota with room to spare.
What actually hurts is that each call is slow. We measured 6.6 seconds per inspection on 4 September 2026 (5 calls, 6,583 to 6,702 ms, on traffictriage.com). Run that during a page load, the way our dashboard first shipped, and inspecting 20 URLs at concurrency 8 takes about 17 seconds of the render. That is the difference between a report and a spinner.
What we built instead: an hourly sweep with a priority rule
The fix we designed on 7 September moves inspection out of the request path entirely:
Before we start can you check docs and competitors how do they do this ?
urlInspection.index.inspect: single required string, no batch sitemaps indexed field: "Deprecated; do not use." coverage resource: does not exist (11 methods total) quota: 2,000/day, 600/min, per property
no bulk endpoint anywhere; every tool queues one URL per call
There is no batch call to find. The design that fits the API we actually have: inspect in the background on a schedule, store the results, and make the dashboard a pure database read.
So the sweep runs inside our existing hourly cron, inspects a bounded batch per run, and writes the results to the database. The owner's call, typed in that session: "Okey lets start with spec for moving render option to hourly cron instead when we open the "pages" we will just see data from db".
The priority rule is the part worth stealing. Search analytics has no daily limit, and a page with impressions is indexed by definition. So impressions are free evidence, and inspection quota should go where that evidence cannot reach: inspect the pages search analytics cannot vouch for first. New pages, pages with zero impressions, pages whose impressions stopped. Pages earning impressions every day can wait at the back of the queue, because you already know their index state.
As of 8 September 2026 the hourly sweep is written and reviewed but not merged yet; the Pages tab still inspects at render time, so this section describes the design we are shipping, not a result we have measured.
How to get your own list today, in quota order
Spend the free sources before the metered one. Each step shrinks the set the next step has to cover.
1. Export the Page indexing report from the UI. Search Console, Indexing, Pages, then Export. Good output: a spreadsheet with one tab per state. Bad output: exactly 1,000 rows in a tab, which means you hit the export cap and the list is truncated, not complete.
2. Pull impressions per page from search analytics. Query with page as the dimension over the last 16 months. Every page that appears is or was indexed; the first day a page records an impression is a reliable lower bound on when it entered the index. This API has no daily limit. We used exactly this diff when our indexed count fell from 560 to 524 and it named 14 of the 36 lost pages.
3. Inspect only the remainder. Whatever your sitemap contains that steps 1 and 2 did not confirm gets a per-URL inspection, up to 2,000 a day. Good output: URL is on Google with a recent crawl date. Bad output worth acting on: Crawled - currently not indexedon pages you care about, which is a quality decision on Google's side, not a crawl failure.
Or let the list accumulate while you work
Everything above is scriptable, and if you enjoy OAuth consent screens, the scripts already exist. Our conclusion from building this was different: index coverage is not a report you run, it is a table that should fill itself. That is the same principle the rest of our routine runs on, and the other assistant-side workflows follow the same pattern. If you want the site-level basics checked before any of this, the free triage report runs eight checks from a URL alone, no account needed.
FAQ
Is there a Search Console API to list all indexed pages?
No. The entire Search Console API is 11 methods, and none returns the indexed-page list you see in the UI. URL Inspection checks one URL per call, the Sitemaps endpoint's indexed field is deprecated, and the BigQuery bulk export carries performance data only. The list in the Page indexing report reads an internal endpoint Google has never exposed, and its export caps at 1,000 rows per category.
What is the URL Inspection API quota?
2,000 calls per day and 600 per minute, per verified property, per Google's usage limits page. The quota is per property, not per project, so a site verified as several properties gets an allowance for each. For most small sites 2,000 a day covers the whole site several times over; the practical limit is latency, since each call takes several seconds.
How do I check if all my pages are indexed without writing a script?
Start in the Search Console UI: the Page indexing report lists indexed and not-indexed pages and exports up to 1,000 rows per category. Then use search analytics as a proxy: any page with impressions is indexed by definition, and that API has no daily limit. Only the remainder, pages with no impressions and no UI row, needs a per-URL inspection.
See every tracked page's index state in one table. Create a free account, connect Search Console, and the Pages view in the dashboard holds coverage state, last crawl, and Google clicks per URL, the table this post's sweep was built to fill. Your assistant can read it too, through the MCP server.
