How to Tell If a Page Is Indexed by Google

A lot of people still start with a site: search. It is quick, but it is also where a lot of indexing checks go wrong.

If I need a real answer, I inspect the exact URL in Google Search Console first. That tells me whether the URL is actually on Google, whether Google picked a different canonical, and whether this is a basic technical block rather than a true indexing issue.

The mistake I see most often is simple: people check one URL variant while Google is indexing another, then spend an hour arguing about the wrong page.

Most of the time, the problem ends up being one of three things: the exact URL is indexed, the content is indexed under another canonical, or the page is crawlable but still not indexed.

Quick answer: how to check if a page is indexed

If you only want the short version, do this:

1. Inspect the exact URL in Google Search Console URL Inspection.
2. Check whether Google says “URL is on Google” and whether it picked the same canonical you intended.
3. If not, check the dull stuff next: noindex, X-Robots-Tag, robots.txt, redirects, and whether the URL really returns 200.

Google’s own URL Inspection documentation is still the best reference if you want to verify what each status means: https://support.google.com/webmasters/answer/9012289

Can you use site: search to see if a page is indexed?

You can use a site: search, but I only treat it as a rough signal.

Typical quick checks:

site:example.com/page-url

or:

site:example.com "title fragment"

If the page shows up, that is useful. If it does not, I still would not call the page unindexed from that alone.

I have seen site: miss pages that URL Inspection already showed as indexed. I have also seen teams think a page was indexed when Google had actually kept a different canonical.

Google says the same thing in its site: operator documentation: the results are not comprehensive. https://developers.google.com/search/docs/monitor-debug/search-operators/all-search-site

How I would check it in practice

When I am not sure what is going on, I usually narrow it down fast: am I looking at the right URL, is there an obvious technical block, or is Google just not seeing enough reason to keep the page?

1. Am I checking the exact URL Google is evaluating?

I start by checking the URL variant itself:

• https vs http
• www vs non-www
• trailing slash vs no trailing slash

This is where a lot of false alarms start. One team member checks the slash version, someone else checks the non-slash version, and the whole conversation drifts before anyone looks at what Google is actually storing.

Right after that, I look at Google-selected canonical. If Google picked another canonical, the content may be indexed while the exact URL I care about is not. That is usually where the conversation stops being “is it indexed?” and turns into “which version is Google actually keeping?”

Google’s canonicalization docs are still worth checking here if the signals feel mixed: https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls

2. Is there a simple technical reason the page is excluded?

If GSC says the page is not on Google, I do not jump to content quality first. I check the dull stuff:

• noindex in a meta robots tag
• X-Robots-Tag: noindex
• robots.txt blocking the crawl path
• a non-200 response
• redirect hops that point Google somewhere else

None of this is advanced, but this is still where a lot of teams lose time, especially when the page looks fine in the browser and the real issue is a stale canonical, a redirect hop, or an old internal link pattern. One messy version of this is a URL that returns 200 but quietly points Google somewhere else through canonical or redirect signals.

If you need the exact rules on crawl blocking, Google’s robots.txt docs are here: https://developers.google.com/search/docs/crawling-indexing/robots/robots_txt

3. Is this really an indexing problem, or a discovery/value problem?

A successful live test only proves Google can fetch the page right now. It does not prove Google wants to keep it in the index.

This is where the question changes. At that point I am not asking whether Google can fetch the page anymore. I am asking why Google would keep it. Thin programmatic pages, posts only linked from paginated archives, and city pages generated from the same template are the ones I get suspicious of first.

If rendering is part of the suspicion, Google’s JavaScript SEO basics are still useful background: https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics

If the page is technically clean but still not indexed, I use two supporting checks:

• Is the page linked from relevant, crawlable pages?
• Is it in your XML sitemap?
• Does it receive only weak footer or archive links?
• Is it competing with several near-duplicate URLs?

If GSC and search results do not match

When GSC and search results do not seem to match, I trust URL Inspection first and then narrow the question. Am I looking at the exact URL I care about, or just a version of the content that Google chose differently?

If Inspection says the URL is on Google, I stop treating it as a pure indexing problem. If it says the URL is not on Google but Google selected a different canonical, I treat it as a canonical issue first. Only when the canonical matches and the page is still excluded do I move into discovery, duplication, or page-value questions.

If the page is indexed but still flat on impressions, move to Page Indexed But Not Ranking? What to Check Next. If Google is grouping the page into the wrong topic cluster, the better next read is Why Google Isn’t Understanding Your Page.

One case that changed how I explain this

One case that changed how I explain this started with a disagreement inside the team. Search results still showed the post title, so everyone assumed the preferred URL was indexed. But the slash version and the non-slash version were telling different stories in Search Console.

The first thing that threw people off was that the page looked healthy everywhere obvious. It loaded fine, the sitemap already had the slash version, and a title search still returned the post. The preferred URL was /blog/post/, but older cards and the related-posts module were still linking to /blog/post. That made it look like a slow indexing problem when it was really a signal conflict.

The moment the direction changed was when URL Inspection kept showing Google-selected canonical leaning toward the older pattern even after the sitemap had been refreshed. We spent a bit of time rechecking sitemap freshness and earlier indexing requests before admitting the internal signals were still split. Once the internal links, canonical tag, and redirect behavior all pointed to the same URL, the preferred version started replacing the old one within a few days. The page was not missing. We were checking the wrong version of “indexed.”

Mistakes to avoid

I would not rewrite a page just because site: search looks weird once.

I would not keep hitting “Request indexing” every time I make a small edit.

If the page is already on Google but still flat, that is usually a different conversation:

• Page Indexed But Not Ranking? What to Check Next

If you have already confirmed the index status and need the next layer of diagnosis, these are the two pages I would open next:

• GSC URL Inspection Tool Guide
• Why Your Page Isn’t Indexing (2026 Checklist)

FAQ

How do I know if a page is indexed by Google?

Use Google Search Console URL Inspection. If it says “URL is on Google”, that is the answer.

Can I check it without Search Console?

You can use a site: search such as site:example.com/page-url, but I would only treat that as a clue.

Live test works, but the page is still not on Google. Why?

Usually Google can fetch the page, but still has not chosen to index it. That points more to canonical confusion, weak discovery, duplication, or page value than to a crawl failure.

GSC picked a different canonical. What do I fix first?

Fix the signals that reinforce Google’s choice: internal links, canonical tags, redirects, and sitemap URLs. If those disagree, Google has a reason to keep picking the wrong version.