Page Not Indexed? What Each Search Console Reason Means and How to Fix It
Open Search Console, go to Indexing > Pages, and scroll past the green "indexed" number to the table below. Every URL Google decided not to index is grouped under a reason like "Discovered - currently not indexed" or "Duplicate without user-selected canonical." Those labels are terse, and half of them describe situations that are completely fine. The other half are real problems with specific fixes.
The mistake we see most in audits is people treating the whole table as a to-do list and trying to force-index pages Google is correctly leaving out. Before you touch anything, sort the reasons into three buckets: leave it alone, fix the page, fix a technical setting. This post walks each reason Google reports, what it actually means, whether it is a problem, and what to do. If your goal is the opposite, getting a legitimately good page indexed faster, start with how to get Google to index your site.
Discovered - currently not indexed
Google knows the URL exists (it found it in a sitemap or a link) but has not crawled it yet. It is in the queue.
Is it a problem? Usually not on its own. This is normal for new pages and for large sites where Google is rationing crawl budget. If it clears within a week or two, ignore it.
It becomes a problem when thousands of URLs pile up here for months. That pattern says Google is choosing not to spend crawl budget on your site, often because it has learned your pages tend to be low value, or because you are generating far more URLs than your content justifies (faceted navigation, endless filter combinations, thin tag archives). The fix is not "request indexing" on each one. It is reducing the number of low-value URLs you ask Google to crawl and making the pages that remain worth the visit. Solid internal links from crawled pages also help pull these out of the queue.
Crawled - currently not indexed
Google fetched the page, looked at it, and decided not to index it. This is a quality judgment, and it is the reason worth taking personally.
Is it a problem? Yes, if the page is one you want ranking. The usual causes, in the order we find them: the content is thin or mostly boilerplate, it is near-duplicate of another page on your site or the wider web, or it simply does not add anything the index does not already have. Auto-generated pages, doorway-ish location pages, and scraped or lightly spun content land here constantly.
The fix is the content, not a resubmission. Make the page substantially more useful than what already ranks, consolidate it into a stronger page if it overlaps with one, or accept that it should not be indexed and noindex it deliberately. Requesting indexing on a page Google already judged and rejected is the single most common wasted effort in this whole report.
Excluded by 'noindex' tag
The page carries a <meta name="robots" content="noindex"> tag (or an X-Robots-Tag: noindex HTTP header), so Google obeyed it and kept the page out.
Is it a problem? Only if you did not mean it. Half the time this reason is correct and intentional (staging pages, thank-you pages, internal search results). The other half it is a page you very much want indexed, and a CMS setting, a plugin, or a stray template tag is quietly noindex-ing it. Inspect the URL, look at the fetched HTML, and confirm whether the tag should be there. If it should not, remove it at the source. Note that noindex and robots.txt do different jobs and interfere with each other, the robots.txt vs noindex guide explains why blocking a page in robots.txt can actually prevent Google from seeing the noindex you want it to obey.
Blocked by robots.txt
Your robots.txt file disallows the path, so Googlebot did not crawl it.
Is it a problem? Depends. If you meant to block it, fine, though be aware a robots-blocked URL can still appear in search results as a bare link if other pages link to it, because Google indexes the URL without the content. If you did not mean to block it, this is an urgent fix: a Disallow rule on a section you want ranking will keep the whole thing out. Check your robots.txt for an overly broad rule (a stray Disallow: / from a staging config is the classic disaster). Remember that robots.txt controls crawling, not indexing, so if you want a page kept out of results entirely, you need noindex on a crawlable page, not a robots block.
Duplicate without user-selected canonical
Google found multiple URLs it considers the same page, and you did not tell it which one is canonical, so Google picked one itself and grouped the rest under this reason.
Is it a problem? Sometimes. If Google picked the URL you would have picked, no harm done. The risk is Google canonicalizing to a version you did not want (an HTTP variant, a URL with tracking parameters, a print page). The fix is to stop leaving the choice to Google: add a <link rel="canonical"> pointing to your preferred URL on every duplicate, keep internal links pointing at that canonical version, and make sure your sitemap lists only canonicals. The canonical tags and duplicate content guide covers the tag syntax and the common ways it gets ignored.
Duplicate, Google chose different canonical than user
You did set a canonical, but Google overrode it and picked a different URL as the real one.
Is it a problem? It means Google disagrees with your canonical signal. This usually happens when your signals conflict: your canonical points to page A, but your internal links, sitemap, and redirects all point to page B, so Google trusts the majority. Line up every signal (canonical tag, internal links, sitemap entries, hreflang, redirects) on the same URL. If they already agree and Google still overrides, the two pages may genuinely be too similar to keep separate, and consolidating them is the honest fix.
Alternate page with proper canonical tag
The page correctly declares a canonical pointing to another URL, and Google indexed that canonical instead. This is the system working exactly as designed.
Is it a problem? No. Leave it alone. This is the single most misread reason in the report. People see a big number here and panic, but these are your duplicate or variant URLs correctly deferring to their canonical, which is exactly what canonical tags are for. A paginated series, a mobile URL, a parameterized version all show up here doing their job. No action needed.
Soft 404
The page returns an HTTP 200 (OK) status, but Google thinks it looks like a "not found" page, empty content, a "no results" message, or a "this product is unavailable" stub.
Is it a problem? Yes, one way or another. Either the page genuinely has no content and should return a real 404 or 410 status, or it does have content and something is making it look empty to Google, often JavaScript that renders the content client-side while the initial HTML is blank. Check what Googlebot actually receives with the URL Inspection tool's rendered HTML. If the page is meant to exist, get real content into the server response. If it is not, return the correct status code instead of a 200 with an "oops, nothing here" message.
Redirect error
Google tried to follow a redirect and failed: a redirect loop, a chain too long to follow, an empty or malformed Location header, or a redirect to a URL that itself errors.
Is it a problem? Yes. A broken redirect means the URL and often everything behind it is unreachable. Trace the chain, redirect A should go straight to the final destination, not A to B to C to D. Fix loops where two URLs redirect to each other, and make sure the final hop returns a 200. Run the URL through our redirect checker to see the full hop-by-hop chain and status codes, and the guide on fixing redirect chains and loops covers the repair patterns.
A quick triage table
| Reason | Problem? | First move | | --- | --- | --- | | Discovered - currently not indexed | Usually no | Wait; reduce low-value URLs if it's chronic | | Crawled - currently not indexed | Yes | Improve or consolidate the content | | Excluded by 'noindex' tag | Only if unintended | Confirm the tag belongs there | | Blocked by robots.txt | Only if unintended | Check for an overly broad Disallow | | Duplicate without user-selected canonical | Sometimes | Add an explicit canonical | | Google chose different canonical | Sometimes | Align all canonical signals | | Alternate page with proper canonical | No | Leave it alone | | Soft 404 | Yes | Add real content or return a real 404 | | Redirect error | Yes | Trace and fix the redirect chain |
Work top to bottom by impact, not by row count. A hundred URLs under "Alternate page with proper canonical" need nothing. Five under "Redirect error" or "Crawled - currently not indexed" are where your afternoon should go.
Frequently Asked Questions
What's the difference between "Discovered" and "Crawled - currently not indexed"?
"Discovered" means Google knows the URL exists but has not fetched it yet, it is a queue and crawl-budget situation. "Crawled - currently not indexed" means Google did fetch the page and then decided not to index it, which is a content-quality judgment. The first often clears on its own; the second needs a better page.
Is "Alternate page with proper canonical tag" something I need to fix?
No. It means the page correctly points to a canonical URL and Google indexed that canonical instead, which is exactly how canonical tags are supposed to work. A large number here is normal for sites with pagination, parameters, or variant URLs. No action is needed.
Why is a page I never blocked showing "Blocked by robots.txt"?
Something in your robots.txt is disallowing its path, often an overly broad rule inherited from a staging or CMS default, like a stray Disallow: /. Open your robots.txt, find the rule matching the URL, and narrow or remove it. Remember robots.txt controls crawling, so a blocked URL can still appear as a bare link if other pages point to it.
How do I fix "Crawled - currently not indexed"?
Treat it as a content problem, not a technical one. Make the page substantially more useful than what already ranks for its topic, merge it into a stronger page if it overlaps with existing content, or deliberately noindex it if it should not be indexed. Resubmitting the unchanged page does not help, because Google already evaluated it.
Should I request indexing for every page in the not-indexed list?
No. Many of those pages are correctly excluded (canonical alternates, intentional noindex, real duplicates) and requesting indexing does nothing for them. Requesting indexing only helps a genuinely good, eligible page that Google has not gotten to yet. For pages Google already crawled and rejected on quality, fix the page first.