# How to Check When Google Indexed a Page

> Source: https://rankxai.com/blog/check-when-google-indexed-page · Last updated: 2026-09-10

To check whether Google has indexed a page, use the URL Inspection tool in Search Console, which reads Google's own index. The site: operator is a rough smoke test on a single full URL, and Google states it will not return every indexed URL. Search Console does not publish the date a page was first indexed.

## How to check if a page is indexed by Google

Three methods exist, and the gap between the best and the worst is wider than most guides admit. Only one of them reads Google's index directly. Ranked by what each actually looks at:

| Method | What it tells you | Trust it for |
| --- | --- | --- |
| URL Inspection (Search Console) | The current index verdict for one URL, read from Google's index, plus the last crawl date and the canonical Google chose | The real answer on a single page |
| Page indexing report (Search Console) | Aggregated counts of indexed and not indexed pages across the site, grouped by reason | Site-wide patterns, with a lag of days |
| `site:` operator | An incomplete, unranked sample of what Google will show for a prefix | A rough smoke test on one full URL, never a count |

Most guides to this question lead with `site:` and tell you to count the results. Google's own documentation says not to. The [`site:` operator page](https://developers.google.com/search/docs/monitor-debug/search-operators/all-search-site), last updated in December 2025, states that the operator **does not necessarily return all the URLs that are indexed** under the prefix in the query.

Google adds two qualifications on the same page. The first is to keep that incompleteness in mind if you want to use `site:` for tasks like identifying how many URLs are indexed. The second is that a `site:` query with no search terms does not rank its results at all: Google says it generally shows the shortest URL first and the rest are relatively random. A count taken from an unranked, incomplete sample is not a measurement.

The same page is more forgiving about the narrow case. Under its uses for site owners, Google says that a `site:` query on one complete URL **may help you understand whether a specific URL is indexed and served**. That is the honest boundary. Use `site:https://example.com/exact-page` as a two-second sanity check on one page, and never use `site:example.com` as a page count.

## Why Google indexes a page and then drops it a week later

Because indexing is not a permanent state. Google reassesses, and a page that was indexed on Monday can be out of the index by the following Monday with nothing about the page having changed. This is the single most common confusion around index checking, and it has a straightforward answer: **an index check is a reading with a timestamp, not a fact about the page.**

We measured this on this site. On 10 September 2026 we inspected 191 pages of rankxai.com through the Search Console URL Inspection API: 171 pages were indexed and 20 were not. Comparing the verdicts against the previous week's readings, **ten live pages moved from indexed to crawled, currently not indexed between 1 and 8 September 2026.**

- All ten returned HTTP 200 when checked by hand on 10 September.
- None of them carried a `noindex` directive.
- None had a content change in the window. The only commits touching them were an edge-cache duration change and a database query optimisation, neither of which alters a single rendered word.
- **Six of the ten were glossary definition pages.**

That last point needs its denominator, which is the number most write-ups of this kind leave out. **Glossary entries are 60 of the 191 pages inspected**, so they are 31 per cent of the sample and you would expect roughly three of any ten. Six is double that, and at a sample of ten it is still only about a one in seventeen result by chance. Call it suggestive. It is not a pattern, and ten events cannot make it one.

The pages were `/glossary/chunking`, `/glossary/embedding`, `/glossary/grounding`, `/glossary/knowledge-graph`, `/glossary/prompt-volume`, `/glossary/ai-hallucination`, `/compare/semrush`, `/blog/how-ai-crawlers-read-your-site`, `/tools/ai-readiness-score` and `/contact`. A check on 1 September would have called all ten indexed. A check on 8 September called none of them indexed. **All ten were still unindexed when the verdicts were re-read on 10 September**, so this is a drop that held for at least two more days rather than the day-to-day flicker described below.

Two caveats, because this is one site and ten pages. This is a documented instance rather than a study, far too small to support a claim about Google's behaviour at scale, and we are not making one. We also found a cleaner-looking example and threw it out: two pages appeared to leave the index on 22 August and return on 23 August, but both are trailing-slash legacy URLs that redirect, so the readings reflected the redirect rather than an index decision.

## Is Google deindexing more pages in 2026?

