← All posts

How to Check if a Page Is Indexed (3 Methods, 1 Blind Spot)

URL Inspection is the only method that reports Google's real index status, and Google says so. Plus the drop Search Console structurally cannot show you.

QueryScope team · · 12 min read ·
search console gsc indexing

Open Search Console, paste the full URL into the inspection bar at the top, and read the verdict. That is the only method that reports Google's actual index status for one specific page, and Google says so directly: the page indexing report "isn't used to investigate the index status of specific pages. To find the index status of a specific page, use the URL Inspection tool." [1]

That answers the easy version of the question. The version most people actually mean is harder: the page was indexed, the traffic is gone, and they want to know when it fell out. Search Console has no answer to that one, and the reason is structural rather than a missing button.

Below: the three methods people use and which of them reads real data, why a page sitting outside the index isn't automatically a problem yet, and the one check you can't run retroactively no matter which tool you buy.

TL;DR:

  • URL Inspection is the only per-page index check. Google's own docs point you away from the coverage report for this job. [1]
  • A site: search isn't a check. Google's John Mueller: "a site: query is not meant to be complete, nor used for diagnostics purposes." [3]
  • A third-party checker can only read your index status if you connect Search Console, because inspection requires the property. [2]
  • Nothing in Search Console stores per-URL index history, so "dropped out" and "never got in" look identical unless you were already recording.

How do you check if a page is indexed?

