Google Index Checker: Indexability Pre-check

Last updated: What’s new

Test a URL’s live technical indexability signals. This tool cannot see Google’s index; use Search Console URL Inspection for the indexed status Google has recorded.

No signup required. Technical scan results may be used to produce aggregate website statistics. Research records do not include your name, email, IP address, or analytics ID. Privacy details

Live technical pre-check only: no Google index or Search Console data is queried. Pick a status to get it explained against the live evidence.

What This URL Indexability Test Checks

The checker fetches one public URL as a diagnostic client and separates confirmed evidence from anything it could not determine:

  1. Redirect and response evidence: records each redirect hop up to the displayed limit, the final URL, final HTTP status, and content type.
  2. Googlebot directives: combines every generic robots meta tag, Googlebot-specific meta tag, and applicable X-Robots-Tag header.
  3. Robots.txt: evaluates the final path against Googlebot rules, including Allow, Disallow, wildcard, end-anchor, and longest-match precedence.
  4. Canonical target: reports the declared canonical and, for a different target on the same host, performs a bounded response, noindex, and robots check.
  5. Sitemap reference: checks advertised same-host sitemaps, or the conventional root sitemap when none is advertised, within strict document and size limits.

The fetch does not render JavaScript, imitate Google’s complete systems, assess content quality, or read Google’s index. Google’s URL Inspection documentation explains the difference between its indexed view and live test.

Technical Indexability Is One Gate, Not the Index

A crawlable 2xx URL without noindex can still be absent from Google, so use this result as a focused diagnostic:

  • Response and directives are observable: the tool can show what this server-side fetch received now, including scoped Googlebot directives.
  • Canonicalization is selected by Google: redirects and rel=canonical are strong preference signals, but neither proves which URL Google selected or indexed.
  • Sitemaps help discovery: inclusion can support discovery and canonical consistency, but Google explicitly describes sitemap submission as a hint rather than a guarantee.
  • Unknown stays unknown: a timeout, inaccessible robots.txt, cross-host canonical, oversized response, or sitemap limit is not displayed as a pass.

For the underlying rules, see Google’s documentation for robots meta and X-Robots-Tag, canonical signals, and sitemap guidance.

How to Diagnose “Google Is Not Indexing My Site”

Start with the exact affected URL, not an estimated domain-wide index count:

  1. Fix a non-2xx final response, redirect loop, or unintended redirect destination before interpreting page-level tags.
  2. Remove an unintended noindex from generic robots, Googlebot meta, or X-Robots-Tag. If robots.txt blocks crawling, Google may be unable to see a page-level noindex.
  3. Review a cross-canonical in context. Point it to the preferred duplicate only; do not assume every different canonical is an error.
  4. Keep preferred canonical URLs discoverable through internal links and, where appropriate, an XML sitemap. Missing sitemap inclusion alone does not prevent indexing.
  5. Inspect the exact URL in Search Console. Review the indexed status and Google-selected canonical, then run Test live URL after a fix and request indexing when appropriate.

A Google site: search is not exhaustive. Use it only as a secondary clue, never as the deciding index-status test.

When Search Console already names a status

Pick the status above the URL field and the result reads the live checks against it: Expected when the live page explains the status and nothing is wrong, Needs action when the live evidence shows something to fix, and Can’t tell from outside when the answer sits in Google’s own data, such as its crawl history or the canonical it selected.

  • Duplicate without user-selected canonical, Duplicate, Google chose different canonical than user and Alternate page with proper canonical tag: the declared canonical, its target and any redirect. Read duplicate without user-selected canonical: what to check before changing either URL.
  • Crawled - currently not indexed and Discovered - currently not indexed: checks the selected live signals, without establishing why Google has not indexed the URL. Follow the crawled and discovered workflow in our Search Console guide.
  • Page with redirect, Excluded by ‘noindex’ tag, Soft 404 and Blocked by robots.txt: the redirect chain, Googlebot directives, response and title, and the Googlebot robots.txt rules.

Example: HTTP 200, self-canonical and in the sitemap, but still not indexed

Those observations can coexist. Record the last crawl date in URL Inspection, compare its crawled HTML with the current page, and use Test live URL to review the rendered content and resources. This checker does not run that rendering test. Then inspect any similar page and the links that help users reach this URL.