Nobody can answer that with confidence yet, and the disagreement is the interesting part. Since the start of April 2026, large numbers of SEOs have reported pages leaving Google's index at unusual rates. Google's position is that nothing exceptional is happening.

John Mueller, posting on Bluesky on 30 April 2026, said **"I don't see anything exceptional there"**, adding that some sites go up and some go down.

A second explanation came from the SEO community rather than from Google. Valentin Pletzer, checking reported URLs by hand and finding them present in the index, asked whether the reports might be a Search Console reporting bug rather than real removal.

That is a fair question, and it is the one our ten pages answer directly. **These verdicts were read through the URL Inspection API, on URLs independently confirmed as live, returning 200 and carrying no **`**noindex**`**.** A reporting artefact would have to survive that check. It does not settle the wider argument, and it does make these ten cleaner than most of what is being reported.

There is a documented precedent and its date matters. Indexing Insight found that across 2 million monitored pages, 25 per cent were actively removed from Google's index, with individual sites losing between 15 and 75 per cent of theirs. That measurement describes an event at **the end of May 2025**, not 2026, and it is widely re-quoted without that date attached.

A separate review of around 40 sites over the same 2025 period found the removed pages were mostly ones Google would be unlikely to serve to anyone. Six of our ten were thin definitional pages, which is the same shape observed independently fifteen months later.

## What each Search Console index verdict actually means

The Page indexing report groups unindexed pages by reason, and the reasons are not equally worrying. Google documents each one, and the two people worry about most are the two Google explicitly says need no action.

| Verdict | What Google says it means | Does it need fixing? |
| --- | --- | --- |
| Crawled, currently not indexed | The page was crawled by Google but not indexed. It may or may not be indexed in the future; no need to resubmit this URL for crawling | Not directly. It is a quality judgement, so the fix is the page, not the request |
| Discovered, currently not indexed | The page was found by Google, but not crawled yet. Typically Google wanted to crawl the URL but this was expected to overload the site, so the crawl was rescheduled | Check server response times and crawl budget |
| Duplicate without user-selected canonical | The page is a duplicate of another page and does not indicate a preferred canonical. Google has chosen the other page and will not serve this one | Optional. Set a canonical, or make the pages genuinely different |
| Alternate page with proper canonical tag | The page is marked as an alternate of another page, that is, an AMP page with a desktop canonical or a mobile version of a desktop canonical. It correctly points to the canonical page, which is indexed, so there is nothing you need to do | No. Working as intended |

Read the first row carefully, because it is the one that generates the most wasted effort. **Crawled, currently not indexed is not an error.** Google reached the page, looked at it, and decided not to store it. Resubmitting it through Request Indexing does not change the judgement, which is why Google's own text tells you not to bother. The page has to become more worth indexing, or it stays out.

## How to find out when a page was first indexed

Honestly: you mostly cannot, and every widely-repeated trick for it has decayed. Google Search Console does not expose the date a page was first indexed. URL Inspection gives you the **last** crawl date, not the first index date, and the Page indexing report shows counts over time rather than per-URL history.

The advice circulating for this question is mostly a decade old. The most-repeated version tells you to narrow results with the Search Tools date filter and read the date off what appears. That was never reliable: it reflects when Google will show a result for a date range, not when Google indexed the page.

A second version points at the About this result panel, and it is a category error. The month and year that panel reports is when Google first indexed the **site**, not the page, so it cannot answer a page-level question however carefully you read it. It also stops resolving at ten years, reporting anything older as more than ten years ago, and it surfaces only where Google has no Wikipedia description to show instead.

The workable answer is to stop recovering history and start recording it. An index verdict is cheap to capture and only meaningful as a series, so the useful artefact is a **per-URL index status history**: the verdict for every page, captured on a schedule, with each transition dated.

That is how we knew 10 pages left the index inside one seven-day window, rather than noticing months later that a traffic line had bent. Without a recorded series, the first you hear of a page leaving Google's index is when somebody asks why it stopped converting.

## Crawling and indexing are not the same thing

The difference is what Google does with the page after it arrives. Crawling is Google fetching the page. Indexing is Google deciding to keep it in the Google index. All search engines separate the two steps, they fail separately, they are diagnosed separately, and conflating them sends people to fix the wrong thing.

