There are two statuses in Search Console that owners mix up constantly. Crawled, currently not indexed means Google read your page and declined it. Discovered, currently not indexed is one stage earlier: Google knows the URL exists, and has not even fetched it yet.
That difference matters, because the fixes are different. This guide covers the Discovered case: what it means, why pages sit in it for months, and what actually moves them out.
The short answer
Discovered, currently not indexed means Google knows your URL exists, put it in the crawl queue, and has not fetched it yet. Nothing about the page has been judged, because Google has never seen the page. On most sites this is not a crawl budget problem; it is a priority problem. A slow server, weak internal links, sitemap-only URLs, and a history of thin pages all tell Google the trip can wait. Pages move out when something raises their priority, usually stronger internal links and a better first impression from the pages Google has already crawled.
What does Discovered, currently not indexed actually mean?
Google keeps a to-do list. When it finds your URL, through a sitemap, a link, or anywhere else, the URL goes on that list. Discovered, currently not indexed means your page is on the list and Google has not gotten to it. It planned to crawl, and it keeps deciding other things matter more.
So the question is not “what is broken on my page”. Google has never seen your page. The question is “why does Google keep postponing me”, and that has a small number of real answers.
Is it crawl budget? For most sites, no
Crawl budget is the explanation everyone reaches for, and for most of the sites I work on it is the wrong one. Google’s own guidance is blunt about this: crawl capacity only becomes a real constraint on very large sites, think hundreds of thousands of URLs, or sites that change extremely fast.
If your site has 40 pages, or 400, and they sit in Discovered for months, Google is not out of capacity. It is out of motivation. Postponing a crawl is Google quietly saying it does not expect the page to be worth the trip, usually based on what it already knows about the rest of the site.
I see this pattern most on big e-commerce catalogues: hundreds of thin product and category pages get added at once, the first wave Google samples is unimpressive, and the rest of the catalogue queues forever. The catalogue jobs in my case studies almost all started life this way, and Shopify stores get a guide of their own because they hit it hardest.
Why do pages stay stuck in Discovered?
A slow or struggling server. Google backs off when a site responds slowly, because it does not want to break your server. Fewer fetches per day means a longer queue. This is the one genuinely technical cause on the list, and it is worth ruling out first.
Deep or absent internal links. A page that is four clicks from the homepage, or linked from nowhere except the sitemap, looks unimportant. Google crawls where your own links say the value is.
A sitemap dump with no support. Submitting ten thousand URLs in a sitemap while the site itself links to none of them tells Google the sitemap is aspirational. Sitemaps get pages discovered. Links get pages crawled.
Site-wide quality signals. If the pages Google has already crawled on your site are thin or near-duplicates, new URLs inherit that expectation. This is the invisible cause, and on small sites it is the most common one.
What actually moves pages out?
The order matters. Requesting indexing first, before fixing why Google is postponing you, is the doorbell approach: it works for a handful of genuinely important pages and does nothing for a queue of hundreds.
First, check the server. If response times are bad, fix hosting before anything else, because it caps everything downstream.
Second, link the stuck pages from pages Google already crawls and ranks. Navigation, related-content blocks, category pages. Make your own site vouch for them.
Third, make the first impression worth it. If the stuck pages are thin, add substance before inviting Google back. A crawled-then-declined page lands in Crawled, currently not indexed, which is not an upgrade.
Fourth, prioritize. Pick the pages that actually matter commercially and request indexing for those by hand. On client jobs I submit priority URLs individually and track each one, because a queue clears faster when you tell Google which end to start from.
How long does it take?
Movement usually shows within days once the cause is fixed, but big queues drain over weeks, not overnight. One catalogue I worked on had over a thousand URLs submitted across 118 days of daily work before the backlog was under control. That is normal for the size, and it is why every job I run ends with a per-URL ledger instead of a promise: you watch the queue drain, URL by URL, with dates.
One neighbouring status worth knowing, because the two get confused constantly. Discovered means Google has the URL queued and has not crawled it. URL is unknown to Google means Google has no processed record of it at all. They read similarly in a report and they need different fixes, so it is worth checking which one you are actually looking at.
If your Search Console shows a wall of Discovered, currently not indexed, send me the site. I will tell you which of these causes is doing it, free, usually within a day. No obligation.
Quick answers
Is discovered, currently not indexed a crawl budget problem?
On small and mid-size sites, almost never. Crawl budget is a real constraint for sites with hundreds of thousands of URLs. Below that scale, Google is not short of capacity; it is short of reasons to prioritize your pages.
How long do pages sit in discovered, currently not indexed?
Anywhere from days to months. Google re-queues pages on its own schedule, and the wait shortens as internal links and site standing improve. Pages stuck past a few weeks usually need a structural push, not more waiting.