How to Check If a Page Is Indexed by Google (5 Reliable Methods)

What does "indexed" actually mean?

Before you can check whether a page is indexed, it helps to be clear about what the word means, because people use it loosely. A page is indexed when Google has crawled it, processed what it found and stored a record of it in the search index, the giant database it draws on to answer queries. Only pages in that database can appear in results.

Indexed isn't the same as ranking. A page can sit in the index and never show for a single query, because other pages answer those queries better. Think of indexing as the entry ticket and ranking as the seat you get once you're inside.

How does a page get into the index?

Google discovers a URL, usually by following links or reading a sitemap, then schedules a crawl. After crawling, it analyses the content, works out what the page is about, checks for duplicates and decides whether to keep it. Plenty of discovered or even crawled pages don't make the cut, which is why statuses such as crawled, currently not indexed exist.

Each stage can fail for different reasons, so a good check tells you not only whether the page is indexed, but where in the journey it stalled.

A quick map of the journey

Discovered, then crawled, then processed, then indexed, then eligible to rank. Checking indexing tells you how far a URL got.

Why do you need a reliable check?

Because the quick-and-dirty methods mislead. A site: search can omit pages that are indexed, and a query can fail to show a page that's present. Basing decisions on those checks leads to wasted fixes and panicked requests. Using the right tool gives you evidence that you can act on.

Which five methods can you rely on?

There are several ways to check, and each suits a different situation. Knowing which to use saves time.

The first two are the workhorses. The others are supporting tools.

What are the five methods at a glance?

The right approach is usually to combine them: use the report to find patterns and the inspection tool to understand individual URLs.

Which should you start with?

If you have access, start with URL Inspection for a single page, and the page indexing report for anything more than a handful.

What if you don't have Search Console?

Set it up. Verifying a site takes minutes, and it's the single most useful free SEO tool. Without it, you're guessing. If you're checking a client's or competitor's site and can't get access, a site: search and a few targeted queries give you a rough signal, but treat the result as an indication, not proof.

Owning these accounts matters, and the question of what access an SEO consultant should have covers how to share them safely.

How do you use the URL Inspection tool?

The URL Inspection tool is the most precise way to see what Google knows about a single address. It's built into Search Console, and Google's help page for the URL Inspection tool documents what it reports.

Here's how to use it well.

What are the steps?

Open Search Console and select the property that contains the URL. Paste the full address into the inspection bar at the top and press enter. Wait a few seconds while the tool retrieves Google's record. Read the verdict at the top, then expand each section for detail on coverage, canonicals, crawl and indexing permissions.

The URL must belong to the selected property, including the right protocol and host. A common error is inspecting the www version in a property set up for the non-www domain, which returns a confusing "not in property" message. Use a domain property if you want everything covered.

Use the exact address

Include the protocol, the host and any trailing slash exactly as the page is served. Close variants are different URLs to Google.

What does the tool show?

Google's documentation lists several elements. The indexed status gives the overall verdict. The last crawl shows when Google fetched the page, in your local time, and all displayed information comes from that crawl, so it may be out of date. The canonical section shows the user-declared canonical and the Google-selected canonical, which can differ. "Crawl allowed?" says whether robots.txt lets Google fetch the page. "Indexing allowed?" says whether the page forbids indexing, for instance with a noindex tag.

Reading those fields together usually explains the situation. A page that's crawl-allowed, indexing-allowed, canonical to itself and still not indexed points toward quality or duplication. A page where indexing isn't allowed points to the noindex tag.

A caution about robots.txt

If robots.txt blocks crawling, Google's documentation says the "Indexing allowed?" field always shows yes, because Google can't see any noindex directive. Always read "Crawl allowed?" first.

How do you read the verdicts?

The headline verdict is short, and each phrase has a specific meaning. Misreading them is easy, so it's worth slowing down.

Four main outcomes appear.

What do the main verdicts mean?

"URL is on Google" means the page is indexed and eligible to appear in results. Google's documentation is careful to say that's not a guarantee that it will appear. "URL is on Google, but has issues" means the page is indexed but something, such as a structured data problem, needs attention. "URL is not on Google" means the page isn't indexed, and the details explain why. "URL is an alternate version" means Google treats the page as a duplicate of a preferred version.

Each verdict leads to a different next step. Indexed pages move on to performance questions. Not-indexed pages need diagnosis. Alternates need a canonical review.

What "never seen" means

The Page indexing section can also report that Google has never seen the URL. In that case, check that the page is linked internally and listed in your sitemap, and that nothing is blocking discovery.