- **Not crawled** means Googlebot never fetched the URL. Causes live in [robots.txt](/glossary/robots-txt), server errors, redirect chains, or a page nothing links to. Look at the fetch status.
- **Crawled but not indexed** means the fetch worked and the judgement went against you. Nothing in your server configuration will fix it.
- **Indexed but not ranking** means you passed both tests and lost on relevance or competition. That is a content and authority problem, not an indexing one.

A useful consequence: blocking a URL in [robots.txt](/glossary/robots-txt) does not remove it from the index. It prevents crawling, and a page Google cannot crawl is a page whose `noindex` Google can never read. To remove a page from the index, allow the crawl and serve `noindex`, then keep the crawl allowed until the removal registers.

## How to get a page indexed

The mechanics are unglamorous and there is no lever that forces the decision. In rough order of how much they actually move things:

1. **Link to it from a page that is already indexed and crawled often.** Internal links are the strongest discovery route you control, and a page with no inbound internal links is close to invisible whatever its quality.
2. **Include it in your **[**XML sitemap**](/glossary/xml-sitemap) with an honest `lastmod`. A sitemap is a discovery aid, not an instruction, and it guarantees nothing.
3. **Use Request Indexing in Search Console** for a genuinely new or genuinely changed page. It queues a crawl, it does not buy an indexing decision, and using it repeatedly on the same URL achieves nothing.
4. **Make the page worth indexing.** For anything sitting in crawled, currently not indexed, this is the only step that matters.

Two shortcuts get recommended constantly and neither does what people think. Google's [Indexing API](https://developers.google.com/search/apis/indexing-api/v3/quickstart) is documented as usable only to crawl pages with either `JobPosting` or `BroadcastEvent` embedded in a `VideoObject`, so it is not a route for ordinary pages, and its onboarding quota is 200 queries a day.

That restriction is worth dwelling on, because the page currently ranking best for this question disputes it. CrawlWP acknowledges Google's official position and then tells readers the API works for any content type regardless, while selling a WordPress plugin from 59 dollars a year that submits ordinary URLs through it.

Google's wording is that the API **can only be used** for those two types. Whatever the endpoint accepts today, sending it content it is not documented to serve is a risk you are choosing rather than a technique you have found, and the party who decides how that ends is Google.

**IndexNow** is a genuine push protocol with real adoption, but its own FAQ lists the participants as Amazon, Bing, Naver, Seznam.cz, Yandex and Yep. Google is absent, and has been since it said it would evaluate the protocol in late 2021. Implement IndexNow for Bing if Bing matters to you, and expect nothing from it in Google.

## How to check indexed pages across a whole site

