Discovered - Currently Not Indexed: How to Fix It

You publish pages, submit the sitemap, wait a few weeks, and open Search Console to find a growing pile of URLs under “Discovered - currently not indexed.” The status sounds like a queue. For a handful of URLs on a new site, it often is. For hundreds or thousands of URLs that sit there for months, it is a signal about your site, and resubmitting URLs one by one will not fix it.

This guide explains what the status means, how it differs from its sibling “Crawled - currently not indexed,” and a diagnosis workflow that finds the actual cause.

What “Discovered - Currently Not Indexed” Means

Google’s Page indexing report uses this status for URLs that Google knows about but has not crawled yet. Google’s documentation explains the typical reason: Google wanted to crawl the URL, but doing so was expected to overload the site, so it rescheduled the crawl. That is why the “Last crawled” field is empty for these URLs.

In plain terms, three things have happened:

Google found the URL, through your sitemap, an internal link or an external link.
Google decided not to fetch it yet.
Without fetching it, Google cannot evaluate or index it.

The status itself does not say why Google deprioritized the crawl. In practice the cause falls into one of two buckets: the site can’t handle more crawling, or Google does not think the URLs are worth crawling soon.

Discovered vs Crawled - Currently Not Indexed

These two statuses are often confused, and they need different fixes:

	Discovered - currently not indexed	Crawled - currently not indexed
Has Google fetched the page?	No	Yes
Last crawled date	Empty	Present
Usual cause	Crawl capacity or low crawl priority	Google saw the content and chose not to index it (yet)
Where to look	Server performance, URL volume, internal linking, site-wide quality	Page quality, duplication, intent, thin content

With Crawled - currently not indexed, Google has already seen the content. The question is whether that content deserves an index slot: is it unique, useful, and the best version of itself on your site? Google’s documentation notes that such a URL may or may not be indexed in the future and that there is no need to resubmit it.

With Discovered - currently not indexed, Google has not seen the content at all. So the content of those specific pages is not the first suspect. The site around them is.

The Diagnosis Workflow

Work through these steps in order. Each one rules out a cause.

Step 1: Size and shape the problem

Export the URL list from the report (Search Console shows a sample of up to 1,000 URLs per status). Then group the URLs by pattern:

By folder: /blog/, /products/, /tag/
By parameter: ?page=, ?sort=, ?color=
By template: product, category, article, user profile

You are looking for concentration. “1,200 URLs, 1,000 of which are /tag/ pages” is a very different problem from “1,200 product pages spread across the catalog.”

Step 2: Check whether these URLs should exist at all

Ask, for each pattern: would I want this URL in Google?

Common answers are “no”: filter and sort parameters, tag archives with one post, internal search results, paginated archives deep into hundreds of pages, auto-generated location or tag pages with no unique content. When thousands of low-value URLs are discoverable, Google has to choose, and it is reasonable for it to defer crawling the long tail.

For these, the fix is to stop generating or linking to them, consolidate them with canonicals, or noindex them, not to push Google to crawl them. Our crawl budget optimization guide goes deeper on pruning URL patterns.

Step 3: Check server capacity

If the URLs are ones you do want indexed, check whether your site is slow or erroring for Googlebot:

Search Console → Settings → Crawl stats. Look at average response time and host status. A rising response time, or availability issues with robots.txt fetching, DNS or server connectivity, means Google will slow down.
Response codes in Crawl stats. A meaningful share of 5xx or 429 responses tells Google to back off.
Server logs, if you have them. Compare how often Googlebot hits important templates versus junk URLs. Our log file analysis guide shows how.

If server response times are slow, crawling will be slow. Fixing time to first byte, caching HTML, or moving heavy pages behind a CDN directly increases how much Google is willing to crawl. See TTFB optimization strategies.

Step 4: Check internal linking

URLs that are only discoverable through the XML sitemap are weak candidates for crawling. Google uses links to judge importance.

Run a crawl starting from the homepage (not from the sitemap) and check whether the affected URLs are found at all.
Check crawl depth: pages more than four or five clicks from the homepage are crawled less.
Check whether the URLs appear only in paginated lists at page 20 and beyond.

The fix is structural: link new content from hubs, category pages and related articles. A new article with three relevant internal links from pages that already get crawled tends to move out of “Discovered” much faster than one that relies on the sitemap alone. See internal linking strategies.

Step 5: Check site-wide quality signals

If a large share of a site’s already-indexed pages are thin, duplicated or rarely visited, Google has less reason to rush to crawl more URLs from the same site. This is the uncomfortable cause, and it is common on sites that publish at high volume.

Look at the indexed pages in the same folder or template. If many of them get no impressions in Search Console over several months, the new URLs are probably being judged by the same pattern. Improving or consolidating the weak pages often unlocks crawling of the new ones. Content pruning is frequently the fastest fix for this situation.

Step 6: Only then, request indexing selectively

For a handful of genuinely important pages, use URL Inspection → Request indexing. It has a daily quota and is not meant for bulk use. If you find yourself wanting to submit hundreds of URLs, you are treating a symptom; go back to steps 2 to 5.

A Worked Example

An illustrative case: a recipe site publishes about 15 new recipes a week. After a theme change, the “Discovered - currently not indexed” count climbs from a few dozen URLs to several thousand.

Grouping the exported sample shows the new recipes are only part of the problem:

Most URLs follow /recipes/?ingredient=...&diet=..., a new filter widget in the theme that renders crawlable links for every combination.
Crawl stats show average response time has roughly doubled since the theme change, because the filter pages are uncached and query-heavy.
New recipes are linked only from a paginated “Latest” archive and the sitemap.

The fix list:

Render filter options without crawlable <a href> links for combinations, and canonical any existing filter URLs to the clean recipe index.
Cache filter results and fix the slow database query.
Link each new recipe from its category hub and from two related recipes.

Over the following weeks, the filter URLs stop growing, response time recovers, and new recipes move from “Discovered” to indexed within days of publishing instead of lingering.

What Most People Get Wrong

The reflex is to treat “Discovered - currently not indexed” as Google being slow, and to push harder: resubmit sitemaps, request indexing, ping tools. That rarely changes anything, because Google already knows the URLs exist. Discovery is not the bottleneck; priority is. You raise priority by making the site easier to crawl (fast, fewer junk URLs) and by making the URLs look important (internal links, strong neighboring content).

Frequently asked questions

How long does “Discovered - currently not indexed” last?

For a few URLs on a new or small site, it can resolve within days or weeks as Google gets around to crawling them. If thousands of URLs sit there for months, there is usually an underlying cause such as crawl capacity, too many low-value URLs or weak internal linking.

Should I resubmit my sitemap to fix it?

Usually no. Google already knows these URLs, which is why they are listed as discovered. Resubmitting does not raise their crawl priority. Fix server speed, URL bloat and internal links instead.

Is “Discovered - currently not indexed” an error?

No. It is an informational status, not an error. It becomes a problem only when important pages stay in it for a long time or the count grows steadily.

What is the difference between discovered and crawled currently not indexed?

Discovered means Google knows the URL but has not fetched it. Crawled means Google fetched the page and decided not to index it for now, which usually points to content quality or duplication.

Can a slow server cause pages to not be indexed?

Yes, indirectly. If Google expects crawling to overload your server, it slows down and defers URLs, which keeps them in the discovered state. Faster responses and fewer errors increase how much Google crawls.