How to check if a page is indexed (and why site: keeps lying to you)
Ask five people how to check whether a page is in Google’s index and you will get five answers. Three of them will be wrong in a way that only shows up later, when a decision built on that answer turns out to have been built on nothing.
Here are the four methods that exist, what each one actually measures, and when to use which.
1. The site: operator
Type site:example.com/some-page into Google and see if the page comes back.
It is fast, it needs no access to anything, and it is the least reliable method available.
site: is a search operator, not an index lookup. The results it returns are filtered, deduplicated and shaped by the same systems that shape ordinary search results. A page can be indexed and not appear. A page can appear while the version Google holds is stale by weeks. The result count above the list is an estimate that changes between refreshes of the same query.
There is also a subtler trap: site: searches Google’s serving index for your query, which is not the same question as “does Google hold this URL”. For a single URL the two usually agree; for a section of a site they routinely do not.
Use it for: a five-second sanity check when you have no access to the property.
Never use it for: reporting to a client, deciding whether a fix worked, or counting how many pages are indexed.
2. URL Inspection in the Search Console interface
Paste a URL into the inspection box at the top of Search Console and you get the authoritative answer for that URL: “URL is on Google”, or not, plus the reason, the canonical Google selected, the last crawl date, and whether the page is mobile-friendly.
This is the ground truth. When site: and URL Inspection disagree, URL Inspection is right.
One distinction matters here and is constantly missed. The default view shows the indexed version — what Google has stored from its last crawl. The “Test live URL” button fetches the page right now. These answer different questions. If you just fixed a noindex tag, the live test will show it fixed while the indexed version still shows the old state, because Google has not re-crawled yet. Both are correct; they are describing different moments in time.
Use it for: the definitive status of one URL, and for diagnosing why.
Limitation: one URL at a time, by hand. At fifty URLs it is tedious. At five thousand it is not a method.
3. The Page Indexing report
Search Console’s Page Indexing report (formerly Coverage) groups every known URL by reason: indexed, excluded by noindex, duplicate without user-selected canonical, crawled but not indexed, and so on.
This is the right tool for patterns. If an entire section stopped being indexed after a template change, this report shows it as a shape — a cliff in the chart, a reason bucket that suddenly gained four hundred URLs.
Its weakness is timing. The report is aggregated and refreshed on Google’s schedule, and the data you see typically trails reality by several days. It is a rear-view mirror with a wide field of view.
Use it for: finding systemic problems and their scale.
Never use it for: “is this specific URL indexed right now” — by the time it answers, the answer is old.
4. The URL Inspection API
The Search Console API exposes the same inspection data programmatically. One request, one URL, and you get back the machine-readable version of what the interface shows:
{
"inspectionResult": {
"indexStatusResult": {
"verdict": "PASS",
"coverageState": "Submitted and indexed",
"robotsTxtState": "ALLOWED",
"indexingState": "INDEXING_ALLOWED",
"pageFetchState": "SUCCESSFUL",
"googleCanonical": "https://example.com/page",
"userCanonical": "https://example.com/page",
"lastCrawlTime": "2026-08-20T04:31:07Z"
}
}
}Two constraints define what you can build on it.
It requires Full access. The service account or user making the call must be an owner or a Full user of the property in Search Console. Restricted users get a 403. There is no way around this, and no way to inspect URLs on a property you do not have access to — which also means no tool, including ours, can legitimately monitor indexing on somebody else’s site.
It has a hard daily ceiling. 2,000 inspections per day per property, and 600 per minute. That is enough to check a 2,000-page site daily, and not enough to brute-force a 50,000-page site. Anything larger requires prioritising which URLs get checked when — we wrote about how we do that in URL Inspection API limits.
Also worth knowing: the API returns the indexed version only. There is no live-test equivalent in the API. If you need a live fetch, you need the interface.
Use it for: anything at scale, and for anything that must run on a schedule rather than when someone remembers to look.
Which to trust when they disagree
They will disagree, and the hierarchy is stable:
| Question | Use |
|---|---|
| Is this URL in the index right now? | URL Inspection (UI or API) |
| Why is it not indexed? | URL Inspection, then the Page Indexing report for context |
| Did a whole section drop out? | Page Indexing report |
| Roughly, is this page findable? | site:, and only roughly |
If site: says no and URL Inspection says “URL is on Google”, the page is indexed. If the Page Indexing report says a URL is excluded and URL Inspection says it is indexed, the report is stale and inspection is current.
The gap none of these close
Every method above answers “what is the status now” — at the moment you ask. None of them tells you when it changed.
That gap is where the damage happens. A page that quietly leaves the index on a Tuesday keeps its rankings for a few days out of inertia, loses traffic gradually, and gets noticed a month later during a routine report — if at all. The Page Indexing report will eventually reflect it, aggregated among other numbers. Nobody gets notified.
Closing that gap does not require anything clever. It requires asking the same question about the same URLs every day and comparing today’s answer to yesterday’s. That is precisely what Crawlert does: daily checks through the official API, and a message the day a verdict flips — not a month later.