Discovered – Currently Not Indexed: Why Google Found Your Pages and Never Came Back

There are two Search Console statuses that look like siblings and are diagnosed completely differently. “Crawled – currently not indexed” is a verdict on your page. “Discovered – currently not indexed” is a verdict on your server and your URL inventory — Google never read the page at all. Treating the second like the first is the most common wasted week in technical SEO: teams rewrite content that Googlebot has never fetched.

“Discovered – currently not indexed” is a Google Search Console Page Indexing status meaning Google knows the URL exists — from a sitemap or an internal link — but has not fetched it yet. Unlike “Crawled – currently not indexed”, no evaluation of the page has taken place, so the cause lies in crawl scheduling rather than in content quality.

Key takeaways

• Google’s definition names the cause, and it is not your content. The Page Indexing report states: “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.”
• The empty last-crawl date is the diagnostic. Google notes this is why the last crawl date is empty on the report. If there is a crawl date, you are looking at a different status.
• Google treats this status as a crawl-budget symptom. Its crawl-budget guide lists sites with a large portion of their total URLs classified as “Discovered - currently not indexed” as one of three site types the guide is written for.
• “Perceived inventory” is the lever you control most. Google says so directly: without guidance, it tries to crawl everything it knows about, and this is the factor that you can positively control the most.
• On a small site it is usually a discovery problem, not a capacity one. Google’s own advice is that if your site has fewer than 500 pages you probably don’t need this report — at that scale the URLs are almost always poorly linked rather than deprioritised.

What the status actually means

Google’s definition is unusually specific, and worth reading twice:

“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.”

Three things follow from that sentence, and each rules out a category of fix people reach for.

Googlebot has never fetched the page. No HTML was read, no rendering happened, nothing was evaluated. So content quality, thin copy, duplicate paragraphs, missing schema, word count — none of it is in play, because none of it has been seen. This is the whole difference from crawled – currently not indexed, where the page was read and judged.

Google has decided the fetch was expensive. “Expected to overload the site” is a statement about your server’s observed behaviour, not about the page.

The crawl was rescheduled, not cancelled. URLs move out of this status on their own routinely. A handful of them on a healthy site is normal and needs nothing from you.

That last point matters for prioritisation. This status becomes a problem at proportion, not at presence. A dozen URLs in Discovered on a 300-page site is noise. Forty per cent of a 200,000-URL catalogue sitting there is the single most important finding in the audit.

The three real causes, in the order worth checking

Google’s stated cause — server capacity — is real but partial. In practice this status has three drivers, and the fastest diagnosis is to work through them in this order, because the cheapest fix is not the first one people try.

1. Crawl capacity: your server is telling Google to back off

Google calculates a crawl capacity limit, which it also calls hostload, to avoid overwhelming your servers. The mechanism is documented and it is a feedback loop:

“If the site responds consistently and its response times (including latency and Time-to-First Byte) remain stable or improve, the limit goes up… 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.”

So intermittent 5xx responses, a slow origin, or an aggressive WAF returning 429 to Googlebot will each shrink the crawl rate — and a shrunken crawl rate presents as URLs stuck in Discovered. Note that Google treats a site as a unique hostname for this purpose: www.example.com and shop.example.com have separate crawl budgets, so a struggling subdomain does not drag down its sibling.

Check this first because it is measurable and because it is the cause Google actually names. Pull server logs filtered to Googlebot and look at the response-code distribution and the TTFB trend over the last 90 days. If 5xx or 429 responses to Googlebot are anything other than a rounding error, stop reading and fix that. The method is in log file analysis for SEO.

2. Crawl demand: Google can crawl the pages and does not want to

Capacity is only half of it. Google’s summary is explicit: crawl budget is “the set of URLs that Google can and wants to crawl”, and it adds that “even if the crawl capacity limit isn’t reached, if crawl demand is low, Google will crawl your site less.”

Demand is driven by three documented factors: perceived inventory, popularity and staleness. Google flags the first as the one you influence most:

“Without guidance from you, Google tries to crawl all or most of the URLs that it knows about on your site. If many of these URLs are duplicates, or you don’t want them crawled for some other reason (removed, unimportant, and so on), this wastes a lot of Google crawling time on your site. This is the factor that you can positively control the most.”

