Discovered – Currently Not Indexed

What "Discovered – currently not indexed" means in Google Search Console, how it differs from "Crawled – currently not indexed," why it happens, and how to fix it.

First published: Jun 23, 2026 · Last updated: Jul 17, 2026 · Advanced
demand #11 in Indexing#36 in How Search Works#168 in Technical SEO#226 on the site
AIAuthored byAI v2
1 evidence signal on this page

"Discovered – currently not indexed" is a Google Search Console Page Indexing status: Google knows the URL exists (sitemap or link) but hasn't crawled it yet — the Last Crawl date is empty. That one fact separates it from "Crawled – currently not indexed," where the page was fetched and Google is still evaluating it for indexing. Google's two drivers are crawl capacity (crawling now would overload your server) and crawl demand (your site/pages aren't worth the crawl effort — a quality and internal-linking signal). It's often a sitewide signal, not a per-page bug, though that's a practitioner inference rather than a fact the status proves. The fixes are crawl-demand levers (internal links, content quality, cutting crawl waste, links to priority pages) and crawl-capacity levers (server speed/stability). "Request indexing" can nudge a few priority URLs but doesn't scale and doesn't fix the root cause — and getting a page crawled still doesn't guarantee indexing.

TL;DR — “Discovered – currently not indexedStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed.” means Google foundA 302 (\"Found\") is a temporary redirect: it forwards users to a new URL while telling search engines the original URL should stay in the index. It's a weak canonicalization signal, not the zero-equity dead end of SEO folklore. the URL but hasn’t crawled it — the Last Crawl date is empty, which is the single fact that separates it from “Crawled – currently not indexedA Google Search Console Page Indexing status meaning Googlebot fetched the page but Google decided not to index it — usually a content- or site-quality signal, not a technical error.” (fetched, then not kept). Google’s two drivers are crawl capacityThe number of URLs an engine will crawl in a timeframe. (crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. now would overload the server, so it rescheduled) and crawl demandCrawl demand is the 'want' side of crawl budget — how much a search engine wants to crawl a site or URL, driven by popularity, staleness, and perceived inventory (plus temporary spikes from site moves). It's distinct from crawl rate/capacity, the 'can' side. (your site/pages aren’t worth the crawl effort — a quality and internal-linking signal). It’s often a sitewide pattern, not a per-page bug. Fix the demand side first — internal linking, content quality, cutting crawl waste, links to priority pages — and the capacity side (server speed/stability) for large sites. Request indexing nudges a handful of URLs, doesn’t scale, and doesn’t fix the cause. And crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. a page still doesn’t guarantee it gets indexed.

What Google actually says it means

Straight from the Page Indexing reportThe Google Search Console report (formerly Index Coverage) showing how many of your URLs are indexed vs. not indexed, and grouping the not-indexed ones by reason. definition: “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.” Evidence for this claim Google defines Discovered - currently not indexed as a page it found but has not yet crawled, with an empty last crawl date. Scope: Google Search Console Page Indexing status. Confidence: high · Verified: Google: Page indexing report That last sentence is the whole tell — empty Last Crawl date = never fetched. If you inspect one of these URLs in GSCA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results., you’ll see no crawl recorded.

So this is a pre-crawl queue state. Nothing was indexed and removed; nothing was penalized. Google knows the URL exists — it came in through a sitemapA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing., an internal link, or an external link — and it simply hasn’t fetched it.

Discovered vs Crawled – currently not indexed

This is the distinction worth getting exactly right, because the two statuses have opposite root causes and opposite fixes. The contrast table lives in the Cheat Sheets tab; the short version:

  • Discovered – currently not indexedA Google Search Console Page Indexing status meaning Google knows the URL exists but hasn't crawled it yet — the Last Crawl date is empty. Often a crawl-capacity or crawl-demand (site-quality) signal. = not yet fetched. Empty Last Crawl date. It’s a crawl-priority / capacity signal — Google decided not to spend a crawl on it (yet).
  • Crawled – currently not indexed = fetched and not kept. There’s a Last Crawl date. Google looked and, for now, chose not to index it — an indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. evaluation that can have several causes (duplication, thin contentThin content is web content that provides little or no value to users. Google's spam policies name it 'thin content with little or no added value' — and it's about value per page, not word count., canonicalizationHow search engines pick one canonical URL among duplicates and consolidate signals onto it. to another URL, and more), not a single “quality verdict.”

Here’s the part people miss: getting a page out of Discovered doesn’t mean it gets indexed. It can move into Crawled – currently not indexed and still sit there. Crawling is a gate, not a guarantee — the same way it works everywhere else in search. Evidence for this claim Google says repeated recrawl requests for the same URL do not make crawling faster and recommends sitemaps for many URLs. Scope: URL Inspection request indexing; crawling still does not guarantee indexing. Confidence: high · Verified: Google: Ask Google to recrawl URLs

An empty Last Crawl field points upstream: Google knows the URL but has not spent a crawl on it yet. Source: Google Search Console Help

Google knows the URL. On the highlighted Discovered currently not indexed branch, Google has not fetched it, the Last Crawl field is empty, and diagnosis focuses on crawl priority or capacity. On the Crawled currently not indexed branch, Google fetched the page but did not index it, the Last Crawl field has a date, and diagnosis focuses on index selection, page value, duplication, rendering, and conflicting signals.

© Patrick Stox LLC · CC BY 4.0 ·

Why Google leaves pages in “Discovered”

Google frames crawling as a budget made of two halves, and Discovered is the canonical symptom of a problem on one side or the other.

Crawl capacity — your server

Google calculates a crawl capacity limit: the maximum number of simultaneous connections it’ll use on your site, tuned to how your server responds. From the crawl-budget guide: “Google’s crawlersA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. calculate a crawl capacity limit, which is the maximum number of simultaneous parallel connections that Google can use to crawl a site,” and “if the site slows down or responds with server errors, the limit goes down and Google crawls less.” Slow responses, timeouts, and 5xx errors all throttle the crawl — and when capacity is the bottleneck, URLs pile up in Discovered because there literally wasn’t room to fetch them.

Crawl demand — your site’s quality and structure

The other half is whether Google wants to crawl the URL. This is where most “Discovered” problems actually live. Google’s systems extrapolate crawl priority from URL patterns, internal linkingLinks between pages on the same site., and overall site quality. If a page is buried deep, orphaned, or looks like one more near-duplicate in a large low-value set, demand for it is weak and it stays in the queue.

Notably, Google’s large-site crawl-budget guide explicitly calls out this status: it says the guide applies to “Sites with a large portion of their total URLs classified by Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance. as Discovered - currently not indexed.” That’s Google itself tying Discovered to a crawl-budget (capacity + demand) constraint. Google also names the guide’s audience: sites with millions of URLs, sites that change rapidly and have roughly 10,000-plus pages, and sites with a large share of Discovered URLs — but it explicitly calls those numbers rough classification estimates, not exact thresholds. If your site is well under that scale, treat the guide as background, not a sign that a hard capacity ceiling applies to you.

It’s often a sitewide signal, not a per-page bug

This is a useful mental shift for most cases, though it’s a pattern I’ve observed rather than a frequency Google publishes. Discovered rarely means “page X has a flaw” in isolation. More often Google has extrapolated, from your URL patterns and sitewide quality, that a whole category of your pages isn’t worth crawling aggressively — but that’s a practitioner inference from URL-pattern and template behavior, not a fact the status itself proves for any single page. John Mueller has made the point repeatedly that there are two main drivers behind this status: server capacity (Google held back to avoid overloading the site) and overall website quality (the systems don’t think the pages are worth the crawl effort). He’s also noted the real-world causes are broader than the help doc’s “overload” line — accidentally auto-generating too many URLs, poor internal linking, and the need to strengthen the site overall so important pages get prioritized. (These are paraphrased from his office-hours commentary, relayed through industry coverage — I haven’t pinned them to a verbatim transcript.)

Scale plays a role too. Gary Illyes has been widely quoted, via industry coverage of his podcast remarks, as saying somewhere around 90% of sites don’t need to think about crawl budgetThe number of URLs an engine will crawl in a timeframe. at all — but I haven’t independently verified that figure against the original recording, so treat it as a widely relayed approximation, not a confirmed stat. The directional implication still holds: on a small or mid-size site, a true crawl-capacity ceiling is unlikely, and a persistent Discovered backlog is more often a demand problem — quality, internal linking, or crawl waste — than a server wall. Confirm that with your own Crawl Stats and logs rather than assuming it from site size alone.

How to diagnose which cause you have

Before you fix anything, work out whether you’re capacity-bound or demand-bound:

  • Capacity check. Look at GSC Crawl Stats (average response time, host status, response-code breakdown) and your server logs for slow responses and 5xx/timeout spikes. If Google is clearly being throttled by your server, that’s a capacity problem.
  • Demand check. Look at internal-link depth (how many clicks from the homepage), orphan pagesAn orphan page is a page on your site that no other page links to internally. Because crawlers discover pages by following links, an orphan page is effectively invisible to search engines unless it's in an XML sitemap or linked from an external site. (nothing links to them), and sitewide quality (thin, duplicated, or auto-generated URL patterns). If your Discovered URLs are deep, orphaned, or part of a near-duplicate set, that’s a demand problem.

Don’t pick a fix off a general frequency (“most sites are X”) — decide from the evidence in front of you: your own URL-pattern grouping, server logs, Crawl Stats, internal-link counts, sitemapA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing./inventory coverage, and how much each affected group actually matters to the business. For most small and mid-size sites the evidence tends to point to demand; for very large, ecommerce, or programmatic sites, it’s often both — but confirm it on your own data before committing to a fix.

TIP Keep current crawl evidence separate from Google's reported state

Join sitemap, fresh crawl, and Search Console exports to surface mismatches for review with my free Indexation Reconciler Free

  1. Load the sitemap inventory, a current crawl export, and the Search Console URL export for the same scope.
  2. Use mismatches to find stale exports, newly blocked URLs, and URLs absent from the intended inventory.
  3. Use Crawl Stats, server logs, internal-link evidence, and URL Inspection to decide whether the discovered backlog is capacity- or demand-driven.

How to fix it

The levers, roughly in order of impact for most sites:

Strengthen internal linking and fix orphan pages

Internal linking is the most controllable demand lever you have. Pages that nothing links to, or that sit many clicks deep, dominate the Discovered bucket. Link your important URLs from pages Google already crawls often — the homepage, hub pages, main navigation — and pull them shallower in the architecture.

Improve content quality; consolidate thin and duplicate pages

If Google is reading “low value” off your URL patterns, adding more pages won’t help. Mueller’s framing on cutting page count is the one to internalize: reducing the number of indexable pages without actually improving the site doesn’t make the site better — page-count surgery alone won’t fix a quality-driven Discovered problem. (Paraphrased from his office-hours answer; not verbatim.) Consolidate thin and near-duplicate pages, and make the pages you keep genuinely worth crawling.

Cut crawl waste

Faceted navigationFaceted navigation (faceted search, product filtering) lets visitors refine a list of products or content by attribute — price, color, size, brand, rating. The SEO problem: each filter combination can spawn a distinct crawlable URL, turning a small catalog into millions of near-duplicate pages that waste crawl budget and dilute ranking signals., URL parametersThe `?key=value` data tacked onto the end of a URL after a question mark — used for tracking, sessions, filtering, sorting, and search — and one of the biggest sources of duplicate URLs and wasted crawling in SEO., session IDs, soft 404sA soft 404 is a URL that returns a success status code (usually 200 OK) even though the page is empty, missing, or shows a 'not found' message. It isn't a status code a server sends — it's a label search engines apply after comparing the response code against the rendered content, and they treat the page like a 404 for indexing., and infinite spaces are the classic “Discovered factory” — they spend your crawl capacity on junk URLs so your real content never gets reached. This is where ecommerce and programmatic sites bleed the most. Trimming crawl waste frees capacity and sharpens the quality signal Google reads from your URL patterns. (See crawl budget and spider traps.)

Speed up and stabilize the server

On the capacity side, faster and more stable responses raise your crawl capacity limit — Google’s own line is that when a site slows down or returns errors, it crawls less. Fix 5xx errors, cut response times, and remove timeouts.

External links raise crawl demand for the pages they point at — but slowly. This is a real lever for genuinely important pages, not an instant switch. Don’t expect a backlink to flip a URL out of Discovered overnight.

When (and when not) to use “Request indexing”

Use it for a small number of genuinely important URLs you want crawled sooner. Do not treat it as a fix for thousands of Discovered URLs — it doesn’t scale, and Google explicitly says there’s no need to resubmit. For the sibling Crawled status, Google’s own guidance is that there’s no need to resubmit the URL for crawling; Discovered behaves the same way. Request indexing nudges the queue; it doesn’t change why a page was deprioritized.

When to do nothing

Some Discovered is normal triage — Google found a URL and just hasn’t prioritized it yet, and it may crawl it later on its own. If it’s a handful of genuinely low-value URLs, leaving them is fine. The time to act is when a large or important share of your URLs is stuck in Discovered, because that’s the signal of a fixable capacity-or-demand problem underneath.

When you measure “large or important share,” define the denominator first. The Page Indexing reportThe Google Search Console report (formerly Index Coverage) showing how many of your URLs are indexed vs. not indexed, and grouping the not-indexed ones by reason.’s example list for any status is capped at 1,000 URLs and isn’t guaranteed to show every affected URL — so don’t treat the exported examples as a complete list. Compare the report’s count against your own sitemap/URL inventory (not just the sampled examples) to get an honest share, and prioritize by business importance and traffic potential, not just row count.

Special cases: large, ecommerce, and programmatic sites

This is where Discovered stops being cosmetic. Sites with millions of URLs, faceted navigation, near-duplicate product pages, and infinite parameter spaces generate far more URLs than Google wants to crawl — so a large portion sits in Discovered by design. Here the playbook is crawl-waste reduction first (consolidate, block low value spaces from crawling where appropriate, fix parameter explosions), then internal-linking and quality work to raise demand for the URLs that matter, then server capacity. New sites with weak authority hit a milder version of the same thing: low demand, so weak pages wait.

Where this sits

Discovered is one status in the Page Indexing report, and it’s a crawl-stage problem — which is why the fixes lean on crawl budget, internal linking, and indexing fundamentals. Its sibling, Crawled – currently not indexed, is the quality-stage version of the same frustration. For the upstream stage — how Google discovers and fetches URLs in the first place — see crawling; for the downstream stage, see indexing.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.