"Discovered — currently not indexed" is the most quoted and least useful sentence in technical SEO. It tells you that Google knows about a URL and has not included it. It does not tell you why. Treating it as a diagnosis leads to the same loop everyone has run: request indexing, wait, refresh, repeat.
Indexing is a decision, not a switch. Search engines decide which URLs are worth crawling, which are worth storing, and which version of a page should represent the others. Your job is to remove every structural reason to say no, then prove the result with evidence.
Read the status correctly
Search Console labels are clues, not conclusions. They also change over time. The useful move is to separate "not yet crawled" from "crawled and rejected".
| Status | What it usually means | First thing to check |
|---|---|---|
| Discovered — not indexed | Google knows the URL but has not crawled it. | Internal linking, crawl demand, server speed, URL inventory size. |
| Crawled — not indexed | Crawled, but judged not worth including. | Duplicate or thin content, template quality, consolidation. |
| Duplicate without user-selected canonical | Multiple versions exist and Google picked one. | Canonical consistency, parameter variants, internal links. |
| Alternate page with proper canonical tag | Not an error; a non-canonical version. | Whether the canonical target is the page you actually want. |
| Excluded by noindex | A noindex directive is being honoured. | Whether it is intentional, and whether it was inherited from a template. |
| Soft 404 | Returns 200 but looks empty or error-like. | Empty categories, out-of-stock pages, JS rendering failures. |
Diagnose in the right order
Work from the outside in. Fixing content before confirming access wastes weeks.
- Can it be crawled? Check robots.txt, server errors, and whether the URL is reachable from internal links. A disallowed page cannot be indexed reliably, even if it is linked.
- Can it be indexed? Look for
noindex, canonical conflicts, and status codes. Confirm the rendered page actually contains content — not just a JavaScript shell. - Is it distinct? If the page is a near-duplicate of a stronger URL, consolidation is the answer. Find the pattern generating the duplicate and fix it at the source.
- Is it valuable? Thin tag pages, empty archives, and stale variants are not going to be indexed just because you want them to be. Improve, merge, or remove them.
- Is there demand? New URLs in a large inventory wait longer. Reduce the number of low-value URLs competing for crawl attention.
Gather evidence, not guesses
- A crawl inventory. Group URLs by pattern and check status, canonical, and robots signals inside each group. If 800 pages share a template, one representative sample is enough to see the pattern.
- Server logs. Verify which URLs are requested and how often. A page that is never requested has a discovery problem, not a content problem.
- Sitemap parity. Compare sitemap URLs with the crawl inventory. Sitemaps should contain only canonical, indexable, 200 pages.
- URL Inspection. Use it on one or two representative URLs, not as a bulk workflow. It is a spot check, not a strategy.
Keep observed facts separate from inference. A canonical tag is observed. "This page is being treated as a duplicate" is an inference from the canonical, the URL pattern, and the reported status. Both are useful; conflating them produces confident wrong answers.
Fix the template, not the page
Indexation problems are almost never random. They cluster by template:
- Faceted URLs get discovered but not crawled because they are numerous and low value. Decide whether to canonicalise, noindex, or block per pattern.
- Paginated series may be crawled but consolidated. Make sure important items are linked from a crawlable surface, not only deep in pagination.
- Stale variants return 200 long after the product is gone. Redirect or remove them.
- Tag and archive pages often need consolidation or noindex, not individual content rewrites.
Fixing the template is what makes the fix durable. If you only patch the URLs you happened to inspect, the next deploy regenerates the problem.
When not to force indexing
Not every URL deserves to be in the index. If a page has no search demand, no unique value, and no internal link equity, indexing it mostly adds noise. Consolidating or removing it can improve the health of the pages you actually care about.
This is counterintuitive for teams measured on "number of indexed pages", but it is the right trade. Fewer, stronger pages usually outperform a larger index of thin ones.
Frequently asked questions
Why does Google say discovered but currently not indexed?
It means Google knows the URL exists but has not crawled it yet, or has chosen not to spend crawl attention on it. Common causes are weak internal linking, large low-value URL inventories, slow response times, and crawl demand spread across too many pages.
Does requesting indexing in Search Console fix it?
Requesting indexing can speed up a single URL, but it is not a scalable fix. If a whole template is not being indexed, the cause is usually structural and will not be solved by submitting pages one at a time.
Is crawled but currently not indexed a penalty?
Not necessarily. It means Google crawled the page but chose not to include it, often because the page appears duplicate, thin, or less useful than other pages on the site. It is a signal to review content and consolidation, not evidence of a manual action.
Should I noindex thin pages?
If a page has no realistic chance of ranking and no user value, noindex or consolidating it can be healthier than forcing it into the index. Decide per template and keep the decision documented.