About the Indexability Checker
The Indexability Checker answers the question people actually mean when they ask “is my page indexed?” — is there anything stopping Google from indexing it? It follows the redirect chain to the URL that really matters, then tests that URL against every gate a page must pass: HTTP status, robots.txt (evaluated with Google's own longest-match rules), meta robots, the X-Robots-Tag header, and rel=canonical. If something blocks, you get the exact directive and where it lives.
No free tool can honestly tell you whether a page is in Google's index — that needs either the Search Console API (your own verified domains only) or scraping Google, which is against its terms and gets blocked. Tools that claim otherwise usually just check for an HTTP 200 and call it “indexed”. This one tells you the truth: what is technically preventing indexing, and what is not. Go deeper with the Robots.txt Tester, the Canonical Checker or the Meta Tag Analyzer.
No — and no free tool honestly can. Querying Google's live index requires either scraping its results (which Google blocks and forbids) or the Search Console API, which only works for domains you have verified. What this tool does instead is arguably more useful: it checks every technical condition that must hold before Google is able to index the page. If something here is blocking, the page cannot be indexed no matter how long you wait — and you have the exact cause. To confirm a page is actually indexed, use Search Console's URL Inspection on your own site.
Crawling is Google fetching the page; indexing is Google storing it for search results. robots.txt controls crawling — a disallowed URL is not fetched. A noindex directive controls indexing and lives in the page itself. The two interact in a way that trips people up constantly: if you block a URL in robots.txt, Google never fetches it, so it never sees your noindex either. To reliably remove a page from search, allow crawling and serve noindex.
Not by itself. A canonical tells Google which URL of several near-duplicates should be the one in the index. But it does mean this URL is a candidate for consolidation, so it usually will not appear in results — the canonical target will. That is correct for duplicates and a serious mistake if it was set by accident (a common one: a template hard-codes the same canonical on every page, collapsing the whole site into one URL).
Because Google indexes the destination, not the hop. A URL returning 301 or 302 is a signpost, not a page, so it will not appear in results itself. This tool follows the chain and evaluates the final URL — which is the one that can actually be indexed.
The same directives as the robots meta tag, but sent as an HTTP header instead of inside the HTML. It is often used for non-HTML files such as PDFs, and it is easy to miss because you cannot see it in the page source. If a page mysteriously refuses to get indexed while the HTML looks clean, this is a prime suspect.
No. The URL is fetched, the result is rendered, and nothing is stored.