Discovered Currently Not Indexed on Large Sites: Crawl Demand Fixes

"Discovered - currently not indexed" means Google knows a URL exists but has not crawled it yet. On a large site, this status almost always points to a crawl budget problem: Google has decided the pages are not worth fetching at the rate they are being discovered. The fix is not a reindex request. It is demonstrating to Google that those pages deserve crawl priority by improving their internal link signals, their content quality, and the overall site health score Google uses to allocate crawl rate.

This guide covers the causes specific to large sites and the concrete steps to work through them.

---

What "Discovered" Actually Means in the Page Indexing Report

When Google first discovers a URL through a sitemap or an internal link, it adds it to a crawl queue. If Google's systems decide the URL is lower priority than other work competing for crawl slots, the URL stays in that queue. The Page Indexing report in Google Search Console will show it as "Discovered - currently not indexed."

According to Google Search Central documentation, crawl budget is determined by crawl rate limit (how fast the site can respond before Googlebot slows down) and crawl demand (how much Google perceives the pages as worth crawling). Both matter, but on large sites the demand side is usually the problem.

A URL stuck in "Discovered" is different from "Crawled - currently not indexed." A crawled-but-not-indexed page was fetched and evaluated; Google decided not to index it. A discovered-but-not-crawled page never got fetched. Google's queue management deprioritized it before Googlebot arrived.

---

Why Large Sites See More of This Status

Small sites rarely run into crawl budget constraints. Google crawls a 50-page blog completely in a single visit. A 50,000-page ecommerce catalog or a publisher site with 10 years of archives hits real limits.

The specific patterns that create a backlog of "Discovered" pages on large sites:

Thin or templated pages at scale. If Google crawls 1,000 of your category pages and finds thin content, it will assign lower crawl priority to the remaining thousands. The crawl signal from past pages predicts the value of future ones.

Weak internal linking to deeper pages. Pages only discoverable through paginated navigation, faceted filters, or XML sitemaps without any editorial links often sit in the queue indefinitely. Google assigns crawl priority partly based on PageRank signals, and pages with no internal link equity get none.

Site health problems dragging down crawl rate limit. If Googlebot encounters slow server responses, 5xx errors, or redirect chains at scale, it lowers its crawl rate to avoid overwhelming the server. That means fewer total crawl slots, and the already-deprioritized pages fall further behind.

Sitemap bloat. Including URLs in sitemaps that are noindexed, redirected, or canonicalized to other pages tells Google your sitemap is not reliable. That reduces how much weight Google gives sitemap-discovered URLs when setting their crawl priority.

---

How to Diagnose the Scope

Open Google Search Console and go to Indexing > Pages. Filter by reason "Discovered - currently not indexed." Export the list. Look for patterns:

• Are the affected URLs concentrated in one section (a product category, a date range, an author archive)?
• Do they share URL patterns that suggest they are auto-generated or templated?
• What is the oldest discovery date shown for the affected URLs? A URL sitting discovered for 90 days on a large site is not an anomaly; it is a signal.

If more than 20 percent of your indexed pages are in this state, you have a structural crawl demand problem, not an isolated batch of pages to request indexing for.

---

Fix 1: Increase Internal Link Equity to Affected Pages

The single most reliable way to pull pages out of a "Discovered" backlog is to give them internal links from pages Google crawls regularly.

For each section with stuck pages:

1. Find your highest-traffic pages in the same section from the Performance report.
2. Add links from those pages to the affected URLs. Even two or three editorial links from a crawled page to a discovered page changes its crawl priority.
3. For product catalogs or large archives, audit your navigation menus and category pages. If Googlebot can reach a page in four or more clicks from the homepage, it is a candidate for the discovered queue. Bring important pages within two clicks.

The google-search-console-discovered-currently-not-indexed guide covers what this status means and when it clears on its own. The fix for large sites goes further: systematic internal link auditing by section, not page-by-page reindex requests.

---

Fix 2: Prioritize the Pages Worth Indexing

Not every discovered page deserves to be indexed. Before you spend time on crawl optimization, audit what is actually in that queue.

For each discovered URL, ask:

• Does this page have unique content that serves a searcher query no other page on the site answers?
• Does it earn internal links from elsewhere on the site?
• Would Google users find it useful if they landed on it from search?

If the answer to any of these is no, the right move is to either improve the page or consolidate it. Noindexing or canonicalizing low-value pages you do not want indexed reduces sitemap noise and concentrates crawl budget on pages that matter. This is a crawl budget optimization principle: the goal is not to index everything, it is to index everything worth indexing.

Removing junk from your sitemaps and adding a noindex tag to thin pages you are not willing to improve frees up crawl slots for the pages you care about.

---

Fix 3: Clean Up Sitemaps

