One Verdict Instead of Five Separate Checks
Whether a page can appear in Google is not decided by a single setting. It is the combined result of at least five separate signals, and any one of them can quietly knock a page out of the index while the other four look perfectly healthy. The meta robots tag, the X-Robots-Tag HTTP header, your robots.txt rules, the canonical tag, and the HTTP status code all have to agree before a page is genuinely indexable. An indexability checker collapses all of that into one answer: yes this page can be indexed, or no it cannot, and here is exactly which signal is blocking it.
The reason this matters is that the signals live in completely different places. The meta robots tag is in the HTML head. The X-Robots-Tag is in the HTTP response headers. The robots.txt rule lives on a different file at the root of the domain. The canonical is back in the HTML, and the status code is the very first line of the response. No single view in a browser shows you all five at once, so the failure that deindexes a page is almost always the one signal you forgot to look at.
Running an indexability check on a URL is the fastest way to settle the question that comes up constantly in SEO: why is this page not showing up in search. Instead of guessing, you get a deterministic verdict built from the same signals Googlebot evaluates, in the same order of priority.
What the Tool Actually Inspects
Paste a single page URL and the checker fetches that exact page the way a crawler would, then pulls apart the response. First it reads the HTTP status code, because nothing downstream matters if the page does not return a 200. Then it reads the response headers looking for an X-Robots-Tag, because that header carries indexing directives that override anything in the HTML. Then it parses the HTML head for a meta robots tag and a canonical link. In parallel it fetches the domain's robots.txt and tests whether the path of your URL is disallowed for the standard Google crawler.
Each of those becomes a discrete signal in the output. You see the status code and whether it is in the OK range. You see whether meta robots contains noindex. You see whether the X-Robots-Tag header contains noindex and what its raw value is. You see whether robots.txt blocks the path. And you see the canonical URL plus whether it points back at the page itself or somewhere else. The verdict at the top is simply the logical AND of all the positive conditions: the page is indexable only when every blocking signal is clear.
How to Read the Verdict and the Signals
Start at the top. If the verdict says indexable, the page passes the technical gate and the rest is about content quality and crawl priority, which this tool does not pretend to judge. If the verdict says blocked, scroll to the findings list, where each blocker is named in plain language. A blocker is a hard stop. A warning is something that will not deindex the page on its own but is worth fixing, such as a canonical that points to a different URL.
The signal grid is where you confirm the why. A red mark on meta robots noindex means the HTML head is telling crawlers not to index. A red mark on X-Robots-Tag noindex means the server header is doing the same thing, often without anyone on the content side knowing. A flag on robots.txt means the path is disallowed, which is subtle: a disallowed page can still be indexed without its content if it has external links, so robots.txt is not the same as noindex even though people use them interchangeably.
The canonical row deserves the most attention because it is the most misread. If the canonical points to itself, that is the healthy default. If it points elsewhere, the page is telling Google to credit a different URL, which means this exact URL may never rank even though it returns 200 and has no noindex anywhere. That is a soft form of de-indexing that no status code or robots check will reveal.
The Priority Order That Trips People Up
The single most important thing to understand about indexability is the conflict between robots.txt and noindex. If you block a URL in robots.txt, Googlebot is not allowed to fetch the page, which means it never sees your noindex tag. So a page you intended to keep out of the index can end up indexed anyway, listed as a bare URL with no description, because the disallow rule prevented the crawler from reading the very instruction that would have removed it. To reliably remove a page, you allow crawling and use noindex, then once it drops out you can block it if you want.
The second priority issue is the header versus tag override. The X-Robots-Tag header is evaluated as authoritatively as the meta tag, and when they disagree the more restrictive one usually wins. A page can have a clean HTML head and still be deindexed because a CDN or a server config injected an X-Robots-Tag: noindex on an entire directory. This is exactly the kind of split-brain failure the combined checker is built to catch, because the HTML looks fine in view source and the problem is invisible until you read the raw headers.
The Mistakes That Cause Most Indexing Surprises
The classic one is shipping a staging noindex to production. Teams add a site-wide noindex while a site is being built, then forget to strip it at launch, and the brand-new site sits invisible for weeks. An indexability check on the homepage on day one of launch catches this in seconds. The reverse also happens: a page that should be private, like a thank-you or internal search result, is fully indexable and starts collecting impressions for the wrong queries.
Another frequent mistake is conflicting canonicals across paginated or filtered URLs, where every variant canonicalizes to page one, so the deeper pages never rank for their own content. Then there are accidental 4xx and 5xx responses that return an error to crawlers while looking fine to logged-in editors who are served a cached or authenticated version. Because this tool fetches as an anonymous client, it sees the same thing a crawler sees, not the polished version your CMS shows you.
Finally, people confuse a disallow with a removal. Blocking in robots.txt hides the content from the crawler but does not guarantee the URL leaves the index. If your goal is genuine removal, the verdict here will steer you toward the correct combination rather than the one that feels intuitive.
Why This Matters More in the AI Search Era
In 2026, being indexable is the entry ticket to far more than the ten blue links. Google AI Overviews, AI Mode, and the answer engines built on top of search all draw from the same index. If a page is blocked, it is not just missing from traditional results, it is invisible to the AI layer that increasingly sits in front of them. The technical gate that indexability represents is now the gate for AI visibility too.
At the same time, the crawler landscape has multiplied. Beyond Googlebot there are dedicated AI crawlers, and the directives that control them overlap with the ones this tool reads. A page that is cleanly indexable for Google is usually accessible to the broader set of bots as well, while a page tangled in noindex headers and robots blocks tends to be invisible everywhere. Treat the indexability verdict as the foundation that the rest of your AI search strategy is built on.
Indexable Is Not the Same as Indexed
The most important expectation to set is that this tool answers can it be indexed, not will it be indexed. A page can pass every technical check here and still never earn a place in search, because indexability is a permission, not a guarantee. Once the technical gate is open, Google still decides whether the page is worth the storage and the crawl, and that decision rests on content quality, uniqueness, internal linking, and how the page fits into the broader site. A thin, duplicate, or orphaned page can be perfectly indexable and remain absent from results indefinitely.
This distinction matters because it prevents two opposite mistakes. The first is celebrating a clean verdict and assuming the job is done, when in reality you have only cleared the entry requirement. The second is panicking over a missing page and tearing apart your robots and canonical settings, when the signals are actually fine and the real issue is that the content does not yet justify indexing. Reading the verdict correctly means treating an indexable result as a green light to focus on quality, and treating a blocked result as a hard problem to fix before quality even enters the picture.
Internal linking is the bridge between indexable and indexed that this technical check cannot see. A page that is technically open but that nothing on your site links to is hard for crawlers to discover and easy for them to deprioritize. Once you confirm a page is indexable here, the natural next step is to make sure it is genuinely reachable through your navigation and related content, because discoverability is what turns permission into an actual index slot.
What to Do After You Run the Check
If the verdict is blocked, fix the named blocker first and re-run. Remove the stray noindex, correct the robots.txt path, fix the status code, or repoint the canonical, then confirm the verdict flips to indexable before you move on. Do not try to fix all five signals blindly; address the one the tool flagged, because that is the one actually standing in the way.
Once a page is indexable, the work shifts from removing obstacles to earning the index slot. Submit the URL in Search Console, request indexing, and watch the URL Inspection report confirm that Google agrees with the verdict here. Then circle back periodically, because indexability is not a one-time state. A theme update, a CDN rule, or a plugin change can reintroduce a noindex months later, and a quick re-check is the cheapest insurance against silently losing pages from search.