Every working morning starts the same way. I open a spreadsheet of URLs for whichever client is mid-job, and I find out which of them Google is holding today. Not which ones I submitted. Not which ones I fixed last week. Which ones are actually in the index, this morning, according to Google.
That check is the whole job. Everything else in indexing work is downstream of it: what you fix, what you submit, what you leave alone, whether you are making progress or just busy. Get the check wrong and you spend a month rewriting pages that were indexed the entire time.
For two years I did that check with a private tool that talks to Google’s Search Console API. Last week I rebuilt the useful half of it as a free bulk URL inspection tool that runs in your browser, and gave it away. This is the long version of what it does, why it is built the way it is, and where it is deliberately limited.
What Search Console gives you, and where it stops
Search Console has two ways of answering the indexing question, and they answer different questions.
The Page indexing report tells you how many URLs are indexed across the property and groups the rest by reason. It is aggregated, and it lags. Two to four days of latency is normal, and it is not a bug: those numbers are computed across an enormous amount of crawl data. Through June and into July 2026 that lag stretched past two weeks, which Search Engine Land and others covered at the time. Google confirmed the delay affected reporting only, not crawling or indexing or ranking, so pages were being indexed normally while the report showed nothing. Worth remembering the next time a report looks alarming.
The URL Inspection tool answers for one exact URL, and it is fresh. Paste a URL, get Google’s own verdict: indexed or not, which canonical Google picked, when it last crawled, whether a directive is keeping it out.
So the fresh, precise answer exists. It is just behind a box that takes one URL at a time. On a catalogue of nine hundred products that is not a tool, it is a punishment. Google’s own documentation is clear that the Page indexing report “isn’t used to investigate the index status of specific pages”, so the report cannot substitute for the inspection either. You are stuck between a stale aggregate and a very slow queue of one.
In 2022 Google released the URL Inspection API, which returns exactly what the box returns, in bulk. That is the gap the tool fills, and it is the reason the tool can exist at all.
Where it came from
The clearest example in my case studies is a baby products store: 1,006 manual submissions across 118 days. People read that number and imagine something dramatic. It was a routine, run daily, for four months.
That routine only works if you know the state of every URL every day. Search Console caps manual submissions at roughly a dozen a day per property, so the daily decision is not “what shall I submit”, it is “which twelve URLs deserve today’s slots”. You cannot make that call from a number in a report. You need a per URL ledger: this one indexed on the 14th, this one has been discovered but uncrawled for three weeks, this one Google has never heard of.
The private tool built that ledger. It read a sitemap, ran every URL through the inspection API, wrote the results to a sheet, and I worked from the sheet. Nothing clever. It just meant that by the time I sat down, the question of what to do that day was already answered by data instead of by memory.
The tool I have given away is that, minus the parts that touch my own accounts and my own clients’ data. Same API, same status vocabulary, same logic for deciding what a result means.
I should say plainly that I am not first here. Valentin Pletzer’s Google Bulk Inspect URLs has done browser-side bulk inspection for years and is cited by Search Engine Land and Ahrefs. If you have used that and are happy, keep using it. What I have added is the thing I needed and could not get from a data dump: every status carries a plain-English meaning and a link to the guide on fixing it, so the output tells you what to do rather than only what is true.
The bug in my own code that changed the design
This is the part I would rather not write, and it is the most useful part.
The private tool had a documented behaviour I had believed for a long time: that pushing concurrent requests at the inspection API made it start reporting indexed pages as unknown. My own code comments said so. I had built around it: low concurrency, and a re-verification pass that went back and re-asked about every URL that came back unknown, on the theory that some of those answers were artefacts of speed.
When I rebuilt the tool for public use, I carried that belief across, because it came from my own notes on my own tool and I did not think to question it. I wrote it into the public copy in four places. I built the re-verification pass into the free tool.
It was not true. The degradation was a bug in the older tool’s own code, not a behaviour of Google’s API. There was never any speed-related distortion to work around.
Two things had to change. The copy, obviously, everywhere it appeared. And the re-verification pass, which had been quietly spending quota on a problem that did not exist. Re-asking about a URL that came back unknown does not get you a better answer. It gets you the same answer, and on a 2,000 URL daily budget those wasted calls are pages you could have checked instead. The pass now retries only requests that genuinely failed, meaning network errors and rate limiting, where there is no answer yet to spend quota on.
The lesson I have written down for myself: a finding inherited from my own older code is not evidence. It is a hypothesis with sentimental value. If a feature exists to work around a behaviour, the behaviour needs to be reproducible on demand, or the feature is superstition with a progress bar.
I mention it here because “unknown to Google” being a real answer rather than a glitch is now central to how the tool behaves, and you deserve to know that position was arrived at by being wrong first.
Why it runs in your browser
The tool asks you to connect a Google account that has access to your Search Console. That is a meaningful thing to ask for, and most tools that ask for it run the requests on their own server, which means your property list and your results pass through, and usually sit in, somebody else’s database.
This one does not work that way, because it does not have to.
The Search Console API allows cross-origin requests from a browser, which is the technical fact that makes all of this possible. Google hands the access token to your tab. Your tab calls Google directly. The results are assembled into a table in your page’s memory, and the CSV export is built in the browser too, so the file never touches a server on its way to your downloads folder.
Reload the page and everything is gone. That is not a feature I added, it is what happens when you never store anything in the first place. There is no account here, no email collected, and nothing to delete later because there was never anything to delete.
You can also skip me entirely. Under step one there is an Advanced option where you can paste your own OAuth client ID from your own Google Cloud project. The tool then talks only to your registration and my name is nowhere in the flow. Almost nobody will use that, and it should exist anyway.
The one exception, stated honestly
There is a single place where the “nothing touches my server” claim needs a footnote, and I would rather write it here than let someone discover it.
Sitemap mode. A browser is not allowed to fetch another site’s sitemap directly, and in practice no site permits it. So when you point the tool at a sitemap, the XML is fetched by a small reader on this domain, which returns the file and keeps no copy. It writes no log line. No Google token and no inspection result ever reaches it. The only thing it ever sees is a sitemap address that is already public by definition, because sitemaps are meant to be read by crawlers.
If that still bothers you, paste mode contacts no server of mine at all. It exists precisely for people who want the stronger guarantee, and using it costs you nothing except copying your URLs in yourself.
I have written into the code, in a comment on the reader itself, that it must never gain logging, caching, or storage. If that ever changes, the privacy claims on the tool page change in the same commit or the change does not ship.
Why it does not check with a site: search
Most tools calling themselves a bulk index checker work by running a site: or inurl: search for each URL and reading whether anything came back. I decided early that this tool would not, and that decision is the main reason it is worth using.
Google’s own documentation for the operator says it “doesn’t necessarily return all the URLs that are indexed”, and that “bigger sites shouldn’t expect to see all their URLs in the results”. So a URL can be missing from a site: search while sitting in the index and taking traffic. That is the failure mode that costs money: it sends you off to fix a page that was never broken.
There is also the shape of the answer. Even when site: finds the page, it gives you a yes. It cannot tell you that Google picked a different canonical, or that the page was last crawled in February, or that a stray noindex tag is the thing holding it out. Those are the facts that decide what you do next, and they only exist in the inspection response.
The honest trade, because there is one: inspection reads Google’s record for a property, so it only works on properties your Google account is verified on. A site: checker will happily run against any domain on the internet, which is why those tools remain the only option for checking whether somebody else’s page is indexed. Backlink checking is the common case. This tool cannot do that, and wanting it to will not change what the API returns. I wrote up the whole question in is the site: operator accurate.
What the statuses actually tell you
The tool reports Google’s own coverage wording, unedited, and maps it to plain language. The mapping is generated from the same source the results table uses, so the documentation on the page cannot drift away from what the tool actually reports.
The ones that matter most in practice:
Indexed. Google has it. It can rank. If it is not ranking, that is a different job entirely and no amount of indexing work will move it.
Crawled, currently not indexed. Google fetched the page and chose not to keep it. This is a value judgement, not a technical fault, and it is the status people waste the most effort on. Resubmitting an unchanged page books Google a return trip to the same decision. The guide covers what actually shifts it.
Discovered, currently not indexed. Google knows the URL exists and has not crawled it. Different problem, different fix: this is about crawl demand rather than about the page.
Unknown to Google. No current record of the URL. This one has two completely different meanings, and the tool cannot tell them apart for you, so I wrote a guide that can. A brand new page nobody links to and an old page Google has quietly forgotten both report this, and the fixes point in opposite directions.
Duplicate, and alternate with canonical. Google picked a different canonical than your page declares. The tool flags canonical mismatches as their own column, because on large catalogues this is frequently the real story hiding under a pile of “not indexed” rows.
Noindex, blocked by robots, 404, soft 404. Instructions and errors. These are the good ones to find, because they are unambiguous and you can fix them today.
The limits I cannot engineer away
Three of them, and no amount of clever code touches any.
2,000 inspections per property per day. Google’s cap, not mine. A big catalogue gets split across days, which is exactly how the real work goes anyway.
600 inspections a minute. Ten a second. A list of 200 URLs cannot finish in under twenty seconds however hard you push. The tool paces itself under that ceiling rather than collecting rate limit errors, which is why raising the concurrency setting stops making a difference past a point. Concurrency helps when individual responses are slow. It cannot buy you throughput the quota does not allow.
It cannot request indexing. The API is read only. Submitting a URL still means the button in Search Console, roughly a dozen a day, by hand. I would love to automate it. Google would love me not to, and the reasons the button behaves the way it does are worth understanding before you go looking for a tool that claims otherwise.
Verified properties only, which is not really a limit so much as the entire premise. The API answers for properties you control. That is what makes the answer trustworthy.
What changed in the first week
Watching someone else use a tool you built is uncomfortable and extremely productive. Everything below came from actual use in the days after it went live.
The sitemap fallback became the default. Originally the tool tried to read a sitemap directly from the browser first, and offered the reader as a fallback when that failed. It failed every time, because no site allows a browser to read its sitemap cross-origin. A fallback that is always used is not a fallback, it is the path, and making people press a button to reach the only thing that works was a bad joke at their expense.
Sitemaps Google already knows about load automatically. Selecting the option and then pressing Load was a step that existed for no reason.
Sitemap URLs are read only when you press Inspect. The opposite of the point above, and the distinction matters. Listing the sitemaps costs nothing. Reading every URL out of one costs time, so it now happens when you have actually committed to a run.
Stop became Resume. Stopping a long run and then wanting to continue meant starting from the beginning, which on a partly spent daily quota is genuinely expensive. The button now flips: stop, then resume, and everything already inspected is kept. Only the handful of requests in flight when you stopped get redone.
Concurrency went up to 20, with a rate limiter underneath keeping the whole run inside Google’s per minute ceiling. Six at a time was needlessly cautious.
The re-verification pass got narrowed, for the reason described earlier.
What it will not do
It will not get your pages indexed. It is a diagnosis, not a treatment. If the answer comes back mostly red, the work starts there rather than ends there.
It will not check a competitor’s site, or a backlink, or any domain you are not verified on.
It will not store your history so you can compare this week to last. That is a genuinely useful feature and it is fundamentally incompatible with storing nothing, so it is not coming. If you want a trend, export the CSV each time. That is a real limitation of the privacy model and I would rather have the model.
The next tool on the shortlist is a sitemap health checker, built the same way. If something else would be more useful, say so and it moves up the list.
Who this is for
If you have a handful of URLs and a spare afternoon, Search Console’s own inspection box is fine and you do not need this.
If you have a catalogue, a sitemap you are not sure Google has read, or a nagging suspicion that a chunk of your site is missing from the index and you have been guessing with site: searches, run the list through it. It takes a minute, it costs nothing, and nothing you put in leaves your browser.
And if the result is worse than you expected, send me the export. I will tell you what the pattern is, free, before anyone talks about money. Finding out that four hundred product pages are sitting in “crawled, currently not indexed” is not a disaster. It is a diagnosis, and it is a considerably better position than not knowing.