What do the reasons look like?

For pages that aren't indexed, the report names a reason, such as "Excluded by 'noindex' tag," "Blocked by robots.txt," "Duplicate without user-selected canonical," "Soft 404," "Crawled, currently not indexed" or "Discovered, currently not indexed." Each is a different problem with a different fix.

A short reference to the most common ones: a noindex exclusion is a directive you can remove. A robots.txt block is a crawl rule you can change. A soft 404 is a content or status problem. A crawled-not-indexed status is a value judgement. A discovered-not-indexed status is a crawl scheduling story, covered in discovered, currently not indexed.

Don't fix before you diagnose

Matching the reason to the right fix saves effort. Rewriting content won't help a page that carries a noindex tag.

What's the difference between the indexed version and the live test?

The inspection tool offers two views, and confusing them is a classic mistake. They answer different questions.

Knowing which you're looking at prevents false alarms.

What does each view show?

The indexed version reflects the most recent copy Google stored, not the page as it is today. It's the answer to "what does Google have on record?" The live test fetches the URL in real time, so it shows whether Google can access the page now and how it renders. It's the answer to "can Google read my page today?"

If you've just fixed a problem, such as removing a noindex tag, the indexed version will still show the old state until Google recrawls. The live test will show the fixed state immediately. That's how you confirm a fix before the index catches up.

What the live test doesn't check

Google's documentation says the live test doesn't check sitemaps, referring pages, duplicates, manual actions, quality guidelines or content removals, and that a passing test doesn't guarantee indexing. It only suggests the page can probably be indexed.

How do you use both together?

Inspect the indexed version first to see what Google last recorded. Run the live test to see the present state. Compare the two. If they differ, you know your change hasn't been processed yet. If both show the same problem, the problem is current. If the live test passes and the indexed version fails, request indexing and wait.

For pages that render with JavaScript, use the live test's rendered HTML and screenshot to check that the main content appears. If it doesn't, indexing problems may follow, which the guide to JavaScript SEO and rendering checks explains.

Keep a record

Note the date, the verdict and any changes. A short log makes it easy to see whether something improved after a fix.

How do you check indexing at scale?

Inspecting URLs one by one works for a handful of pages. For a whole site, you need the reports.

They answer the bigger question: how much of what I care about is indexed?

How does the page indexing report help?

Open Indexing, then Pages. The report splits your known URLs into indexed and not indexed and lists the reasons for exclusion with counts and sample URLs. Use the filter to switch between all known pages, all submitted pages or a specific sitemap. Focusing on submitted pages cuts out the noise from accidental URLs and shows the status of pages you asked Google to consider.

The trend chart shows whether the numbers are moving. Sudden changes usually coincide with a site change, a release or a Google update, and they're worth investigating the same week.

Export for deeper work

Export the lists of URLs under each reason. A spreadsheet grouped by URL pattern turns thousands of rows into a handful of decisions.

How do you use the sitemaps report?

Submit a sitemap and compare the submitted count with the indexed count using the sitemap filter in the page indexing report. A big gap points to a problem. Splitting sitemaps by section, such as products, categories and blog posts, shows which part of the site struggles. A clean sitemap also acts as a cleaner baseline, which the guide to XML sitemap best practices covers in detail.

If the sitemap report shows errors, fix those first. Google can't use entries it can't read. The common ones are covered under sitemap errors in Search Console.

Watch the ratio, not the total

The share of important URLs that are indexed matters more than the raw number. A shrinking total can be good news if you removed junk.

Can you check with a site: search or a normal query?

You can, and it's tempting, because it needs no tools. Just keep its limits in mind.

Think of it as a hint, not a verdict.

How does a site: search work?

Typing `site:example.com/page-url` into Google shows whether Google returns that address. If the page appears, it's probably indexed. If it doesn't, the result isn't conclusive. The operator isn't designed as a diagnostic, results can vary, and pages that are indexed sometimes fail to appear for it.

Use it for a quick sanity check, then confirm anything that matters with Search Console. Never conclude that a page is missing from the index solely because a site: query didn't show it.

Why results can differ

Search results are personalised and varied by location and device, and the operator returns only a sample. It's a convenience, not a database query.

What about searching for the page's title or a unique phrase?

Searching for an exact title or a distinctive sentence in quotation marks is slightly better. If the page appears, it's indexed. If it doesn't, it may still be indexed but outranked by copies or similar pages, so absence isn't proof.

This approach is also useful for spotting scrapers and duplicates: if other sites rank for your text and you don't, that's a clue worth following. It's a pointer, not a diagnosis.