Checking one URL by hand does not scale past about 20 pages. The Search Console **URL Inspection API** returns the same verdict as the tool, programmatically, and its [published quotas](https://developers.google.com/webmaster-tools/limits) are the thing to plan around. The daily ceiling is the one that binds; at 600 queries a minute, the rate limit almost never does.

| Limit | Per site | Per project |
| --- | --- | --- |
| Queries per day | 2,000 | 10,000,000 |
| Queries per minute | 600 | 15,000 |

The per-site figure is **per verified property, not per account**, which is the detail that decides how you shard the work. At 2,000 queries a day, a site of 10,000 pages takes five days for one full sweep.

So most people sample rather than sweep: inspect the pages that earn money daily, and rotate the long tail weekly. Whatever runs the sweep, **store each verdict with the date you read it**. Search Console shows you today's answer and not last week's, so the comparison that produced this article's ten pages only exists if something kept both readings. RankX AI does that on a schedule, and [the index coverage docs](/docs/traffic/indexing) describe what it reads and how often.

## Indexing decides AI visibility too

Being indexed is no longer only about blue links, and this is the part most indexing guides miss entirely. Google's [AI Overviews](/glossary/ai-overview) and [AI Mode](/glossary/google-ai-mode) draw on Google's index: a page must be indexed and eligible to be shown with a snippet to be cited in either. A `noindex` directive therefore removes a page from AI Overviews as surely as it removes it from search results, and restrictive snippet controls cap what those features may quote from you.

It also cuts the other way, which surprises people. Google's crawler documentation states that **Google-Extended does not impact a site's inclusion in Google Search nor is it used as a ranking signal in Google Search.** Blocking it opts you out of Gemini training and grounding and leaves AI Overviews untouched. Those are separate controls for separate systems, and blocking the wrong one is a self-inflicted wound.

Beyond Google, the assistants run indexes of their own. [OAI-SearchBot](/glossary/oai-searchbot) builds the index behind ChatGPT search, Claude-SearchBot does the same for Claude, and [PerplexityBot](/glossary/perplexitybot) for Perplexity. Each holds its own view of your site with its own inclusion decision, and none of them reports into Search Console.

The practical position is that **Search Console answers one indexing question and there are several**. Whether the AI crawlers can reach you at all is a separate check, which [our AI crawler access checker](/tools/ai-crawler-access-checker) answers, and [how AI crawlers read your site](/blog/how-ai-crawlers-read-your-site) covers what they do once they arrive.

## How long does Google take to index a new page?

Google's own documentation gives one range and it is narrower than most articles claim: crawling can take anywhere from a few days to a few weeks. Be sceptical of anything more precise. The averages published around this question, the ones quoting a specific number of days for new sites or for e-commerce pages, are generally unattributed and not reproducible, so treat them as folklore rather than measurement. The variable that moves it most is whether Google has a reason to come back, and no setting in Search Console exposes that.

## What does it mean when Google has indexed a page?

It means Google has fetched the page, processed it, and stored it in the Google index so it is eligible to appear in search results. Search engines keep only a fraction of the web pages they crawl, so this is a decision rather than a formality. Eligible is not the same as ranking: an indexed page can sit in the index for months without being shown for anything, because indexing decides whether you can appear and ranking decides whether you do. It also means the page can be quoted in AI Overviews and AI Mode, which draw only on indexed, snippet-eligible pages.

## Why does the URL Inspection tool disagree with the Page indexing report?

Because they are different data paths with different refresh cycles. URL Inspection queries the live index for one URL at the moment you ask. The Page indexing report is an aggregated view that lags, typically by days. When they disagree, the URL Inspection verdict is the more current one for that single URL. That gap is worth knowing during the 2026 deindexing reports, because some observers have suggested those reports may partly reflect a Search Console reporting problem. Whatever the answer, inspecting a handful of the affected URLs directly is the check that does not depend on the aggregate being right.

## Can I use Google's Indexing API to get my pages indexed faster?

Almost certainly not. Google's documentation states that the Indexing API can only be used to crawl pages with either JobPosting or BroadcastEvent embedded in a VideoObject. It is not for blog posts, product pages or ordinary web content, and the default quota for onboarding and testing is 200 calls. Services that offer to push arbitrary URLs through it are using it outside its documented purpose. For everything else, the tool Google intends you to use is Request Indexing in Search Console.

## Does IndexNow work for Google?

No. IndexNow is an open push protocol created by Microsoft and Yandex, and the participants listed on its own FAQ are Amazon, Bing, Naver, Seznam.cz, Yandex and Yep. Google is not among them. Google said in late 2021 that it would evaluate the protocol and has never adopted it for general web indexing. IndexNow is still worth implementing if Bing and the other listed engines matter to you, and it costs almost nothing to add, but it will not affect how quickly Google finds your pages.

## Does submitting a sitemap guarantee that Google will index a page?

No. A sitemap is a discovery aid, not an instruction. It tells Google which URLs exist and when they last changed significantly, which helps Google find pages that internal linking alone might not reach. It creates no obligation to crawl or index any of them. A page that is in your sitemap and still not indexed has usually failed on a different test, most often that Google fetched it and judged it not worth storing, which Search Console reports as crawled, currently not indexed.

## Is it a problem if some pages are not indexed?

Often not. Google's own guidance on crawled, currently not indexed says the page may or may not be indexed in future and that there is no need to resubmit the URL. Plenty of pages should not be indexed at all: paginated archives, filtered views, thin utility pages and anything you have deliberately marked noindex. The question worth asking is not how many pages are unindexed but whether the unindexed ones are pages you actually needed in search. A missing product page matters, a missing tag archive does not.