A recorded “Crawled - currently not indexed” status alone does not prove a broken canonical, technical failure or particular content-quality problem. Correct an evidenced issue, request indexing when appropriate, and wait for a new crawl before judging the change. Changing the URL or repeatedly resubmitting it does not establish a fix.

Live Technical Checks Versus Google’s Indexed View

QuestionThis live pre-checkSearch Console URL Inspection
Which URL?The entered public URL and checked final destinationThe exact URL in a verified property, with Google’s canonical information
When was it observed?At this fetch, subject to response cachingIndexed evidence from Google’s last recorded crawl; Test live URL is a separate current fetch
What can it answer?Whether the tested response has selected technical blockersWhether Google reports the URL indexed and the reason it records
What next?Investigate returned blockers and unknown checksCompare indexed and live evidence, then request indexing only when appropriate

A passing live test does not guarantee indexing. Follow the Search Console guide to inspect the recorded URL.

What’s new

  • Interrupted compressed responses now finish with an explicit outcome instead of leaving the check waiting.

  • New: pick the Search Console status you see, such as a duplicate canonical or crawled but not indexed, and the result says if the live page explains it, what to fix, or that only URL Inspection can tell.

  • Only an HTTP 200 page counts as clean. A robots.txt that blocks every crawler is reported as unknown, and repeated identical canonical tags are no longer flagged.

Next steps

Google Index Checker: Indexability Pre-check related tools and articles

Continue with the closest follow-up checks and guides based on this tool's topic, crawl intent, and optimization workflow.

Google index status and indexability: FAQ

What does this Google index checker actually test?
It tests live technical indexability signals for one public URL: the complete redirect path within its limit, final HTTP response and content type, generic and Googlebot-specific robots directives, Googlebot robots.txt rules, declared canonical and a bounded same-host canonical-target check, plus sitemap inclusion where a sitemap can be found. It does not query Google or Search Console.
Does “no tested blocker” mean the URL is indexed by Google?
No. It only means this fetch did not find a blocker among the signals it could test. Google may still choose not to index a URL because of duplication, quality, security, manual actions, removals, or other conditions. Inspect the exact URL in your verified Search Console property for Google’s indexed view.
How do I check Google index status?
Open Google Search Console, select the property that contains the exact URL, paste the full URL into URL Inspection, and review the indexed URL result. Then use Test live URL to compare Google’s current live test. The indexed view and live test answer different questions.
Can I check many URLs at once?
No, it checks one URL per run. For a whole site, open the Page indexing report in Search Console, which groups every URL Google knows about by status, then run this checker on the important URLs it flags.
Can this tool explain a Search Console indexing status?
Yes, as far as live evidence allows. Choose the status you see, such as Duplicate without user-selected canonical or Crawled - currently not indexed, and the result says whether the live page explains it, what to fix, or that the answer depends on Google’s own data. It reads the same live checks and does not query Search Console.
Is a site: search a reliable index check?
No. Google says a URL can be indexed without appearing in a related site: query, and site: results are not exhaustive. This tool keeps the search as an optional clue, never as proof of indexed or not indexed status.
How are robots directives checked?
The response HTML is checked for all robots and googlebot meta tags. The response headers are also checked for unscoped and Googlebot-scoped X-Robots-Tag noindex and nofollow directives. JavaScript-rendered changes are outside this server-side fetch.
What does a robots.txt block mean?
It means the checked Googlebot rules disallow crawling the final URL. A robots.txt block is not a noindex directive and a blocked URL can sometimes remain listed without a snippet. Google also must be able to crawl a URL to see a noindex rule on that URL. When robots.txt disallows every crawler and has no Googlebot group, the result stays unknown: some sites serve Google a different robots.txt than they serve to other tools.
Is a different canonical URL an indexing error?
Not necessarily. A canonical is a preference signal for duplicate or very similar pages, and Google can select a different canonical. This tool checks a same-host target within strict limits; cross-host targets and anything outside those limits stay unknown.
Does sitemap inclusion guarantee indexing?
No. A sitemap helps discovery and is a weak canonical signal, but Google says submission is only a hint. “Not found” here only covers the bounded set of sitemap files checked and is a diagnostic warning, not a noindex result.