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.

Before concluding that Google dropped a page, run four checks on it, because each one rules out a cause that has nothing to do with an index decision:

• Fetch the page by hand and confirm it returns HTTP 200.
• Confirm it carries no noindex directive.
• Check whether anything in the window changed the rendered content, rather than only the code around it.
• Re-read the verdict a few days later, because a page that comes straight back was a flicker rather than a decision.

Exclude redirects before you count anything. A legacy URL that redirects, such as an old trailing-slash address after a migration, can appear to leave the index one day and return the next, and that reading reflects redirect handling rather than an index decision. When a live page passes all four checks and stays out, Google has made a quality judgement, and the verdict table below says what each one means.

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 a site owner can answer it for their own pages. Read the verdicts 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 makes your own readings 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.

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.

A recorded series shows a page leaving the index in the week it happens, rather than months later when a traffic line has bent. Without one, the first you hear of a page leaving Google's index is when somebody asks why it stopped converting. Deindexing is one of five causes worth ruling out when positions fall, and diagnosing a Google rankings drop sets out the other four in the order to check them.

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 a week-on-week comparison 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.

One free shortcut narrows the list before you spend a single quota unit. A page earning impressions in the Performance report is a page Google has indexed, so anything with impressions can be skipped. That leaves the silent pages to inspect, and reading impressions with no clicks explains what the remaining numbers do and do not prove.

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.

Bing runs the other index worth checking, because Microsoft grounds Copilot on it and Bing applies a selection step Google does not describe in the same terms. A site Google indexes freely can still be largely absent from Bing, and Bing indexing and the inbound links warning covers how to read that gap.

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.