Large sites often accumulate sitemap problems over time: URLs that return 404s, pages that have been canonicalized to a different URL, filtered or faceted URLs that should never have been in the sitemap.

Run a sitemap audit:

1. Download your sitemap URLs.
2. Test a sample for redirect chains, noindex tags, and canonical mismatches. If you find these at scale, your sitemap is undermining your crawl signal.
3. Remove URLs from the sitemap that are not the canonical version of themselves. Only submit canonical, indexable, 200-status URLs.

Google will crawl a site with a clean sitemap more aggressively than a site where it has learned that sitemap entries frequently lead to redirects or noindexed pages.

---

Fix 4: Improve Content Signals on Thin Sections

If Googlebot has crawled a section and found it largely thin, it will deprioritize the rest of that section's undiscovered URLs. The crawl signal from past pages predicts future value.

To change that signal:

• Identify which section the discovered pages belong to.
• Audit the already-indexed pages in that section. Are they thin? Are they ranking? Are users engaging with them?
• Improve the worst-performing indexed pages in the section first. As those pages generate more engagement signals, Google re-evaluates the crawl priority for nearby URLs.

This takes longer than a quick internal link fix, but for sections where every page is templated and thin, it is the only approach that works long-term.

---

Fix 5: Monitor Server Response Health

Googlebot throttles its crawl rate when it encounters server errors. Use the Crawl Stats report in Google Search Console (Settings > Crawl Stats) to check:

• Average response time over the last 90 days. Spikes above 500ms can trigger crawl slowdowns.
• Any 5xx error responses Googlebot received. Even a small percentage of server errors on a large site can deprioritize hundreds of discovered pages.

If you see response time spikes correlating with the period when pages entered the discovered queue, server health is a contributing factor. Address hosting and caching issues before expecting crawl budget to improve.

---

What Not to Do

Do not use the "Request Indexing" button for large batches. The URL Inspection tool's Request Indexing option is designed for individual, high-priority pages. Google Search Central explicitly notes it is not intended for site-wide crawl issues. Using it on hundreds of discovered URLs wastes your request quota and addresses symptoms rather than the cause.

Do not add more pages to your sitemap to push Google to crawl them. Adding thin or low-quality pages to push Googlebot to crawl discovered URLs will only lower the signal further. Quality over quantity in sitemaps is not optional on large sites.

Do not wait it out without changes. "Discovered" URLs can sit in the queue for months or years on large sites if no structural changes improve their crawl demand. Waiting without action is not a strategy.

---

How Long It Takes

Internal link improvements can move some pages from "Discovered" to "Crawled" or "Indexed" within a few weeks, depending on the site's overall crawl rate. Full resolution of a large backlog typically takes two to four months if the underlying structural issues are addressed consistently.

Track progress in the Page Indexing report. Export the "Discovered" count monthly. A declining count over time means your crawl demand improvements are working.

---

Key Takeaways

• "Discovered - currently not indexed" on large sites is primarily a crawl demand problem, not a reindex problem.
• Internal link equity is the fastest lever: pages with editorial links from crawled content get deprioritized less.
• Sitemap hygiene matters: sitemaps bloated with redirected or noindexed URLs lower Googlebot's trust in all sitemap-submitted URLs.
• Thin content in a section depresses crawl priority across the whole section, not just individual pages.
• Monitor the Crawl Stats report in Search Console settings for server health signals alongside the Page Indexing report.

---

Frequently Asked Questions

How is "Discovered - currently not indexed" different from "Crawled - currently not indexed"? "Discovered" means Googlebot has not fetched the page yet. It is in the crawl queue but has not been evaluated. "Crawled - currently not indexed" means Google fetched it but decided not to index it, usually because of content quality issues or signals that the page is not worth including in results.

Can I request indexing for discovered pages in bulk? The URL Inspection tool handles one URL at a time and has a daily limit. It is intended for single high-priority pages, not bulk crawl queue management. For large batches of discovered URLs, the right approach is structural: improve internal links, clean up sitemaps, and improve content quality in affected sections.

Does submitting a sitemap help pages move out of the discovered state? Yes, if the sitemap is clean. Submitting a sitemap with only canonical, indexable, 200-status URLs tells Google that submitted pages are reliable candidates. Including redirected, noindexed, or error pages in the sitemap reduces that trust signal over time.

How do I find which section has the most discovered pages? Export the "Discovered - currently not indexed" URL list from the Page Indexing report in Search Console and open it in a spreadsheet. Sort or group by URL prefix to identify which sections of the site have the highest concentration of discovered pages.

Will adding more content to a thin page move it out of the discovered queue? Not directly, since the page has not been crawled yet. But improving already-indexed pages in the same section sends a better content signal for the section as a whole, which can increase how aggressively Google crawls new pages in that section over time. The more reliable fix is adding internal links from crawled pages.