What should you do if the page isn't indexed?

A not-indexed verdict is a prompt to investigate, not a reason to panic. Work through a short sequence.

Each step rules out a cause.

What's the diagnostic order?

First, confirm the page returns a 200 status and loads properly. Second, check for a noindex directive in the tag or header. Third, check whether robots.txt blocks it. Fourth, check the canonical: is the page pointing to itself, or to something else? Fifth, check internal links: is the page linked from relevant, indexed pages? Sixth, check the sitemap. Seventh, assess quality and uniqueness honestly.

That order goes from technical blockers to value signals. Most problems appear in the first four steps, and they're the cheapest to fix.

A common finding

Pages that were launched with a staging directive, a plugin setting or a template rule still in place. Fixing the directive resolves the issue without touching content.

When does it come down to quality?

When everything technical checks out and Google still declines, the verdict usually reflects value. The page may be thin, repetitive, near-duplicate or lacking a clear purpose. Strengthen it with substance that's specific to your business, and link to it from relevant pages. The reasoning behind that judgement is explained under crawled, currently not indexed.

For pages Google hasn't crawled yet, the picture is different. Work on discoverability: internal links, sitemap entries and server health, as described in discovered, currently not indexed.

Be honest about the page

Ask whether you'd be happy to see this page as the top result for its main query. If not, improve it before you push for indexing.

How does requesting indexing work, and when should you use it?

Requesting indexing is the button everyone presses. It helps in specific situations, and it's useless in others.

Understanding the limits saves you from repeating it fruitlessly.

What does Google say about requests?

Google's help page says you can request indexing from the inspection result page. Google runs a quick check first, and pages that are non-indexable in the live test can't be submitted. Indexing usually takes about a day but can take longer, and submitting a request doesn't guarantee the page will appear in the index. Each property has a daily limit on inspection requests and live tests.

For many new or updated pages, Google's recommendation is to submit a sitemap with accurate lastmod values instead of requesting each URL individually. That scales better and signals freshness more reliably.

When a request makes sense

Use it for a few high-priority pages after a genuine improvement: a new service page, a fixed noindex error, a significant rewrite. Don't use it as a daily habit.

What if the request doesn't work?

Check that the live test passes. Make sure the page is linked internally and in the sitemap. Review quality and duplication. Then wait. Repeated requests don't change a decision based on value, and they use up your quota. If nothing changes after a few weeks, revisit the diagnosis, because something else is holding the page back.

How do you check other types of content?

Pages aren't the only things in the index. Images, videos and documents have their own paths, and the checks differ slightly.

For most business sites, the main concern is pages, but it's useful to know.

How do you check images and videos?

For images, check that they're embedded in indexable pages with sensible alt text and descriptive filenames, and that they aren't blocked. The page indexing report covers pages, while Search Console's performance report can be filtered by search type, such as image, to see impressions. For video, Search Console has a video indexing report that lists pages with videos and reasons for non-indexing.

If you use an image or video sitemap, it helps Google find files it might otherwise miss, though ordinary embedded media on well-linked pages is usually discovered without one.

Remember dependencies

Images and videos are indexed through the pages that host them. If the host page isn't indexed, neither is its media.

What about PDFs and other files?

PDFs and other documents can be indexed. The X-Robots-Tag header can control them, as described in the guide to the noindex tag. Inspect their URLs with the tool as you would a page. If a PDF should stay out of results, apply a header rule, and if it should be found, link to it from indexed pages.

How long should you wait before worrying?

Timing questions come up constantly. The honest answer is "it depends," and it depends on identifiable things.

Setting expectations avoids unnecessary alarm.

What's a typical timeline?

For an established, well-linked site that publishes regularly, new pages are often discovered and indexed within days. For a brand-new site, it can take longer, because Google has less history and fewer links to go on. Pages deep in a site, or with few internal links, may wait longer. Google's own guidance says indexing after a request usually takes about a day but can take longer, and that there are no guarantees.

If weeks pass for an important page on a healthy site, treat it as a signal to investigate. If days pass for a brand-new page, be patient.

Speed levers you control

Strong internal links, a clean sitemap with accurate lastmod dates, fast server responses and genuinely useful content all help Google prioritise a URL.

What if a previously indexed page drops out?

Check what changed: a release, a plugin update, a template edit, a server move. Inspect the URL for noindex, canonical, status code and robots changes. Look at the page indexing report for the date the drop began. Roll back or fix whatever you find, then request indexing for key pages.

