How to check if a page is indexed by Google

Search for the exact URL first

Type or paste the complete address, including the scheme, into the search box. A result means the URL is in the index. No result means it is not, or that it is indexed under a different URL that Google chose as canonical.

This works without any account, on any site, including sites you do not own. It is the check to run before anything more elaborate, because a surprising share of "my page is not indexed" reports end here with the page sitting in the index all along, ranking too low to have been noticed.

Use the site: operator for a rough count

The site: operator restricts results to one host or one path:

site:example.com
site:example.com/blog/
site:example.com inurl:product

Treat the count it reports as an estimate, not as data. It is generated for speed, it varies between runs, and it can be off by an order of magnitude on a large site. What it is good for is shape: a site with 4,000 pages showing a handful of results has a site-wide problem, and a path that returns nothing while its siblings return results points at one template or one section.

Use URL Inspection for the real answer

For a property you have verified in Search Console, URL Inspection is authoritative. It reports whether the URL is on Google, the canonical you declared next to the canonical Google actually selected, the last crawl date, the crawling user agent, and whether indexing is allowed. When a page is not indexed, this is where the reason is named rather than guessed at.

Two limits are worth knowing. The tool reports the state of the last index attempt, so it lags a change you made an hour ago, and "Test live URL" fetches the page now but does not change the indexed state. Requesting indexing after a genuine fix is reasonable; requesting it repeatedly does not accelerate anything.

What "Discovered - currently not indexed" means

Google knows the URL exists, from a link or a sitemap, and has not crawled it yet. This is a crawling decision rather than a quality verdict, and the usual reasons are volume and capacity: a large number of new URLs appeared at once, the server has been slow or returning errors, or the URL is buried deep in the internal link structure.

What helps is making the page cheaper and more obviously worth fetching. Link to it from pages that are already crawled often, keep the server fast under crawler load, and remove the low-value URLs that are consuming the same budget, such as parameter permutations and empty filter combinations.

What "Crawled - currently not indexed" means

Google fetched the page and chose not to index it. That is a quality or duplication judgment, not a technical fault, and no amount of resubmitting changes it. The realistic responses are to make the page substantively better than what already ranks, to merge it into a stronger page and redirect, or to accept that a thin listing page does not need to be in the index.

The related verdict "Duplicate, Google chose different canonical than user" is a different problem with the same symptom: the page is indexed, under another URL. Compare the declared and selected canonicals in URL Inspection before treating it as a missing page.

Check the on-page signals that block indexing

Three technical causes account for most pages that genuinely cannot be indexed, and all three are visible in the page you serve:

1. A noindex directive, in a meta tag or the X-Robots-Tag header. See what noindex does.
2. A canonical pointing elsewhere, which asks for the page to be folded into another URL. See what a canonical URL is.
3. A robots.txt rule blocking the path, which prevents the crawl entirely. See how to check robots.txt.

Checking those one URL at a time is where this stops scaling, because the cause is almost always a template rather than a page, and the affected URLs are the ones nobody thought to inspect.

Check the whole site at once

The free site crawl tool walks the site from a starting URL and reports, per page, whether it carries a noindex flag, whether a canonical is missing or points at a different URL, and which pages are duplicates of each other by body content, so a template-level block shows up as a block of rows instead of one unlucky page. Keeping those signals under continuous watch, alongside uptime, certificates and domain expiry, is what a website monitoring service does.