Robots.txt vs Noindex: Which One Should You Use?
Robots.txt controls crawling and noindex controls indexing. Learn the difference, when to use each, and why combining them…
Pages missing from Google? Work through 12 common indexability problems, from stray noindex tags and robots.txt blocks to thin content, and learn how to fix each one.

Indexability is whether a page is technically able to be stored in a search engine’s index. If a page is not indexable, it cannot rank for anything, no matter how good the writing is. This checklist walks through 12 common reasons pages stay out of Google’s index, how to spot each one, and what to change so your important pages get a fair chance.
This guide is part of our complete website SEO audit guide, which walks through every step of auditing a small site.
The two terms are often used interchangeably, but they describe different steps:
A page has to pass both stages. Google explains the full process of crawling, indexing and serving in its overview of how Google Search works. For practical purposes, think of it as a chain: discover, crawl, render, index. A break anywhere in the chain keeps the page out of results.
Before working through the list, gather some evidence so you know which problems actually apply:
With that evidence in hand, match each excluded page against the 12 reasons below.
The most common cause, and the easiest to miss. A <meta name="robots" content="noindex"> tag in the head, or an X-Robots-Tag: noindex HTTP header, tells Google not to index the page. It often slips in from a staging site, a “discourage search engines” setting in WordPress, or a plugin option applied to a whole post type.
Fix: Remove the tag or header from pages you want indexed, then request indexing in Search Console.
If robots.txt disallows a path, Google cannot crawl it, and so cannot see the content. Blocked URLs occasionally appear in results without a description, but they will not rank properly. Our guide to robots.txt vs noindex explains why blocking is not the same as excluding.
Fix: Remove or narrow the Disallow rule, then test the URL again so you know indexability has been restored.
If a page’s canonical tag names a different URL, Google treats the page as a duplicate and indexes the other URL instead. Templates that set every canonical to the homepage cause this at scale.
Fix: Use self-referencing canonicals on unique pages. See our canonical URL guide for the full set of rules.
Indexability starts with the server response: pages must return a 200 status code to be indexed. A 404, 410 or 5xx response removes them. Soft 404s, where a page returns 200 but shows “nothing found” or very thin content, are also dropped.
Fix: Restore the content, redirect the URL to a relevant replacement, or make sure genuinely empty pages return a proper 404.
A redirecting URL is never indexed itself; only its destination can be. If your sitemap or internal links point to redirecting URLs, you are asking Google to index addresses that cannot be indexed.
Fix: Update links and sitemap entries to the final URL.
Orphan pages, with no internal links pointing to them, are hard for crawlers to discover and look unimportant when they are found.
Fix: Link to the page from relevant posts, category pages or navigation.
A sitemap is not required for indexing, but it helps discovery, especially on new sites with few backlinks.
Fix: Make sure the sitemap lists every canonical, indexable URL and nothing else, and submit it in Search Console.
If the main content only appears after scripts run, and those scripts are blocked, slow or broken, Google may index an almost empty page.
Fix: Use URL Inspection’s rendered HTML view to confirm the content is present. Server-render critical text where possible.
Near-identical pages, such as location pages with only the city name changed, or tag archives that mirror categories, are often filtered out as duplicates.
Fix: Merge similar pages, make each one genuinely distinct, or canonicalise duplicates to the best version.
“Crawled – currently not indexed” frequently means Google fetched the page and decided it was not worth storing. Short pages with little original information are common victims. This is where indexability stops being a purely technical question and becomes a content one.
Fix: Expand the page with specific, useful information, or consolidate it into a stronger page.
“Discovered – currently not indexed” means Google knows the URL exists but has not crawled it yet. On new or small sites this can simply take time.
Fix: Strengthen internal links to the page, keep the sitemap current and avoid publishing large batches of low-value URLs that dilute attention.
Pages behind a login, a password-protected staging environment, or a firewall rule that blocks Googlebot cannot be crawled at all.
Fix: Check server and security plugin settings, and confirm that public pages are actually public.
Quick tip: After a site launch or migration, check reasons 1, 2 and 3 first. Leftover noindex tags, a staging robots.txt and canonicals pointing to the old domain account for a large share of sudden indexability problems.
Use this table to map what you see in Search Console to the likely cause:
| Search Console status | Likely reason | Where to look |
|---|---|---|
| Excluded by ‘noindex’ tag | #1 Noindex present | Page head, HTTP headers, plugin settings |
| Blocked by robots.txt | #2 Disallow rule | /robots.txt |
| Alternate page with proper canonical tag | #3 Canonical elsewhere (often intended) | Canonical tag |
| Duplicate, Google chose different canonical | #3 or #9 Conflicting signals or duplication | Canonical, internal links, content |
| Not found (404) / Server error (5xx) | #4 Error status | Server logs, hosting |
| Page with redirect | #5 Redirecting URL | Internal links, sitemap |
| Crawled – currently not indexed | #9 or #10 Duplication or thin content | Content quality |
| Discovered – currently not indexed | #6, #7 or #11 Discovery and priority | Internal links, sitemap |
Note that “Alternate page with proper canonical tag” is often fine. It means the canonical is working as intended. Only investigate it if the excluded URL is one you actually want in search results.
Indexability problems tend to creep back in when themes update, plugins change or new sections launch. A light routine catches them early:
If you want a structured way to do the crawl part, our walkthrough on running a 25-page SEO audit in 15 minutes fits neatly into this routine.
Many indexability problems persist simply because small sites rely on heavyweight tools they rarely open. We explain the alternative in why lightweight SEO tools win for small websites, and debunk related misconceptions in seven technical SEO myths.
Start with evidence, not guesses: inspect the URL in Search Console, crawl your key pages, and match each excluded URL to one of the 12 reasons above. Fix the technical blockers first (noindex, robots.txt, canonicals, status codes) because they are quick and absolute. Then work on discovery and content quality, which take longer but decide whether Google wants the page once it can index it. For more lightweight checks, visit LiteScroll.com.
Written by
Editorial Team
The LiteScroll Editorial Team researches, tests and writes every guide on LiteScroll.com. We run each fix through our own SEO Crawler and SEO Inspector before we recommend it, and we update guides when search engines change the rules.
Our editorial policy
Robots.txt controls crawling and noindex controls indexing. Learn the difference, when to use each, and why combining them…

Learn what a canonical URL is, how to add canonical tags correctly, how to test them across your…

A complete website SEO audit guide for small sites: plan your pages, check indexability, canonicals, titles, headings, images…