If you've dug into Search Console's Pages report and found a chunk of URLs marked 'Discovered — currently not indexed,' it's worth reframing this the way you'd think about a job sitting in a queue rather than a request that failed. The URL has been enqueued (discovery); it just hasn't been dequeued and processed (crawl + index) yet.
The Three-Stage Pipeline
Discovery is roughly equivalent to a URL entering a work queue — sourced from your sitemap.xml, internal link graph traversal, or occasionally external referring links. Crawling is the actual GET request and parse.
Indexing is the decision to persist that parsed content into the searchable store and make it eligible for ranking. 'Discovered — currently not indexed' just means the item is sitting in the queue; it hasn't been picked up for the next two stages, or it was picked up once, evaluated, and deprioritized for a re-run.
Why Items Sit in the Queue Longer Than Expected
● Low domain-level trust/authority, meaning the crawler allocates fewer cycles overall to this queue
● Content similarity to already-indexed pages, functionally a dedup check that can deprioritize near-identical entries
● Low in-graph connectivity (few or no internal links), which lowers this node's priority score in the traversal
● Bulk enqueueing, publishing 50+ URLs in a single deploy dilutes available crawl attention across all of them at once
● Transient server-side issues on a previous crawl attempt, slow TTFB, intermittent 5xx responses
The Fix That Actually Works: Increase In-Graph Priority
Adding internal links from already-indexed, high-traffic pages is the equivalent of increasing a node's in-degree in the crawl graph, it raises the page's effective priority score more reliably than any manual trigger does.
If you're publishing programmatically or in bulk, staggering the publish schedule instead of pushing everything in one deploy avoids diluting your crawl budget across too many simultaneous new nodes.
Why Repeatedly Hitting 'Request Indexing' Doesn't Work
This is the manual-trigger equivalent of re-running a single CI job instead of fixing the underlying pipeline config, it processes that one item once, but doesn't change anything structural.
If the node still has low in-graph priority afterward, it goes right back to the bottom of the queue on the next pass. Worth using exactly once, after a real structural change, not as a repeated poll.
A Quick Debugging Checklist
● Confirm the URL is correctly listed in sitemap.xml, not malformed or duplicated
● Check server logs for Googlebot's user-agent around the discovery date — did a request arrive and fail, or never arrive at all?
● Count inbound internal links to the URL, zero or one is a strong predictor of staying stuck long-term
● If recently migrated or bulk-imported, check whether many other URLs share this same status, a cluster points to a systemic crawl-budget issue, not a per-page one
A Reasonable Wait Threshold
There's no published SLA, understandably, since it depends on overall domain trust and current crawl demand across the web.
As a practical heuristic: if a URL has been sitting in this status for 30+ days and still has zero or one internal links pointing to it, that's a strong signal the fix is structural (add edges), not a matter of waiting longer.
Full non-technical writeup, including how this status differs from 'Crawled — currently not indexed': Discovered — Currently Not Indexed.
Originally published on SEO Inbounds.
Top comments (0)