Google Index Checker: Check Google Index Status, an Indexation Checker for Every URL

What "indexed" tells you, and what it does not

Indexed means Google has stored the page and it is eligible to appear in search results. That is all it means. It is not a promise of traffic, it is not a ranking, and it is not a quality score. Plenty of indexed pages never receive a single click, and that is normal.

The inverse matters more. A URL that is not indexed cannot rank for anything, no matter how good the content is or how many links point at it. So index status is a gate, not a goal: it is the first thing to confirm when a page gets no impressions, because every other explanation is a waste of your time until you have ruled this one out.

• Indexed: stored and eligible to rank. Nothing more is implied.
• Crawled, currently not indexed: Google read it and passed. A quality or duplication judgment.
• Discovered, currently not indexed: queued but not fetched yet. Usually crawl priority.
• Excluded by noindex or robots.txt: you are keeping it out, deliberately or by accident.
• Indexed URL with no snippet: Google indexed the address but was blocked from crawling the content.

Checking a whole site without guessing

The honest method at scale is the Search Console URL Inspection API. It returns the same verdict the URL Inspection tool shows, one URL per query, capped at 2,000 queries per day and 600 per minute per property. That cap is the real constraint, and it is why serious index checking is a prioritisation exercise rather than a speed contest. You decide which URLs are worth a query today.

Start from a source of truth for what should be indexed: your sitemap, or a crawl of your own site, filtered to canonical, indexable URLs. Anything on that list without an indexed status is a gap worth explaining. Anything indexed that is not on the list is worth a look too, because it often turns out to be a filtered or paginated URL quietly eating crawl budget.

Then attach a reason to every gap, because a list of missing URLs with no causes is just a longer version of the site: problem. Once the cause is clear, the fixable ones get fixed and resubmitted through official channels, and the rest get retired. Google still decides what to index, and nobody can honestly promise otherwise, but at that point you know exactly what you are asking it to reconsider and why.

How do I check if my whole website is indexed by Google?

Checking one URL is easy. Checking whether a site is indexed is a different question, and the tempting shortcut gives a misleading answer. Typing a site: query returns a page count, people treat that count as their indexed total, and it is not one. Google describes those results as an estimate. It rounds, it excludes some content, and the number moves between two searches run a minute apart on an unchanged site.

The Page indexing report in Search Console is the honest source for a whole property, because it reports what Google actually holds and splits the not-indexed URLs by reason. Its limits are worth knowing before you rely on it: the data lags by a few days, and any individual status shows up to 1,000 example URLs no matter how many are affected. On a site with 50,000 pages, a status covering 12,000 of them still shows you 1,000. You can see the scale of a problem there. You cannot get the full list.

So the workable method for a whole site is to start from your own inventory rather than from Google's report. Take the URL list you believe should be indexed, usually straight from your sitemap, and check each address for a real per-URL verdict. That inverts the question from "what does Google have" to "which of my pages are missing", which is the version you can act on. It also catches the case the coverage report structurally cannot show you: pages that were never discovered at all, and so appear in no status because Google does not know they exist.

• site: returns an estimate, not your indexed page count.
• The Page indexing report is accurate in aggregate but shows at most 1,000 example URLs per status.
• Search Console data lags by a few days, so it describes the site as it was.
• Checking your own URL list catches never-discovered pages, which appear in no report at all.

How often should you check your Google index status?

For a site that publishes occasionally, checking new URLs a week or two after they go live catches the ordinary failures while there is still time to fix them cheaply. Most pages that are going to be indexed are indexed within that window, so a page still missing after two weeks is usually missing for a reason rather than because Google is busy.

For a site that publishes constantly, or one where indexing is the business, spot checks stop working. The failure mode that costs the most is not a new page that never indexed, it is an old page that quietly dropped out. Nothing announces that. Search Console sends no notification when a URL leaves the index, traffic to a single page rarely falls hard enough to trigger an alert, and the loss surfaces in a quarterly review months later. Continuous checking exists to turn that into an event you find out about the same week.

The pattern that works for most teams is a scheduled check across the full URL inventory, at whatever cadence matches how fast the site changes, plus an immediate check on anything newly published or newly changed. That gets you both halves: confirmation that new work landed, and early warning when existing work disappears. Checking once and assuming the answer holds is the mistake, because index membership is not a permanent state.

Checking one URL, a list of URLs, or an entire site

These are three different jobs and using the wrong tool for one of them wastes a lot of time. For a single URL where you need Google's own authoritative answer, the URL Inspection tool in Search Console is the right instrument and nothing else is more trustworthy, since you are asking Google directly. The cost is that it handles one URL at a time and belongs to a property you have verified.

