If you've worked with any system that has a multi-stage pipeline, this pattern will look familiar: two failure states that sound similar in a status dashboard but represent completely different points of failure, requiring completely different debugging approaches.
Search Console has exactly this pair: 'Discovered — currently not indexed' and 'Crawled — currently not indexed.'
A Rough Pseudocode Version
If it helps to see it as logic rather than prose: if (!crawled) return 'discovered_not_indexed'; else if (crawled && !passed_quality_check) return 'crawled_not_indexed'; else return 'indexed'; The branch you're in determines the fix entirely.
Debugging the wrong branch, adding internal links to a page that already failed its quality check, for instance, burns time without changing the outcome, the same way patching the wrong function in a codebase leaves the actual bug untouched.
Mapping This to a Pipeline
Think of Google's process as: enqueue → crawl → evaluate → index. 'Discovered — currently not indexed' means the URL is sitting in the queue, pre-crawl. Nothing has executed yet. 'Crawled — currently not indexed' means the crawl step completed, the evaluation step ran, and the result was a negative decision.
These are as different as a job that's still queued versus a job that ran and failed a validation check, conflating them means debugging the wrong stage.
Why Conflating Them Wastes Time
If you treat a 'Crawled — not indexed' page as if it just needs to be re-queued (hitting Request Indexing repeatedly, or adding more internal links without touching content), you're retrying the same input against the same evaluation logic and expecting a different output.
Nothing changed about what's being evaluated, so nothing should be expected to change about the result.
Diagnostic Signals for Each State
● Discovered: check inbound internal link count (likely 0 or 1), check crawl budget signals if this is happening to many URLs simultaneously, check sitemap correctness
● Crawled but not indexed: check for near-duplicate content against other indexed pages on the domain, check word count / content depth relative to competing indexed pages, check whether the page adds anything not already covered elsewhere on the site
A Practical Debugging Order
Pull the exact status per URL from Search Console's Pages report rather than assuming — this is your stack trace, effectively, and it tells you which stage to focus on. For 'Discovered' URLs, the fix is structural (internal links, crawl budget).
For 'Crawled but not indexed' URLs, the fix is content-level (uniqueness, depth, consolidation). Applying a structural fix to a content-level problem, or vice versa, is the single most common time-waster in troubleshooting indexing issues.
Full non-technical writeup with the decision framework: Discovered vs Crawled — currently not indexed.
Originally published on SEO Inbounds.
Top comments (0)