"Discovered, currently not indexed" means Google found your URL and deliberately postponed fetching it. Google's own definition names the reason, and it is not the one most guides give: "Typically, Google wanted to crawl the URL but this was expected to overload the site; therefore Google rescheduled the crawl" (support.google.com, checked August 2026). That is a statement about your server, not your writing.
The gap between that sentence and the advice you will find elsewhere is why we built the drop-out alerting in our Bulk Google Index Checker around status rather than volume. Almost every article on this status blames crawl budget or weak internal linking. Google blames capacity. Acting on the wrong one costs weeks, because the two have no fixes in common.
What does "Discovered, currently not indexed" actually mean?
It means the URL is known and queued, and Google chose not to fetch it yet. Nothing has been evaluated. Your content has not been judged, your title has not been weighed, your internal links have not been counted, because none of that happens until a crawler actually loads the page.
That single fact rules out most of the work people do in response. Rewriting a page Google has never fetched cannot change its status, since the new version is as unfetched as the old one. The page is not competing badly; it is not competing at all.
The important word in Google's definition is "rescheduled". This is not a rejection and not a queue you have fallen out of. It is a deferral with an unstated date, made by a system that decided fetching your URL right now looked expensive.
Why is this a server problem rather than a content problem?
Because Google throttles crawling to protect your site, and it says so plainly. From Google's crawling documentation: "Google wants to crawl your site without overwhelming your servers. To prevent this, Google's crawlers calculate a crawl capacity limit" (developers.google.com, checked August 2026).
That limit is not fixed. Google describes exactly what moves it in both directions: "If the site slows down (latency increases or response times become longer), or responds with server errors (5xx HTTP status codes) or rate-limiting signals (such as HTTP 429), the limit goes down and Google crawls less." And the reverse: "If the site responds consistently and its response times (including latency and Time-to-First Byte) remain stable or improve, the limit goes up."
Read those two sentences together and the whole status makes sense. Slow or flaky responses shrink the number of connections Google will use on you. A smaller allowance means URLs sit in the discovered queue longer. The status is downstream of hosting behaviour, and it is the only major Search Console indexing status that is.
Source of truth
Crawl capacity limit
Response time and Time-to-First Buffer
Stable or improving times raise the limit; slower times lower it
Server errors (5xx)
Push the limit down, even when the pages themselves are fine
Rate limiting (HTTP 429)
Read as an explicit signal to back off
Crawl demand
Popularity and staleness decide what Google wants, capacity decides what it can take
Your word count
Not a factor: the page has not been read
Your internal links
Affect discovery and demand, not the capacity ceiling
Google publishes no numeric threshold for any of this, and anyone quoting you a specific "safe" response time is inventing it. What the documentation supports is the direction of travel, not a target to hit.
How is it different from "Crawled, currently not indexed"?
They are one word apart and need opposite fixes. Discovered means Google has not fetched the page, so the blocker sits on the delivery side. Crawled means Google fetched it, read it, and declined to index it, so the blocker is the page.
Getting this backwards is expensive in both directions. Rewriting content for a Discovered URL changes a page nobody has read. Buying faster hosting for a Crawled URL speeds up delivery of a page Google has already assessed and turned down. We have watched a fortnight go into a content rewrite for pages whose only real problem was a slow origin.
The verdict for the crawled-and-declined case is a quality judgement, and Google's guidance there ends with an instruction that surprises people: do not resubmit. That reasoning is worth reading on its own, in what "Crawled, currently not indexed" actually means.
What should I check on my server?
Start with response time under load, not response time when you test one page on a quiet afternoon. The number Google reacts to is what its crawler experiences while fetching many URLs in sequence, which is precisely when shared hosting, an unwarmed cache or an N+1 query in a template starts to show.
Four things are worth looking at, roughly in this order. Time-to-First-Byte on a cold, uncached page, because that is the case a crawler hits most. Your error rate for 5xx responses over the last month, since Google names those explicitly as a reason to back off. Any rate limiting or bot protection that returns 429 to a crawler, which Google reads as an instruction to slow down. And whether your host throttles concurrent connections, because a crawler opening several at once is exactly the pattern cheap plans clamp.
Search Console's Crawl Stats report is the honest source here, because it shows what Googlebot actually measured on your site rather than what a synthetic test measured from a datacentre. If average response time there is trending up, that trend is the story, whatever a one-off speed test says.
Sheer URL count matters too, though not in the way "crawl budget" articles imply. A site that generates tens of thousands of near-identical filter and tag URLs spends its capacity on them, and genuine pages wait behind that queue. Cutting the junk is usually cheaper than buying more server.
Does adding internal links help?
Sometimes, but for a different reason than the advice assumes. Internal links raise crawl demand: they tell Google a URL matters and is worth reaching sooner. They do nothing to the capacity limit, which is set by how your server behaves.
So links help when the problem is that Google does not consider the page important enough to spend a constrained allowance on. They do not help when the allowance itself is the bottleneck. On a slow origin, adding links moves your URL up a queue that is barely advancing.
The practical read: link the page properly because it should be linked anyway, then judge whether the status moves. If a well-linked page still sits in Discovered for weeks while your Crawl Stats show rising response times, you have your answer, and it is not an editorial one.
How long should I wait before acting?
Give it two to four weeks before treating a single Discovered URL as a problem. New URLs on a modest site routinely wait that long and then get crawled with no intervention, because Google is working through a queue on its own schedule.
Volume changes the reading entirely. One URL is noise. Several hundred URLs stuck in Discovered, or a number that keeps climbing as you publish, is a capacity signal and should be treated as an infrastructure ticket rather than an SEO task.
Watching that number move is the part Search Console makes awkward, since the Page Indexing report aggregates by status, lags by days, and caps its example URL lists at 1,000. Getting a per-URL answer means going through the API, which has its own ceiling of 2,000 inspections per property per day, worked through in the URL Inspection API's 2,000-a-day limit.
Will submitting the URL make Google crawl it sooner?
It can, and this is the one status where a manual submission is genuinely reasonable. Request Indexing puts the URL into a priority queue, which addresses demand. If the page has simply not surfaced yet, that nudge sometimes brings the crawl forward.
What it cannot do is create capacity. If Google is deferring because your server looks strained, a priority request lands in the same constrained pipe as everything else. Submitting the same URL repeatedly does nothing beyond spending your own daily allowance.
The honest sequence, then, is: fix the delivery side first, submit second, and confirm with a real check rather than by refreshing the report. How to check if a page is indexed by Google covers why a site: search cannot confirm this for you, in Google's own words.
FAQ
How long does "Discovered, currently not indexed" last?
Commonly two to four weeks for a single URL on a modest site, and sometimes indefinitely if the underlying cause is never addressed. Google gives no timeframe because the status is a deferral rather than a decision: the URL sits in a queue until crawl capacity and crawl demand both allow the fetch. One URL waiting is normal. Hundreds waiting, or a count that grows every time you publish, is a capacity signal rather than a delay.
Does Discovered mean my content is bad?
No, and it cannot mean that. Google has not fetched the page, so nothing about the content has been read or assessed. Quality judgements produce a different status entirely: "Crawled, currently not indexed" is the one that means Google looked and declined. If you rewrite a page sitting in Discovered, Google is still holding the same unfetched URL, and the status will not move because of the edit.
Will faster hosting fix Discovered, currently not indexed?
Often, when response times are genuinely the constraint. Google states that if response times stay stable or improve, its crawl capacity limit rises and more connections are used to crawl your site, while slower responses, 5xx errors and HTTP 429 rate limiting push that limit down. Check Search Console's Crawl Stats report for what Googlebot actually measured before spending money, since a synthetic speed test from a datacentre does not reflect what a crawler experiences fetching many pages in sequence.
Should I request indexing for pages stuck in Discovered?
It is reasonable once, unlike with the crawled-and-declined status where Google explicitly says not to bother. Request Indexing raises priority, which can help if the URL simply has not surfaced yet. It cannot create crawl capacity though, so if Google is deferring because your server looks strained, the request joins the same constrained queue. Fix delivery first, submit second, and do not resubmit the same URL repeatedly.