For a batch, whether that is a hundred URLs from a publishing run or several thousand from a migration, the constraint becomes throughput rather than accuracy. The URL Inspection API exists for exactly this and is capped at 2,000 queries per day and 600 per minute per property, and it is read only, so it reports status and never submits anything. Any tool that checks a large list at speed is working inside those same limits, which is a useful thing to know when a vendor implies otherwise. The bulk index checker page covers that workflow and the per-URL reasons in more detail.

For an entire site, the answer is a combination rather than a single tool: the coverage report for the aggregate shape, your own sitemap as the list of what should be there, and per-URL checks to reconcile the two. The reconciliation is where the value is. The pages that cost you traffic are almost always the ones sitting in the gap between what you think you published and what Google actually kept.

• One URL, authoritative: URL Inspection in Search Console.
• A list: the URL Inspection API, capped at 2,000 queries per day and 600 per minute per property, read only.
• A whole site: coverage report for shape, your sitemap for intent, per-URL checks to reconcile.
• No tool exceeds Google's published API limits. Treat claims otherwise as a warning sign.

How do I check my Google index status?

Open the URL Inspection tool in Google Search Console, paste the full URL, and read the verdict at the top. It says either "URL is on Google" or "URL is not on Google", and when a page is not indexed it names the reason underneath. That is the only method that reports from Google's own index rather than inferring status from search results, which is why it is the answer to this question and everything else is a proxy for it.

The tool also gives you two facts that matter more than the headline status. It shows the date of the last crawl, which tells you whether Google has ever fetched the page at all, and it shows the canonical Google selected, which is frequently different from the one you declared. A page that reports as not indexed with a Google-selected canonical pointing at another URL is not a missing page. It is a duplicate that Google consolidated, and no amount of resubmitting will change that.

For a quick informal Google index check without opening Search Console, search for the full URL including https. An indexed page almost always returns itself. Treat a negative result as inconclusive rather than proof, because a page can be indexed and still fail to surface for the exact string you typed. That asymmetry is the whole reason the search-based check is a screening step and not a verdict.

• URL Inspection tool: authoritative, one URL at a time, names the exclusion reason.
• Searching the exact URL: fast yes signal, unreliable no signal.
• site: operator: an estimate Google has said is not a count. Never use it to prove absence.
• Page indexing report: accurate in aggregate, capped at 1,000 example URLs per status.

Checking website indexing for a whole site, and the point where bulk checking takes over

Checking site indexing one address at a time is fine up to roughly a few dozen URLs. Past that the manual route stops being a check and becomes a data-entry job, and the practical ceiling in the URL Inspection tool is somewhere around 30 to 60 URLs an hour if you are quick and nothing distracts you. A 500-page site is a full day. A 5,000-page site is not a thing anyone finishes.

That is the point where the question changes shape. A per-URL Google site index check answers "is this page in", which is what you want when you are debugging one page. What you need for a whole property is a run over your entire URL list that returns a verdict for every address at once, sorted into indexed, missing and dropped, with the reasons attached. Those are different jobs and they use different mechanisms: the first is a lookup, the second is a scheduled process working within a fixed daily quota.

If your list runs to thousands of URLs, that second job is what our bulk index checker page covers, including how the 2,000 queries per day per property cap shapes what is realistically possible and how to prioritise inside it. Stay on this page if you are checking a handful of pages and want a reliable answer per URL. Both use the same underlying source of truth, so the results agree; the difference is throughput and how you decide which URLs are worth a query today.

Is there a Google index checker API?

There is, and it is the Search Console URL Inspection API. It returns the same verdict the URL Inspection tool shows in the interface, programmatically, one URL per request. This is the only official API that reports Google index status, and anything marketed as a Google index checker API that does not require verified Search Console access on your property is scraping search results instead, with all the accuracy and reliability problems that implies.

The quotas are published and they are the binding constraint. Google allows 2,000 queries per day and 600 per minute per property, alongside a much larger per-project ceiling that almost nobody reaches first. Two thousand a day sounds generous until you divide a real catalog by it: a 40,000-URL site needs about twenty days to complete a single full pass, which means comprehensive daily coverage is not available at any price. The quota is fixed, not purchasable.

That constraint is what turns index checking at scale into a prioritisation problem rather than an engineering one. The URLs worth spending a query on today are the ones that changed, the ones that earn traffic, the ones you published recently, and the ones that were indexed last month and are worth re-verifying. Checking everything on a rota beats checking nothing comprehensively, and it is the design any honest tool ends up with, including ours.