Paste the full URL (including https://) into the search bar at the top of any Search Console property you own, and wait for the inspection panel. A green "URL is on Google" means indexed. Anything else names a state: crawled and not kept, discovered and not crawled, blocked, or excluded by a canonical.

Three details make the reading trustworthy or misleading:

  • Use the exact URL Google would. A trailing slash, http instead of https, or a www mismatch inspects a different URL than the one you meant.
  • Read the last crawl date beside the verdict. Everything shown describes that crawl, because "the results shown are from most recently indexed version of a page, not the live version on the web." [2]
  • Ignore the panel's certainty. One inspection is a reading, not a verdict, and it can flip without your site changing. The four ways a single inspection misleads you covers that in detail.

That's the whole check. The rest of this post is about the three places people go instead, and the question the tool can't answer.

Why doesn't the page indexing report answer this?

Because it was built for a different job and Google says so on the page itself: "This report isn't used to investigate the index status of specific pages." [1] It reports how many URLs are in each state across your whole site. Counts, not identities. It's the right tool for spotting that forty pages fell out and the wrong tool for asking about yours.

Two limits in the same help page make that concrete, and both are worth knowing before you go hunting through it.

The first is that Google discourages small sites from opening it at all: "If your site has fewer than 500 pages, you probably don't need to use this report." [1] Most people asking this question run a site an order of magnitude under that line, which means the report they were sent to is a large-site instrument handed to a small-site problem.

The second is the row cap. "Note that the list of example URLs in the report is limited to 1,000 items, and isn't guaranteed to show all URLs in a given status, even when less than 1,000 items." [1] Read that carefully. The list is a sample, and Google explicitly declines to guarantee completeness even below the cap. So a page missing from the examples for a given state tells you nothing at all, in either direction.

Is a site: search a real index check?

No, and Google has said so plainly. Asked why a site: query doesn't return every URL, Google's John Mueller answered: "The short answer is that a site: query is not meant to be complete, nor used for diagnostics purposes." [3] He then pointed people at the same place this post does: "If you're keen on finding out how many pages google has indexed from your website, then use Search Console instead." [3]

The operator is still useful, just not for this. It's a filter on ordinary search results, which means it inherits every ordinary ranking and deduplication behavior. A page can be indexed and absent from a site: search. A site: result count can move without a single page's index status changing.

Where it does earn its keep is as a quick negative signal on a site you don't own and therefore can't inspect: competitor research, a client site before you get access, checking whether a domain has any presence at all. Treat a hit as weak evidence of indexing and a miss as no evidence of anything.

Can a third-party index checker see your real index status?

Only if it asks you to connect Search Console first. The URL Inspection tool and its API are scoped to properties you're verified on: "The URL must be in the current property. To test a URL in a property that you don't own, use the appropriate non-owner test." [2] There's no public endpoint for "is this URL in Google's index."

So any bulk checker that takes a list of URLs and returns green ticks without an OAuth step is not reading your index status. It's running something else, usually a site:-style query or a scrape of search results, and inheriting all the unreliability Mueller described. The output looks like Search Console data and isn't.

This is the one place a free tool is genuinely worse than no tool, because it produces a confident answer from a source Google has told you not to use for diagnostics. Checkers that do ask you to authorize Search Console are reading the real thing, ours included, and they're all reading the same API with the same limits.

What if the page simply isn't indexed yet?

Then usually nothing is wrong and there's nothing to fix. A new page is expected to sit outside the index for a while, and Google is upfront that "indexing typically takes only a day or so, but can take much longer in some cases." [2] Treating day-three as a defect is how people end up rewriting pages that were fine.

Our own indexing check encodes that as a grace period: a page in a wait state (found but not crawled, or crawled and not yet kept) doesn't escalate into work for 28 days. Before that window it shows as status, not as a task. The number is a judgment call rather than a Google rule, but the principle behind it isn't: a brand-new site would otherwise generate a queue full of "problems" whose only real fix is waiting.

What separates waiting from broken is the state, not the elapsed time. A robots block, a stray noindex, a 404, or a server error is actionable on day one. The two wait states are different jobs with different causes: Google crawled it and declined to keep it, or Google found it and hasn't fetched it yet. If you want that split done for you rather than read off a coverage list, separating the real blocks from the noise is the job that page does.

Try it

Read your own Search Console, not just an essay about it.

QueryScope brings your real Search Console data into Claude Code or Cursor, so your agent reads it for you. From $14.99/month.

Why can't Search Console tell you a page dropped out?

Because the two surfaces that could answer it each hold exactly half the information, and neither holds both. The report tracks index counts over time but is explicitly not for specific pages. Inspection is specific to a page but returns one current reading with no memory of the last one. History without identity, identity without history.

Google's own troubleshooting entry shows the shape of what you get. Under a drop in indexed pages, the advice is: "If you see a drop in total indexed pages without a corresponding increase in errors, you might be blocking access to your existing pages via robots.txt, 'noindex' or a required login." [1] That's real guidance about a number. It names three causes and no URLs, because the report doesn't know which pages left.

Adam Gent, an SEO product manager and technical SEO consultant who works on indexing specifically, reaches the same conclusion from the practitioner side: "The most important insights come from tracking coverage state changes over time, which GSC doesn't show." [4] A Google help page and an independent specialist naming the identical gap from opposite directions is about as much corroboration as a structural claim gets.

The practical consequence is that a de-index is a diff, and Search Console stores no previous state to diff against. Any tool that reports "this page recently dropped off Google," ours included, is reporting a comparison it made against a reading it saved itself. It's not surfacing a Google field. There is no such field.

How do you tell a page that dropped out from one that never got in?

Not from the inspection panel, which shows both as some flavor of not-indexed with no distinction between them. But two things do separate them, and one of them is sitting in a Search Console report nobody thinks to open for this.

The performance report is an index-history proxy. A page cannot earn impressions without appearing in search results, and it cannot appear in search results without being indexed. So if a URL shows impressions in March and none since, it was indexed in March. That's a real answer reconstructed from a different report, and it works back through however much history you still have, which is 16 months at most before Google drops it. Two limits: it dates the disappearance of traffic, which trails the actual de-index by however long the page took to stop being served, and a page that never earned a single impression tells you nothing.

The last crawl date is the other tell. An empty one on a not-indexed page means Google has never fetched it, so it was never in and there's no drop to investigate.

Here's the part worth internalizing, because it's the limit on every tool in this category rather than a gap in one of them. Our own de-index detector needs a stored prior reading that says indexed before it can report a drop at all. The branch that handles a URL with no such reading is a single line, and its comment says exactly what it does: // Never indexed (crawled-not-kept from first sight): nothing to drop. It returns nothing and moves on.

So a page that fell out last month, before anything started watching, is genuinely indistinguishable from a page that was never indexed. Not hard to tell apart. Indistinguishable, from the data. You can't detect a drop you weren't already recording, and no product can sell you that history retroactively, because Google never had it to give.

Watching index state without checking by hand

The check itself takes ten seconds and doesn't scale past a handful of URLs, which is why it gets used for the wrong job: it's excellent for a page you already suspect and useless for finding out which pages deserve suspicion. Running it across a site by hand every week is the kind of task that gets done twice and then quietly stops.

QueryScope inspects your sitemap's URLs once a day and keeps the readings, which is what turns a snapshot into the diff Search Console doesn't do. When a page's verdict flips from indexed to not, that's a dated event with the clicks it was earning beforehand attached, and your agent gets it in the terminal with the repo open beside it. A drop only counts once it survives a second inspection the next day, so a flicker in the API doesn't wake you up.

Start recording before you need it. That's the whole lesson, and it's the one thing you can't buy back later. For the one-line meaning of each index state and its caveat, the Search Console glossary covers them individually.

Sources

  • Google Search Console Help, Page indexing report ("This report isn't used to investigate the index status of specific pages. To find the index status of a specific page, use the URL Inspection tool"; "If your site has fewer than 500 pages, you probably don't need to use this report"; "Note that the list of example URLs in the report is limited to 1,000 items, and isn't guaranteed to show all URLs in a given status, even when less than 1,000 items"; "If you see a drop in total indexed pages without a corresponding increase in errors, you might be blocking access to your existing pages via robots.txt, 'noindex' or a required login"). [1]
  • Google Search Console Help, URL Inspection tool ("This is not a live test. The results shown are from most recently indexed version of a page, not the live version on the web"; "The URL must be in the current property. To test a URL in a property that you don't own, use the appropriate non-owner test"; "Indexing typically takes only a day or so, but can take much longer in some cases"). [2]
  • John Mueller (Google), via Search Engine Journal, Google: A 'Site:' Search Doesn't Show All Pages, 17 August 2021 ("The short answer is that a site: query is not meant to be complete, nor used for diagnostics purposes"; "If you're keen on finding out how many pages google has indexed from your website, then use Search Console instead"). [3]
  • Adam Gent, Indexing Insight, 5 Hidden Insights in the Page Indexing Report ("The most important insights come from tracking coverage state changes over time, which GSC doesn't show"). [4]
Try it

Read your Search Console where you code.

Ask your coding agent how your site is doing. QueryScope reads your real Search Console data in the terminal: clicks, queries, intent, and indexing. From $14.99/month. One to ten sites.