Last updated: September 18, 2026
Discovered currently not indexed is a Google Search Console status that means Google knows a URL exists, usually from a sitemap or a link, but has not crawled it yet. Nothing on the page has been read, nothing has been judged, and the last-crawl column in the report is empty. Google’s own description of the status is that it typically wanted to crawl the URL but expected the crawl to overload the site, so it rescheduled. That explanation covers some cases and not others. This guide explains what the status actually tells you, how it differs from the better-known “crawled, currently not indexed”, whether crawl budget is the cause, what sitemaps can and cannot do about it, an order of operations that fixes it, and why a page in this state is invisible to AI Overviews, AI Mode and every other answer engine as well as to classic search.
The definition is not in dispute. As Search Engine Land’s guide to the status puts it, the page has been found but not crawled or indexed, Google’s documentation says it may come back to the URL later without any extra effort on your part, and the factors that hold a crawl back are server or technical issues restricting Google’s crawl capability and issues with the page itself, including quality. The same guide reports a pattern seen across multi-million-URL sites: URLs that are not crawled at least once every 75 to 140 days tend to fall out of the index, which is why a growing “discovered” queue is a leading indicator rather than a cosmetic one.
If you would rather have your non-indexed URLs inventoried and prioritised automatically, sign up for free and NytroSEO will start from your sitemap and Search Console data.
The reason the status deserves its own guide is that it is routinely confused with its neighbour. “Crawled, currently not indexed” means Google fetched the page and chose not to index it, which is a quality judgement about the page. “Discovered, currently not indexed” means Google has not fetched it, which is a judgement about priority, capacity or reachability. The fixes are different, and applying the content-quality fixes for the first to a site suffering from the second wastes months.
Lee Agam, founder and CEO of NytroSEO, treats the discovered queue as a measure of how much of a site Google has decided is not worth its time yet. In his experience with large sites, the phrase “expected to overload the site” is rarely literal; Googlebot is polite and most servers cope. What the status usually means is that Google’s crawl demand for that section of the site is low, because the URLs are weakly linked, look similar to thousands of others, or sit behind a sitemap that lists everything indiscriminately. His order of work is to make the queue smaller before trying to make Google crawl faster: remove the URLs that should never have been discoverable, link the ones that matter from pages Google already trusts, and keep the sitemap honest. He also points out that every URL in the queue is a URL no AI system can cite, which is why the status now has a cost beyond rankings.
What discovered currently not indexed means in Search Console
The google search console discovered currently not indexed status lives under Indexing, then Pages, in the list of reasons why pages are not indexed. Some tools and older guides write it as discovered not currently indexed; it is the same state. Google’s Page indexing report describes it in one sentence: 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, so Google rescheduled the crawl. Because no crawl has happened, the URL has no last-crawl date and no fetched HTML for Google to evaluate.
Three things follow from that definition.
It is not an error. A new page on a healthy site will pass through this state for hours or days on its way to being crawled and indexed. A handful of low-value URLs can sit in it indefinitely without harm.
It is a queue, and queues have causes. A URL is in it because Google discovered it and has not yet allocated a crawl. The allocation depends on how much Google wants to crawl your site, how much it can without slowing your server, and how important the specific URL looks relative to everything else it has discovered.
It is upstream of everything. Uncrawled means unread. A page in this state cannot rank, cannot be selected for an AI Overview or AI Mode answer, and cannot be retrieved by any assistant that depends on an index. Our guide to why your best pages cannot rank if Google never indexes them covers the downstream cost.
Discovered vs crawled: the distinction that decides the fix
The diagram above separates the two statuses by what Google has and has not done; the fixes follow from that.
Crawled, currently not indexed is a post-fetch judgement. Google read the page and decided it did not add enough to the index: thin, duplicated, low-value, or crowded out by better pages. The fix is the page and its place in the site. Our guide to crawled currently not indexed and its causes covers that state in detail.
Discovered, currently not indexed is a pre-fetch decision. Google has not read the page, so it cannot have judged the content. The fix is reachability and priority: server health, internal links, sitemap hygiene and reducing the volume of low-value URLs competing for the same crawl. If your discovered count is large and your crawled-not-indexed count is also large, work on the crawled set first, because it tells you what Google thinks of the pages it does reach.
Can poor crawl budget cause discovered currently not indexed?
Yes, and it is the most common cause on large sites, but crawl budget is not one thing. Google describes it as the combination of crawl capacity, the rate Googlebot can fetch without degrading your server, and crawl demand, how much Google wants to fetch given the site’s popularity and how stale its copies are. A site can have a discovered backlog because capacity is low, because demand is low, or because the URL inventory is so large that even adequate capacity and demand cannot cover it.
Capacity problems show up as slow response times, 5xx errors and host-status warnings in the Crawl Stats report under Settings. When Googlebot meets timeouts during a crawl of many URLs on the same site, it backs off and reschedules, and rescheduled URLs are exactly what the discovered status describes. The fix is server performance, not SEO.
Demand problems show up as a discovered set concentrated in one section of the site: faceted category pages, filtered listings, tag archives, paginated series, parameter variants, user-generated pages. Google has discovered thousands of near-identical URLs and has decided the section is not worth the crawl. The fix is to reduce the inventory: consolidate, canonicalise, noindex or block the variants, and stop linking to the ones that should never have been discoverable.
Inventory problems are the large-site version of demand problems: the site simply has more discoverable URLs than Google will crawl in a reasonable period. Our guide to crawl efficiency and prioritising non-indexed URLs walks through the triage.
Two things do not help. Google does not honour a crawl-delay directive in robots.txt, and the Search Console crawl-rate limiter tool was retired in 2024, so there is no dial to turn; crawl rate is earned through server responsiveness and reduced by low-value inventory. And on small sites, sites with a few thousand URLs that change infrequently, crawl budget is almost never the cause. A small site with a persistent discovered backlog has a linking or quality problem, not a capacity problem.
How do sitemaps affect discovered currently not indexed pages?
A sitemap is how many of these URLs were discovered in the first place, so it is natural to look there for the fix. Its effect is real but narrower than most guides imply.
A sitemap announces that a URL exists and, through lastmod, when it last changed. It does not force a crawl and it does not confer priority; Google ignores the priority and changefreq fields. What it does is give Google a candidate list and a freshness signal, and the quality of that list affects how the candidates are treated. A sitemap that lists redirects, noindex pages, parameter variants and thin pages alongside the pages that matter teaches Google that the file is not a reliable guide to value, and the important URLs suffer with the rest.
So the sitemap work for a discovered backlog is subtraction. List only canonical, indexable URLs that return 200. Keep lastmod truthful, because a file where every URL was modified today is ignored as a freshness signal. Split large files by section so that the section with the backlog can be resubmitted and tracked on its own. Our note on whether to resubmit your sitemap every month explains why resubmission itself does nothing if the file has not changed.
Then pair the sitemap with internal links. A URL that appears in a sitemap but is linked from nowhere is, to Google, a URL the site itself does not think is important. The single strongest lever for a discovered URL is a contextual link from a page Google already crawls often.
Discovered currently not indexed how to fix: an order of operations
The order matters because each step changes what the next one is measuring. Do them in sequence and re-check the report after each.
The staircase above is the sequence; requesting indexing is deliberately the last step, not the first.
- Check server health. Open Crawl Stats and look at average response time, host status and the share of 5xx responses over 90 days. If Googlebot is meeting timeouts, nothing else you do will move the queue until that is fixed. Confirm in your logs that Googlebot is fetching at all and is not being challenged by a CDN rule.
- Add internal links to the URLs that matter. Take the discovered list, keep the URLs that should be indexed, and link each from two or three well-crawled, topically related pages with descriptive anchors. Bring important pages within three clicks of the homepage. This is the step that resolves most cases on its own.
- Clean the sitemap and the URL inventory. Remove non-canonical, noindex, redirecting and thin URLs from the sitemap; canonicalise or block the parameter and facet variants that inflate the discovered count; make lastmod accurate. The goal is a smaller, more credible queue.
- Improve the value of the pages you kept. If a discovered URL survives steps one to three and Google still does not crawl it, look at it the way Google will: does it add something the site does not already say? Merge, expand or remove.
- Request indexing for a handful of priority URLs, last. Use URL Inspection and Request Indexing for the ten or twenty pages that matter most commercially, after the structural work is done. Requesting indexing for hundreds of URLs does not fix the cause, and Google throttles the tool.
Then monitor weekly: the total discovered count, the URLs that moved into crawled or indexed, and any new URLs entering the state. A queue that shrinks after step two confirms a linking problem; one that only shrinks after step three confirms an inventory problem; one that does not move confirms step one was not really done.
Steps two and three are where large sites stall, because they are repetitive across thousands of URLs. NytroSEO’s automation keeps the sitemap scope and the canonical hints consistent by rule and monitors indexing state changes so the queue is tracked rather than rediscovered each quarter; it does not fix server capacity or write the content that makes a page worth crawling. Book a strategy meeting with the NytroSEO team if you manage a large site and want the discovered queue worked as one project.
Why discovered pages are invisible to AI search too
Every AI answer surface that cites the web depends on an index, and a URL that has never been crawled is in none of them. Google’s AI Overviews and AI Mode draw on Google’s index; a discovered-not-crawled page has no entry there and cannot be selected. ChatGPT, Perplexity, Gemini and Copilot either fetch pages directly or rely on a search index, and in either case the page has to be reachable and, in practice, linked from somewhere the crawler already visits.
This changes the cost of the status. A discovered backlog used to mean some pages did not rank. Now it means those pages cannot be cited, mentioned or summarised anywhere, at a time when a growing share of buyer questions are answered without a click. And the fix that resolves it, a smaller, better-linked, honestly mapped set of URLs, is the same fix that improves AI retrieval for the pages that are indexed, because crawlers of every kind spend their budget on what the site signals is important.
A practical rule for the AI era: treat the discovered list as a list of pages your site has told every crawler not to bother with. Either make them matter, by linking them and giving them something unique to say, or stop discovering them. The middle state, where they sit in a sitemap unlinked and unread, has no upside.
Frequently Asked Questions
It means Google knows the URL exists, usually from a sitemap or link, but has not crawled it yet. Google’s description is that it typically wanted to crawl the URL but expected the crawl to overload the site, so it rescheduled. Because no crawl has happened, the last-crawl date is empty. It differs from crawled – currently not indexed, where Google fetched the page and chose not to index it.
Work in order: confirm fast server responses and no 5xx errors in Crawl Stats, add internal links from well-crawled pages to the URLs that matter, clean the sitemap so it lists only canonical indexable URLs with accurate lastmod, improve the unique value of the pages you keep, and only then use Request Indexing for a small set of priority URLs.
On large sites, often yes. Slow responses, endless faceted or parameter URLs and thin pages consume crawl capacity and reduce crawl demand, so Google defers the rest. On small sites with a few thousand URLs crawl budget is rarely the cause; weak internal linking or thin content is more likely.
There is no fixed timeline. Well-linked pages on healthy sites are usually crawled within days to a few weeks; pages Google considers low priority can stay in the state for months. Reducing the queue, improving links and fixing server response times shorten the wait. Google may also return to the URL on its own.
Not on their own. A sitemap tells Google a URL exists and when it changed; it does not force a crawl, and Google ignores the priority and changefreq fields. Accurate lastmod values and removing non-canonical URLs help Google prioritise, but internal links and page value decide when the crawl happens.
Ready to shrink the discovered queue?
The fastest way to get a discovered page crawled is to make the queue around it smaller and the links to it stronger. Keeping the sitemap scope and canonical rules honest across thousands of URLs is rule-based work. Sign up for free to have NytroSEO track indexing state changes and keep the on-page layer consistent, or book a strategy meeting if you manage a large site or a client portfolio and want the backlog worked through as one project.
