Indexability

Indexability Diagnosis

Enter a URL and we tell you whether Google can index it, and if it cannot, exactly what is standing in the way, with the evidence.

The page is fetched as Googlebot (Smartphone), with no language preference sent. A few requests reach the target site: robots.txt, the page itself, and on multilingual sites one language probe.

Enter a URL and we will show you whether Google can index this page, and if not, exactly what is blocking it.

What is the Indexability Checker?

This tool answers one question: can Google index this URL? It fetches the page as Googlebot and works through the checks in the order Google applies them, stopping at the first hard blocker and naming the reason with its exact evidence. The order matters: if robots.txt blocks crawling, Google never reads the noindex tag inside the page, so the right advice changes completely. Things that do not block indexing but do reduce your chances, such as a missing title, thin content or an undeclared sitemap, are kept in a separate warning class.

Indexability Checker

How to use it

  1. 1Enter the full address of the page you expect to be indexed.
  2. 2Read the verdict card at the top: one sentence says whether something blocks it.
  3. 3If something does, copy the evidence and fix that exact line or tag.
  4. 4Leave the amber rows in the checklist for later; they are not blockers.

How to read the results

Indexable
No actionNo technical blocker found; the page can be indexed.
Self-canonical
Correct setupThe page declares itself as canonical, so there is no duplicate confusion.
Canonical elsewhere · redirect
Is it deliberate?The page works, but a different URL is the one getting indexed. Fine if you meant it.
noindex · robots · error
Fix firstGoogle is not indexing this URL at all. No other work helps until the blocker is gone.
Warnings
Can waitTitle, thin content or sitemap points that lower your chances without blocking anything.

When to use it

Right After Publishing

Check as soon as the page goes live. A noindex inherited from a template or a wrong canonical is caught here, not weeks later.

When A Page Drops Out

If Search Console says "not indexed", see the reason with evidence here and fix that exact line instead of guessing.

After A Site Migration

A leftover staging noindex and canonicals pointing at old URLs are classic post-migration faults. Diagnose your highest-traffic pages one by one.

Common mistakes

Using robots.txt To Deindex

robots.txt blocks crawling, not indexing. A page already in the index can stay there behind a robots block. The right tool is noindex, and it only works if the page is crawlable.

Hard-Coding The Canonical

A template that pins the canonical to one value makes every sub-page point at the home page. The pages work and throw no errors, yet none of them gets indexed.

The Staging noindex

A site-wide noindex added in the test environment is the setting most often forgotten at launch. Always diagnose the home page and a few inner pages after going live.

Frequently asked questions

It says indexable, but my page is not in Google. Why?

This tool measures technical blockers, not Google's judgement. A technically open page can still be left out for being low value, duplicate or simply new. Use the Google Index Check tool to see whether it is in the index, and Search Console to see whether it was crawled.

What if the page has both a robots.txt block and noindex?

Decide which you want. To get it indexed, remove both. To keep it out of the index, REMOVE the robots block and keep the noindex. That sounds backwards, but Google has to fetch the page to see the noindex; while the robots block stands it never reads the tag and the URL can still get indexed through links.

The canonical points to another page. Is that a mistake?

Not if it is deliberate. Pointing duplicates and parameter variants at a main URL is exactly what canonicals are for. But when an original piece of content declares someone else as canonical, that page will never be indexed, and it is one of the most common setup mistakes there is.

Does it see tags generated by JavaScript?

No. It reads the HTML the server sends and does not execute JavaScript the way a browser does. Google does execute it, but with a delay. If you write canonical or robots tags with JavaScript, putting them in the server HTML as well is always the safer choice.

Why fetch as Googlebot?

Because some sites answer bots differently: a different X-Robots-Tag header, a different canonical, sometimes a different status code. A result measured with a normal browser identity may not reflect what Google sees. To compare the two identities directly, use the Googlebot Simulator.