This is the cause behind most large-site Discovered pile-ups, and it is rarely where teams look. Faceted navigation, session parameters, sort orders, paginated variants, printer-friendly duplicates and internal search results generate URLs faster than any crawler will consume them. Google is not refusing to crawl your product pages; it is working through a queue in which your product pages are a minority.

3. Discovery: the URL is known but barely linked

The third case is the one that dominates on smaller sites, and it is not really a budget problem at all. A URL that appears only in an XML sitemap, with no internal links pointing at it, carries almost no signal that it matters. Google knows it exists — hence Discovered — and has no reason to hurry.

Sitemap inclusion is a hint, not an instruction. If a page’s only route in is the sitemap, it is an orphan wearing a disguise. Finding those systematically is what an internal linking audit is for.

Telling the three apart in twenty minutes

Signal	Points to	Where to look
5xx or 429 responses to Googlebot; rising TTFB	Crawl capacity	Server logs, Crawl Stats report
”Host had a problem” flags in Crawl Stats	Crawl capacity	Search Console → Settings → Crawl stats
Googlebot spending most requests on parameter or facet URLs	Crawl demand	Server logs, grouped by URL pattern
Affected URLs share a template or a parameter	Crawl demand	Export the report, sort by URL pattern
Affected URLs have zero internal links	Discovery	Crawl your own site, count inbound links
Site under ~500 pages, few URLs affected	Usually discovery, or nothing	Internal link graph

The export is the underused step. Take the Discovered URL list out of Search Console and look at it as a set rather than as individual rows. If ninety per cent of the affected URLs share one path segment or one query parameter, you have your answer without touching a log file — and the answer is inventory, not content.

What actually fixes it

Ordered by how much of the problem each one typically removes.

Cut the inventory Google is wading through. This is the highest-leverage change on any large site, and Google’s guidance is specific about the tools:

• Consolidate duplicates so crawling focuses on unique content rather than unique URLs.
• Block genuinely unimportant URLs in robots.txt — Google gives infinite-scrolling pages that duplicate linked content, and differently sorted versions of the same page, as its own examples. The mechanics, including the noindex trap, are in robots.txt for developers.
• Return 404 or 410 for permanently removed pages. Google’s wording is worth keeping: it “won’t forget a URL that it knows about, but a 404 status code is a strong signal not to crawl that URL again.” The corollary is the part people miss — blocked URLs stay part of your crawl queue much longer and get recrawled when the block is removed. If a page is gone, delete it properly rather than hiding it.
• Eliminate soft 404s. Google states that soft 404 pages will continue to be crawled, and waste your budget. Client-rendered applications manufacture these by the thousand through catch-all server rules; the mechanism is covered in Vue SEO and single-page application SEO.

Make the server cheaper to crawl. Faster responses raise the capacity limit directly, since the limit is a function of observed latency and error rate. Google also asks for HTTP caching support: returning 304 (Not Modified) when a page has not changed lets Google reuse its cached copy instead of re-downloading. On a large catalogue that is a substantial share of crawl traffic reclaimed for free. Where the latency is front-end rather than origin, Core Web Vitals for developers covers the measurement.

Shorten redirect chains. Google’s guidance is one line — “avoid long redirect chains, which have a negative effect on crawling” — and every hop is a request spent reaching a page rather than reading one.

Link the pages properly. If the URLs are orphaned, internal links are the fix and nothing else will substitute. Link from pages that are themselves crawled often: category hubs, the pillar article in the cluster, recently updated pages. A link from a page Google visits weekly is worth more than a sitemap entry.

Keep sitemaps honest. Google reads them regularly and recommends the <lastmod> tag for updated content. A sitemap that lists every URL with today’s date, or that includes redirected and 404 URLs, is training Google to discount it.

Then wait, and re-check the proportion. Crawl scheduling responds over weeks, not hours. Track the Discovered count as a percentage of total known URLs, not as an absolute number — on a growing site the absolute number can rise while the problem shrinks.

What does not fix it

