How to Check When Google Indexed a Page

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:

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 (opens in a new tab), 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.

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, 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 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 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 (opens in a new tab) 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 (opens in a new tab) 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.

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 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 and 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 builds the index behind ChatGPT search, Claude-SearchBot does the same for Claude, and 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 answers, and how AI crawlers read your site covers what they do once they arrive.