Sometimes pages fall out because Google reassesses their quality or because a duplicate has taken over. In that case, improve the page and its signals. For deeper investigations, a specialist technical SEO consultant can trace the cause across templates, headers and logs.

What does a worked example look like?

A concrete case ties everything together. This one is hypothetical, built from common patterns, and the details are illustrative.

It follows one page from suspicion to fix.

What was the problem?

A small London accountancy publishes a new page for its self-assessment service. Two weeks later, it doesn't appear for its own name plus the service, and a site: search shows nothing. The owner suspects Google is ignoring the page.

The owner pastes the URL into the inspection tool. The verdict says "URL is not on Google," and the details say indexing isn't allowed because of a noindex tag. A look at the page settings shows that the draft status of the plugin had left the "hide from search engines" option switched on after publishing.

The lesson

The problem was never quality or authority. It was a toggle. The inspection tool found it in thirty seconds.

How was it fixed and confirmed?

The owner switched the option off, saved and ran the live test, which now showed that indexing was allowed. They requested indexing once, added the page to internal links from the main services page and confirmed it was in the sitemap. A few days later the inspection tool reported "URL is on Google," and the page began to collect impressions in the performance report.

The routine, inspect, diagnose, fix, verify with the live test, request once, then monitor, works for almost every indexing question. If you'd like a systematic review of your site's indexing health, an SEO audit covers it alongside crawling, canonicals and sitemaps.

A one-minute checklist

Inspect the URL. Read crawl and indexing permissions. Check the canonical. Run the live test. Fix what you find. Request indexing once. Check again in a week.

Which mistakes make indexing checks misleading?

A few habits turn a simple check into a source of false alarms. Spotting them saves you from fixing things that aren't broken, and from missing things that are.

They're all easy to avoid once you know them.

Why is trusting a single signal risky?

Because each method has blind spots. A site: search can omit indexed pages. A rank tracker can show a page missing for one keyword while it's indexed. A third-party "index checker" may rely on its own sampling or an old snapshot. Search Console's data comes from Google's own records, but it reflects the last crawl, not the present moment.

Cross-check anything important. If the inspection tool says a page is indexed, and the performance report shows impressions, you can be confident. If a tool outside Google says the opposite, trust Google's data and treat the other tool as a lead to investigate.

The three-source rule

Confirm important findings with at least two independent signals before you change anything on the site.

Why does inspecting the wrong URL variant cause confusion?

Because http and https, www and non-www, and trailing-slash variants are distinct URLs. If you inspect the wrong one, you'll see a status for a page nobody visits. Always inspect the preferred, canonical version, and check that the others redirect or canonicalise properly.

Also watch for parameters and session identifiers copied from browser address bars. A tracking parameter can create a different URL from the one Google indexed, so strip them before you paste.

Check the canonical first

If the inspection result says Google selected a different canonical, the page you inspected isn't the one that counts. Look at the canonical target instead.

How do you build indexing checks into regular routines?

One-off checks fix today's problem. Regular checks stop the next one. A light, repeatable routine turns indexing from a surprise into a managed risk.

It doesn't need to take long.

What should a monthly check include?

Open the page indexing report and compare the indexed and not-indexed counts with last month. Scan the reasons for new categories or sudden jumps. Check the sitemap report for errors and discrepancies. Inspect a handful of your most important URLs: the homepage, top service pages, key product categories and recent articles. Note the results in a simple log.

If something looks odd, dig in the same week. The earlier you spot a change, the easier it is to link to its cause, whether that's a release, a plugin update or a Google change.

Make it a team habit

Share the results with whoever manages the site. When people see the numbers regularly, they notice problems sooner and understand what their changes do.

What about alerts?

Search Console sends email messages for significant issues, and you can set up additional monitoring with scheduled crawls or the Search Console API. A simple script that checks key URLs and flags a change in status is within reach of most developers, and it provides early warning that no manual routine matches.

Pair alerts with a documented response: who investigates, what they check first and how they record the outcome. A fast, calm response to an indexing problem is one of the best protections a business site can have, and it's the kind of discipline a good SEO consulting process builds into ongoing work.

What should you record after each check?

Write down the URL, the date, the verdict, the last crawl date, the canonical Google selected and anything you changed. Add the reason for the check, such as a launch, a complaint or a traffic dip. Over a few months, that log becomes a timeline you can lay against releases and Google updates, which makes the cause of a problem much easier to find.

It also helps colleagues and consultants pick up the thread without repeating work. A shared spreadsheet is plenty, and the discipline of filling it in tends to improve the quality of your questions as well as your answers.