Requesting indexing. The URL Inspection tool’s Request Indexing puts a URL in a priority queue, which does nothing about a site-level capacity or demand problem, and Google is clear that requesting a recrawl multiple times for the same URL won’t get it crawled any faster. For a handful of genuinely important URLs it is reasonable. As a response to ten thousand affected URLs it is not a strategy, and the daily quota makes that arithmetic obvious.

Rewriting the content. Google has not read it. Improving a page nobody fetched changes nothing about whether it gets fetched.

Resubmitting the sitemap. Google already knows about the URLs — that is what Discovered means. Resubmission communicates nothing new.

Adding schema. Same reason as rewriting. Structured data is read during crawling, which has not happened.

Each of these is popular because each is quick. None of them addresses either half of what Google says the problem is.

When to leave it alone

Not every Discovered URL deserves attention, and clearing the report is not the goal — getting the right pages crawled is.

If the affected URLs are pages you would not miss, the correct action is to stop Google knowing about them: remove them from the sitemap, drop the internal links, and let them fall out of the queue. That is a genuine improvement, because it reduces perceived inventory and returns crawl demand to the pages that matter.

And if your site is under a few hundred pages with a handful of URLs in this status, Google’s own guidance applies: if pages seem to be crawled the same day that they are published, you do not have a crawl-budget problem, and the crawl-budget playbook is not for you. Check the affected URLs have real internal links, then leave it.

Where this fits

Discovered is the symptom; the system underneath it is the subject of crawl budget, which covers capacity and demand in full, and how to measure both. The sibling status, where Googlebot did read the page and declined to index it, is crawled – currently not indexed — a content verdict with a content fix. The broader indexation decisions sit in canonical vs noindex, and the whole indexation layer is one phase of the 12-phase SEO and GEO audit.

If a large share of your URLs is stuck in this status and you would rather have the inventory problem diagnosed than guessed at, that is what GEO and technical SEO consulting covers.

FAQ

What does “Discovered – currently not indexed” mean?

Google’s Page Indexing report defines it as: “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.” Google knows the URL exists, from a sitemap or an internal link, but has never fetched it. Nothing about the page’s content has been evaluated, because no content has been read.

How is “Discovered” different from “Crawled – currently not indexed”?

Discovered means Googlebot has never fetched the page — the last crawl date is empty. Crawled means it fetched and read the page, then chose not to index it. The distinction decides the fix entirely: Discovered is a crawl-scheduling problem, addressed through server responsiveness, URL inventory and internal linking; Crawled is a quality judgement, addressed by changing the page. The second is covered in crawled – currently not indexed.

Will requesting indexing fix “Discovered – currently not indexed”?

Rarely, and never at scale. Request Indexing prioritises one URL; it does not raise your crawl capacity limit or reduce the inventory Google is working through, and Google notes that requesting a recrawl multiple times for the same URL won’t get it crawled any faster. Use it for a genuinely important page you have just published. Do not use it as a response to a report with thousands of rows.

How long does it take for pages to move out of “Discovered”?

There is no published interval, and the honest answer is that it depends on which of the three causes applies. Capacity fixes — removing 5xx responses, cutting latency — tend to show first, because Google’s capacity limit adjusts automatically as the site’s measured health improves. Inventory changes take longer, since Google has to work the removed URLs out of its queue. Measure the affected URLs as a share of total known URLs and look at the trend over weeks.

Does “Discovered – currently not indexed” mean my content is bad?

No. Google has not read your content, so it cannot have judged it. The status is about crawl scheduling. If you want the status that is a content judgement, it is “Crawled – currently not indexed”, where the page was fetched, evaluated and left out.

Can a small site have a crawl budget problem?

Usually not, and Google says as much: if your pages are crawled the same day they are published, you don’t need the crawl budget guide, and if your site has fewer than 500 pages you probably don’t need the Page Indexing report either. On a small site, URLs stuck in Discovered are nearly always discovery problems — pages that exist only in the sitemap with no internal links pointing at them. Fix the linking, not the budget.

Should I remove “Discovered” URLs from my sitemap?

Only if you do not want them indexed. If the pages matter, removing them from the sitemap makes discovery worse. If they do not matter — old parameter URLs, thin tag archives, filtered variants — then yes: taking them out of the sitemap and unlinking them reduces the inventory Google is working through, which is the factor Google says you control most.