Indexability
Indexability is the composite answer to whether a page can end up in Google's index once every gate is checked: HTTP status code, robots.txt, meta robots/X-Robots-Tag, and canonical target. All four must pass; they're evaluated together, not in isolation.
One gate blocking silently tanks traffic
A page can be well-written, rank-worthy, and crawlable yet never appear in search results because a single gate blocks indexing. A canonical pointing to a noindexed URL, or a robots.txt disallow on a page that's already been indexed. Both are conflicts a human reviewing the HTML would spot immediately, yet they silently kill traffic. Indexability is the first thing to check when a page vanishes from search.
Most sites don't notice until search traffic nosedives weeks later. Entire sections can be deindexed by accident, and nobody finds out until the damage is done.
The four gates, in order
Google evaluates indexability as four independent gates. If any gate fails, indexing stops.
First: HTTP status code. A non-2xx response (404, 410, 500) blocks indexing immediately. The page never gets past the first gate.
Second: robots.txt. Google checks whether the URL path is explicitly blocked there. A robots.txt disallow stops indexing regardless of the page's own meta tags.
Third: meta robots and X-Robots-Tag headers. A noindex directive blocks indexing even if HTTP status was 200 and robots.txt allowed crawling.
Fourth: canonical target. If the page points to a canonical, that destination URL must be indexable too. If the canonical is noindexed or returns a redirect, Google may refuse to index the original page.
All four gates must pass.
Crawlability is not indexability
A page can be perfectly crawlable and still never appear in the index. Google can fetch it, read the HTML, follow its links, and still refuse to index it because one gate says no. A page returns 200 OK, robots.txt allows it, internal links point to it, yet a meta robots noindex still blocks indexing.
Crawl access and indexability are two different permissions.
Content quality doesn't determine indexability, either. Indexability is purely a permissions gate. A thin page with perfect HTML still passes all four gates and gets indexed; a brilliant, authoritative page with a rogue noindex directive fails them all and stays invisible.
Code example
Good: A page that passes all indexability gates.
<!-- HTTP: 200 OK -->
<!-- robots.txt: allows / (default) -->
<head>
<meta name="robots" content="index, follow">
<link rel="canonical" href="https://example.com/article">
</head>
Broken: A canonical pointing to a noindexed page blocks indexing of both.
<!-- At https://example.com/article -->
<head>
<link rel="canonical" href="https://example.com/article-old">
<!-- ...but https://example.com/article-old has: -->
<!-- <meta name="robots" content="noindex"> -->
<!-- Both pages now fail the canonical gate -->
</head>
How Scalpel flags it
The Overview panel shows a single indexability pass/fail, computed from robots directives, canonical resolution, HTTP status, and robots.txt. If the page fails, Scalpel flags which gate is blocking indexing. The Meta panel breaks down each of the four gates separately so you can spot conflicts.