Indexability Checker: Find Out Why a Page Is Not Indexed
Enter a URL and get every technical reason Google could skip it, named the way Search Console names it. It checks the blockers, not Google’s index itself.
Checks
Redirect chain
| # | URL | Status |
|---|
What this checker can and cannot tell you
No outside tool can read Google's index. The only source of truth is the URL Inspection tool in Search Console, and only for sites you have verified. What a tool can do is fetch the page the way Googlebot does and look for the things that stop indexing: a status code other than 200, a redirect, a noindex, a canonical that points away, a robots.txt rule, a page that looks empty. Those are the reasons behind most of the "Why pages aren't indexed" rows I see in client accounts, and every one of them can be tested from outside.
So read the verdict as "is anything technical in the way?" Indexable means no blocker was found. It does not mean the page is indexed, and it does not mean Google will choose to index it.
How each check maps to a Search Console status
| What the checker finds | Status in the Page indexing report | Fix |
|---|---|---|
| 404 or 410 | Not found (404) | Restore the page or 301 it to the closest live page |
| 5xx, timeout, refused connection | Server error (5xx) | Fix hosting, caching or the crashing template |
| 401 or 403 | Blocked due to unauthorized request (401), Blocked due to access forbidden (403) | Remove the login wall or the firewall rule for Googlebot |
| 3xx to another URL | Page with redirect | Nothing, if the redirect is intended; update internal links |
| Loop or more than 5 hops | Redirect error | Redirect straight to the final URL |
| Disallow rule matches for Googlebot | Blocked by robots.txt | Remove or narrow the rule |
| noindex in meta robots, meta googlebot or X-Robots-Tag | Excluded by 'noindex' tag | Remove the noindex |
| Canonical to another live URL | Alternate page with proper canonical tag | Nothing for duplicates; self-canonical if this page should rank |
| Canonical to a broken or redirected URL | Often Duplicate, Google chose different canonical than user | Point the canonical at a live 200 page |
| 200 with an error-page title, or almost no text | Soft 404 | Return a real 404, or give the page real content |
The checker prints the matching status beside each failing row, so you can put its result next to the report in Search Console and see which row explains which URL.
How Google reads robots.txt
robots.txt is where most tools get it wrong, so this one follows Google's own rules. Googlebot uses the group whose User-agent is Googlebot; only when there is none does it fall back to User-agent: *. A group for Googlebot-News does not apply to normal crawling. Inside the group, the rule with the longest matching path wins, whatever order the rules are in. When an Allow and a Disallow match with the same length, Allow wins. * matches any run of characters and $ anchors the end, so Disallow: /*.pdf$ blocks /guide.pdf but not /guide.pdf?v=2.
The status of robots.txt itself matters too. A 404 means "no rules", so everything is allowed. A 5xx, a 429 or a timeout makes Google stop crawling the whole site until the file can be read again. Google reads only the first 500 KB of the file.
noindex, canonical and the signals that cancel each other
A noindex can live in three places: <meta name="robots">, <meta name="googlebot">, or the X-Robots-Tag HTTP header, which is how PDFs and images get noindexed. The checker reads all three. A value of none counts as noindex too.
The classic mistake is blocking a page in robots.txt and adding noindex. Google cannot crawl the page, so it never sees the noindex, and the URL can stay in the index from links alone, shown as "Indexed, though blocked by robots.txt". To remove a page, let Google crawl it with noindex until it drops out, and only then block it if you must.
A canonical tag is a hint, not a command. When it points to a URL that returns 404, redirects or is noindexed, Google usually ignores it and picks a canonical itself. That is why the checker fetches the canonical target instead of only reading the tag.
Soft 404 and thin pages
A soft 404 is a page that returns 200 but looks like an error or like nothing at all: "Product not found", an empty search result, a category with no items. The checker flags two signals: a title or H1 that reads like an error, and a body with fewer than about 60 words in the HTML. Both are hints, not proof. A single-page app that builds its text in the browser will also look thin here, because the checker reads raw HTML. Google renders JavaScript later, so test those pages in URL Inspection's live test to see the rendered version.
When every check passes and the page is still not indexed
Then the problem is not technical. "Discovered, currently not indexed" means Google knows the URL but has not crawled it yet, which usually points to crawl priority: few internal links, a big site, a slow server. "Crawled, currently not indexed" means Google fetched the page and decided it was not worth indexing yet, usually because it is thin, close to another page, or simply new. Neither one has a tag you can remove. Link to the page from pages that are already indexed, make it clearly different from its neighbours, and give it time. I go through these cases in order, with what to do for each, in why your pages are not indexed.