Paste a URL into this indexability checker and get a straight yes or no, plus the exact reason. We check the six things that decide indexability: HTTP status, robots.txt, X-Robots-Tag header, noindex meta, canonical target and sitemap presence.
Instant, free, no account needed. Checks status, robots.txt, X-Robots-Tag, noindex, canonical and sitemap.
Any one of these silently keeps a page out of Google. We check each, on every page.
A robots meta tag (or X-Robots-Tag header) telling Google to keep the page out of the index.
Disallow rules that stop Google fetching a URL - sometimes matching far more than intended.
A canonical that points elsewhere tells Google to index that page instead of this one.
Redirects, 404s and server errors that mean there's no live page to index.
Thin or empty pages that return 200 but have no real content, which Google quietly drops.
Pages with zero internal links - Google struggles to find and value them.
Indexability is the foundation - fix it before anything else, because nothing ranks until a page can be indexed.
The classic outage: a noindex added to a shared layout or component to hide a staging page, then shipped to production. Grep your built HTML for noindex and confirm it only appears where you intend (thank-you pages, internal search results).
A single Disallow: can match more paths than you expect. And remember: blocking a URL in robots.txt doesn't remove it from the index - it just stops re-crawling. To deindex, allow crawling and add a noindex tag instead.
Every page you want indexed should self-reference its canonical. Watch for templates that canonicalize every paginated or filtered page back to page 1 - that deindexes the rest.
Thin "no results" pages should return a real 404, not a 200 with no content (a soft 404). Make sure pages you want indexed return a clean 200 and aren't caught in a redirect.
A page with no internal links is hard for Google to find and rank. Link to important pages from your navigation, related-content blocks, or hub pages so they're discoverable and gain authority.
Every check maps to one cause and one fix. Find the one you got, do that, then re-run.
Google never fetches the URL, so every other signal on the page is invisible to it, including a noindex you added on purpose. This is the one case where two fixes cancel out: blocking a URL to remove it actually keeps the listing alive, just stripped of its snippet.
Do this: remove the matching Disallow rule, re-run the check, and only then act on anything else it reports.
Each of these keeps one URL out on its own. A noindex tag or header excludes it outright, a canonical pointing elsewhere hands indexing to that other URL, and anything other than a 200 means there is no live page to index.
Do this: fix whichever the check named, then confirm the page returns 200 with a self-referencing canonical.
A clean result means nothing is stopping Google indexing the URL. It does not mean the URL is in the index today: discovery still has to happen, and for a new or rarely linked page that can take days or weeks.
Do this: if Search Console still reports it missing, the bottleneck is discovery rather than permission. Add internal links and a sitemap entry, not more tags.
This checks a single URL. Almost every serious indexability fault is a template fault, so it repeats across every page built from the same layout and stays invisible from any one of them.
Do this:run a full audit to crawl every page, or read the indexability guide for the mechanics behind each check.
The most common indexability bug is an accidental noindex. Here is where it usually lives.
First check Settings → Reading for "Discourage search engines from indexing this site", a single checkbox that noindexes the entire site, and the most common cause of a whole-site disappearance after launch. Per-post, look in the SEO plugin's Advanced tab (Yoast: Advanced → "Allow search engines to show this page?"; Rank Math: Advanced → Robots Meta). Category, tag and archive defaults are set globally in the plugin's Search Appearance settings.
Shopify noindexes certain pages by default (internal search, cart, some collection filters) via theme.liquid. If a page you want ranked is noindexed, look for a conditional block outputting <meta name="robots" content="noindex"> in the theme's <head>, under Online Store → Themes → Edit code.
A noindex can come from page metadata (a robots: noindex in your head component) or from an X-Robots-Tag: noindex HTTP header set at the server or CDN, which the page source will not reveal. The header version is the one most often left over from a staging config; check your server, framework config, and CDN response-header rules, not just the HTML.
Clearing the block is step one. Getting the page back into the index is a separate step you can push.
A clean indexability check means the page is now eligible to be indexed, not that it is indexed. Google still has to re-crawl and re-process it, which can take days on its own. To speed it up, open Google Search Console, paste the URL into the URL Inspection tool at the top, and read the coverage verdict. If it still shows the old exclusion, click "Request Indexing" to push it into the priority crawl queue. Then check back after a few days: the tool will show the page as indexed once Google has honoured the fix. This inspect-then-request loop is the fastest way to recover a page that was accidentally noindexed, far quicker than waiting for the next natural crawl.
Indexability is the one category where checking a single page and checking a whole site answer genuinely different questions, and where doing only the first is the most common way sites lose traffic without noticing.
For a single URL the check is a short, closed list: does it return 200, does robots.txt allow crawling, does meta robots or the X-Robots-Tag header say noindex, and does the canonical point at itself or somewhere else. Four questions, four answers, and if all four pass the page is eligible.
This is exactly the check to run when a specific page stopped appearing in search. It is fast, it is definitive, and it usually finds the cause immediately, because the causes of a single page becoming non-indexable are few and mechanical.
The damaging version of this problem is never one page. A noindex reaches production on a shared template and applies to a whole section. A canonical rule written for one page type gets applied to another and points hundreds of URLs at a single destination. A robots.txt edit intended to block a staging path blocks a live directory that happens to share a prefix.
None of these look different from a correct configuration when you inspect one page. They are only visible as a shape in the data: a directory where every URL is suddenly non-indexable, a canonical target receiving hundreds of inbound canonicals, a status code distribution that changed since the last crawl. Crawlability and indexability are also distinct, and a site-wide view is what separates them: a page blocked in robots.txt was never crawled, so its meta robots directive is irrelevant and possibly never even read.
A crawl tells you what should be indexable. Search Console tells you what Google has actually indexed. The gap between those two lists is where the real findings sit, and neither source alone reveals it.
Pages that are indexable but not indexed are usually a discovery or quality problem rather than a directive problem: nothing links to them, or Google crawled and chose not to index. Pages that are indexed but not indexable in your crawl are the more urgent case, because something changed recently and the deindexing has not finished propagating yet. Catching that gap early is the difference between fixing a directive and waiting out a recovery.
Read the mechanics behind a check, or run the next tool on the same site.
Read the guide
When noindex helps, when it silently buries pages, and how to audit it.
How robots.txt blocks crawling, and why that is not the same as noindex.
How canonicalisation affects which of your pages get indexed.
Run another check
Free to start. Crawl your site and find every non-indexable page.
Check my indexability