Discovered, Currently Not Indexed: Capacity Problem or Demand Problem, and How to Tell
· Royking Niba
Discovered, currently not indexed is a Page Indexing status in Google Search Console meaning Google knows the URL exists but has not fetched it yet. It is a crawling problem, not an indexing verdict: Google has not read the page, so it has not judged it. There are only two reasons a known URL waits, either the site cannot take more crawling or Google does not want the URL enough to spend a request on it, and the fix for one does nothing for the other.
What Google actually says
From the Page Indexing report help page, checked on 1 October 2026:
The page was found by Google, but not crawled yet. Typically, Google wanted to crawl the URL but this was expected to overload the site; therefore Google rescheduled the crawl. This is why the last crawl date is empty on the report.
Google Search Console Help, Page Indexing report
Compare the neighbouring status. "Crawled, currently not indexed" is defined as "The page was crawled by Google but not indexed. It may or may not be indexed in the future; no need to resubmit this URL for crawling." That one is a judgement on a page Google has read. Discovered is a queue. Treating a queue problem as a quality problem, or the reverse, is how teams spend a quarter rewriting content Google never fetched.
Google’s definition names capacity, the site being overloaded, as the typical reason. Its crawl budget guide supplies the other half. It defines crawl budget as "the set of URLs that Google can and wants to crawl", splitting it into a crawl capacity limit, which "limits the total amount of time your server spends holding connections open for Google", and crawl demand, driven by perceived inventory, popularity and staleness. "Can" is capacity. "Wants to" is demand. A URL sitting in Discovered is short of one of them.
Who this is really about
The crawl budget guide is addressed to "Large sites (1 million+ unique pages) with content that changes moderately often", "Medium or larger sites (10,000+ unique pages) with very rapidly changing content", and sites with a large share of URLs classified as Discovered, currently not indexed. That gives a quick first test. If your site has 400 pages and a third of them sit in Discovered, capacity is almost never the explanation, because a small site’s whole URL set fits in a fraction of a day’s crawling. On a small site, Discovered is a demand signal: Google has seen the URLs and has not prioritised them.
The original number: when a capacity backlog builds
On a large site the arithmetic is worth doing, because a capacity backlog grows linearly and quietly. Take a site where Googlebot makes about 6,000 requests a day, read from the Search Console crawl stats report, and where about 60 percent of those requests go to recrawling URLs Google already knows. That leaves roughly 2,400 requests a day for new URLs. The table shows what happens to the Discovered queue at different publishing rates.
| New URLs created per day | Requests available for new URLs | Daily change in the queue | Queue after 30 days | Queue after 90 days |
|---|---|---|---|---|
| 1,000 | 2,400 | Shrinks by 1,400 | Clears | Clears |
| 2,400 | 2,400 | Flat | No growth | No growth |
| 3,600 | 2,400 | Grows by 1,200 | 36,000 | 108,000 |
| 5,000 | 2,400 | Grows by 2,600 | 78,000 | 234,000 |
| 8,000 | 2,400 | Grows by 5,600 | 168,000 | 504,000 |
The shape is the point. Publishing 50 percent faster than the crawl can absorb does not slow indexing by 50 percent; it builds a queue of 36,000 URLs in a month that does not drain until publishing drops below the crawl rate. The model also shows the two ways out. Raise the 2,400, by making the server faster so Google’s capacity limit rises, or by cutting the recrawl share through removing duplicate and low-value URLs. Or lower the left-hand column, by not generating URLs nobody needed.
The model overstates one thing. Google does not crawl in first-in, first-out order; it prioritises URLs it expects to be valuable, which is exactly why weak URLs can sit in the queue indefinitely while strong ones jump it. That is the demand half showing through, and it is why a capacity fix alone rarely empties the report.
Telling capacity from demand
| What you see | Points to | Fix |
|---|---|---|
| Crawl stats show rising average response time, or a share of 5xx or 429 responses | Capacity | Server performance first. Google lists response times, server errors and rate-limiting among the crawl health signals that move the capacity limit. |
| Discovered count climbs in step with a feed, import or auto-generated section | Capacity and demand together | Stop generating the URLs, or gate them, before tuning anything else. |
| Small site, healthy server, a stable block of URLs never fetched | Demand | Internal links from pages Google already crawls often, and a hard look at whether the pages deserve to exist. |
| Discovered URLs are reachable only through the sitemap | Demand | Link them from the navigation or from related pages. A sitemap is a discovery hint, not a priority signal. |
| Discovered URLs are parameter or filter variants | Demand, correctly applied | Usually nothing. Consider whether they should be crawlable at all. |
A six-step fix, in the order that works
- Read the Crawl stats report before anything else: total requests per day, average response time, and the share of responses that are errors. That decides whether this is a capacity question at all.
- Group the Discovered examples by URL pattern. Google limits the example list to 1,000 rows, so treat it as a sample and look for the template or directory that dominates it.
- If one pattern dominates and you do not need those URLs indexed, stop producing them, or stop linking to them, and return 404 or 410 for the ones that exist.
- If the server is the constraint, fix response time and errors. Capacity rises when the site answers quickly and reliably.
- For the URLs you do want, add internal links from pages that are already crawled frequently. Orphaned and sitemap-only URLs are the most common demand failure on small sites.
- Request indexing through URL Inspection only for a handful of priority pages. It does not raise the site’s capacity, and Google says validation of a fixed issue "typically takes up to about two weeks, but in some cases can take much longer".
One rule to keep in view throughout: "Google doesn’t guarantee that all pages everywhere will make it into the Google index." The goal is not an empty report. It is getting the pages that earn traffic out of the queue, and keeping the ones that never will from joining it.
Leave a Reply