Discovered – Currently Not Indexed

TL;DR — “Discovered – currently not indexed” in Google Search Console means Google has found your page but hasn’t downloaded (crawled) it yet — so it can’t be in search. The Last Crawl date is empty. It usually means Google didn’t think the page was worth crawling right now, or crawling it would have strained your server. The fix is to make your important pages easier to reach and clearly worth crawling — not to keep clicking “Request indexing.”

What this status means

Open Google Search Console, go to the Page Indexing report, and you’ll see your pages grouped by status. “Discovered – currently not indexed” is the bucket for URLs that Google knows about but hasn’t actually crawled yet. 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: 2026-07-14 Google: Page indexing report

Remember the three steps every page goes through to show up in search:

1. Crawl — Google downloads the page.
2. Index — Google files it away in its database.
3. Serve (rank) — Google shows it when someone searches.

A “Discovered” page is stuck before step one. Google found the URL — usually from your sitemap or a link — added it to its to-do list, and then didn’t get around to fetching it. The clearest sign is in the URL Inspection tool: the Last Crawl date is empty, because nothing was ever crawled.

Why Google leaves a page “Discovered”

Two reasons, in plain terms:

• It didn’t want to overload your site. Google holds back if crawling more pages right now might slow your server down. It reschedules the crawl for later.
• It didn’t think the page was worth it. If your site (or that section of it) looks thin, duplicated, or hard to reach, Google deprioritizes crawling those URLs. This is a plausible diagnosis, not something the report status proves by itself.

How it’s different from “Crawled – currently not indexed”

These two statuses look almost identical and people mix them up constantly. The difference is one word — crawled:

• Discovered – Google hasn’t fetched the page yet. Empty Last Crawl date.
• Crawled – currently not indexed – Google did fetch it but decided not to keep it. There’s a Last Crawl date.

So Discovered is a “we haven’t gotten to it” problem; Crawled is a “we looked and passed” problem. Different stages, different fixes.

What actually helps

• Link to the page from pages that already get crawled — your homepage, main navigation, or popular articles. Orphan pages (nothing links to them) are one possible cause.
• Make the page genuinely useful and not a near-duplicate of others.
• Submit it in your XML sitemap (this helps Google find it, though not necessarily prioritize it).
• Keep your server fast and stable.

The thing most people get wrong

Clicking “Request indexing” over and over is not the fix. It can nudge a few important URLs, but it doesn’t scale to hundreds or thousands of pages, and it does nothing about why Google deprioritized them. If a whole section is sitting in “Discovered,” that’s a signal about your site’s quality, structure, or server — not something a button solves. 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: 2026-07-14 Google: Ask Google to recrawl URLs

Want the full diagnosis — how to tell whether it’s a server problem or a quality problem, and the fixes that actually scale? Switch to the Advanced tab.

TL;DR — “Discovered – currently not indexed” means Google found 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 indexed” (fetched, then not kept). Google’s two drivers are crawl capacity (crawling now would overload the server, so it rescheduled) and crawl demand (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 crawling a page still doesn’t guarantee it gets indexed.

What Google actually says it means

Straight from the Page Indexing report 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: 2026-07-14 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 GSC, 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 sitemap, 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 indexed = 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 indexing evaluation that can have several causes (duplication, thin content, canonicalization 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: 2026-07-14 Google: Ask Google to recrawl URLs

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 crawlers 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 linking, 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 Console 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 budget 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 pages (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, sitemap/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.

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 navigation, URL parameters, session IDs, soft 404s, 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.

Earn links to priority pages

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 report’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.

AI summary

A condensed take on the Advanced version:

• What it is: a GSC Page Indexing status meaning Google found the URL but hasn’t crawled it — the Last Crawl date is empty. It’s a pre-crawl queue state, not a penalty.
• vs Crawled – currently not indexed: Discovered = not yet fetched (a crawl-priority/capacity signal); Crawled = fetched, and Google is still evaluating it for indexing (several possible causes, not one “quality verdict”). Getting out of Discovered still doesn’t guarantee indexing.
• Two root causes (Google): crawl capacity — crawling now would overload the server, so Google rescheduled — and crawl demand — your site/pages aren’t worth the crawl effort (quality + internal linking). Google’s crawl-budget guide targets very large or fast-changing sites; it labels its size thresholds as rough estimates, not exact cutoffs.
• It’s often sitewide, not per-page: Google extrapolates crawl priority from URL patterns and overall site quality — a practitioner inference from pattern behavior, not something the status proves for a single URL.
• Diagnose: Crawl Stats + logs for the capacity side; internal-link depth, orphans, and sitewide quality for the demand side. Small/mid-size sites lean demand-bound more often than not — Illyes has been widely quoted (unverified against the original recording) putting it around 90% of sites not needing to worry about crawl budget — but confirm on your own data rather than assuming from site size.
• Fix: strengthen internal linking and fix orphans; improve quality and consolidate thin/duplicate pages; cut crawl waste (facets, parameters, soft 404s, infinite spaces); speed up the server; earn links to priority pages.
• Request indexing nudges a few URLs but doesn’t scale and doesn’t fix the cause — Google says no need to resubmit. Cutting page count without improving quality doesn’t help either.
• Measuring the backlog: the Page Indexing report’s example rows cap at 1,000 per status and aren’t guaranteed complete — measure share against your own URL inventory, not just the sampled export.

Official documentation

Primary-source documentation from the search engines.

Google

• Page Indexing report — the definitions of “Discovered – currently not indexed” and “Crawled – currently not indexed,” and every other status in the report.
• Optimize your crawl budget — crawl capacity + crawl demand; the guide explicitly names sites with a large share of “Discovered – currently not indexed” URLs.
• In-Depth Guide to How Google Search Works — crawl → index → serve, URL discovery, and why not all pages make it through each stage.
• Crawling and Indexing — the hub for robots, sitemaps, and crawl controls behind crawl-waste fixes.

Bing / Microsoft

• Bing Webmaster Tools — help — Bing doesn’t use the exact “Discovered – currently not indexed” label; it reports indexing via URL Inspection / Site Explorer and governs crawling through crawl quota and content value. Confirm current Bing terminology before citing it.

Quotes from the source

On-the-record statements from Google. Each link is a deep link that jumps to the quoted passage on the source page.

Google — the definition (Page Indexing report)

• “Discovered - currently not indexed: 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.” — Google Search Console Help, Page Indexing report. Jump to quote

Google — the sibling status, for contrast

• “Crawled - currently not indexed: The page was crawled by Google but not indexed. It may or may not be indexed in the future; no need to resubmit this URL for crawling.” — Google Search Console Help, Page Indexing report. Jump to quote

Google — crawl capacity (why the server side throttles)

• “Google’s crawlers calculate a crawl capacity limit, which is the maximum number of simultaneous parallel connections that Google can use to crawl a site.” — Google Search Central, Optimize your crawl budget. Jump to quote
• The same guide applies to “Sites with a large portion of their total URLs classified by Search Console as Discovered - currently not indexed.” Jump to quote

”Discovered – currently not indexed” triage checklist

Work top to bottom — confirm what kind of problem you have before you start fixing:

• Confirm the status in GSC URL Inspection — is the Last Crawl date empty? (Empty = genuinely Discovered, not Crawled.)
• Capacity check: review Crawl Stats (average response time, host status) and server logs for slow responses, timeouts, and 5xx spikes.
• Demand check: are the affected URLs orphaned or buried deep in the architecture? Map their internal-link depth.
• Quality check: are they thin, near-duplicate, or auto-generated URL patterns rather than genuinely distinct pages?
• Crawl-waste check: is faceted nav, parameters, session IDs, soft 404s, or an infinite space inflating your URL count?
• Internal links: important Discovered pages are linked from pages Google already crawls (homepage, hubs, nav) and aren’t many clicks deep.
• Sitemap: affected URLs are in your XML sitemap (helps discovery — not a priority lever).
• Server health: fast, stable responses; 5xx/timeouts minimized.
• Decide scope: a handful of low-value URLs → fine to leave. A large or important share stuck → fix the demand/capacity cause.
• Request indexing only for a few genuinely important URLs — not as a bulk fix.

The mental models

1. Discovered = found, not fetched. The empty Last Crawl date is the whole diagnosis. If something was fetched, it isn’t Discovered — it’s Crawled. Get this right first; everything downstream depends on it.

2. Capacity vs demand. There are only two reasons a URL sits in Discovered: Google couldn’t crawl it (server capacity) or Google didn’t want to crawl it (demand — quality, linking, priority). Diagnose which one you have before you touch anything. Crawl Stats and logs tell you capacity; link depth, orphans, and sitewide quality tell you demand.

3. It’s often a sitewide signal, not a per-page bug. Google extrapolates crawl priority from URL patterns and overall quality — that’s a practitioner inference from pattern behavior, not a fact the status proves for one URL. Discovered is more often a signal about a category of your pages than a flaw in one page. Fix the pattern, not just the page — but confirm the pattern with your own data first.

4. Crawling is a gate, not a guarantee. Getting a page out of Discovered only earns it a fetch. It can still land in Crawled – currently not indexed and never get indexed. Plan for the quality stage, not just the crawl stage.

5. Small and mid-size sites are more often demand-bound. True crawl-capacity ceilings mostly bite very large sites. If you’re small or mid-size and seeing Discovered, demand — internal linking and quality — is the more likely first check, not a server wall. Confirm with Crawl Stats and logs rather than assuming it from site size alone.

6. Request indexing nudges; it doesn’t cure. It moves a few URLs up the queue. It changes nothing about why they were deprioritized, and it doesn’t scale. Use the structural levers for the real fix.

Discovered vs Crawled — and the fix-it map

Discovered vs Crawled – currently not indexed

Capacity vs demand — which problem is it?

Fast facts

• Discovered means empty Last Crawl date — the one fact that distinguishes it.
• Google’s two drivers: crawl capacity + crawl demand.
• Gary Illyes has been widely quoted (industry coverage, not independently verified) as saying roughly 90% of sites don’t need to worry about crawl budget — a directional signal, not a confirmed stat. On small/mid-size sites, persistent Discovered is more often a quality/linking problem than a capacity ceiling.
• Request indexing doesn’t scale and doesn’t fix the cause; no need to resubmit.
• Getting crawled does not guarantee indexing.
• The Page Indexing report’s example rows cap at 1,000 per status and aren’t guaranteed complete — measure share against your own URL inventory, not the sample.

Why hasn’t Google crawled these URLs?

Tools for separating capacity from demand

• Log File Analyzer — check whether Googlebot requests are falling, which URL patterns consume requests, and whether errors are present.
• Robots.txt Tester — rule out an access block before treating a missing crawl as a scheduling decision.
• Sitemap Validator — verify that priority canonical URLs are present and the sitemap is fetchable and structurally sound.
• Link Analyzer — inspect whether the affected page has a crawlable internal path instead of existing only in a sitemap.

Validation tests

Test: internal-link and sitemap fix produces a crawl

Test to run — publish the internal link and sitemap correction, then check the URL’s server-log history and URL Inspection status. Expected result — Googlebot requests the canonical URL and the Last crawl field is no longer empty. Failure interpretation — the URL still has weak discovery/priority signals, a conflicting variant, or is part of a broader crawl-demand problem. Monitoring window — use the site’s normal crawl cadence; compare against similar priority pages rather than assuming an instant visit. Rollback trigger — remove the new link only if it creates an unintended navigation or duplicate-URL path; otherwise diagnose the remaining signals instead of undoing discovery.

Test: server-capacity repair restores crawling

Test to run — deploy the server fix and compare Googlebot request volume, response time, and error responses in server logs. Expected result — successful crawler requests recover without the prior error or latency pattern. Failure interpretation — the capacity constraint remains, or crawl demand rather than capacity is the limiting factor. Monitoring window — compare multiple crawl cycles and the same weekday/time pattern used for the pre-fix baseline. Rollback trigger — revert if the deployment increases crawler-facing errors or response latency.

How to measure the problem

Discovered-not-indexed population

Metric — count and share of submitted canonical URLs in this status, measured against your own sitemap/URL inventory as the denominator — not just the report’s sampled example rows. What it tells you — whether the backlog is growing faster than Google crawls it. How to pull it — export the Page Indexing report and segment by sitemap or template. The report’s example list caps at 1,000 URLs per status and isn’t guaranteed to be exhaustive, so treat exported examples as a sample, not a census. Benchmark / realistic range — establish a baseline by template; the useful target is a shrinking backlog for priority inventory, not a universal percentage. Cadence — weekly during remediation, then monthly.

Time from discovery to first crawl

Metric — elapsed time between publication/sitemap inclusion and the first Googlebot request. What it tells you — whether priority and capacity changes improve scheduling. How to pull it — join publishing or sitemap timestamps to server-log first-seen requests. Benchmark / realistic range — compare like-for-like page types on your own site; crawl cadence varies too much for a universal threshold. Cadence — review monthly or after a material template/server change.

Crawler success and waste

Metric — successful Googlebot requests to important URLs versus errors and low-value URL patterns. What it tells you — whether crawl capacity is being spent on the inventory you care about. How to pull it — segment server logs by status code and URL pattern. Benchmark / realistic range — use the pre-change mix as the baseline and require improvement in the priority share without increasing errors. Cadence — weekly while diagnosing; monthly once stable.

Prompts for backlog analysis

Find template-level causes

Group this export of “Discovered – currently not indexed” URLs by template and URL pattern. For each group, compare sitemap presence, internal-link count, publication date, and server-log first-seen data. Rank capacity, crawl-waste, and crawl-demand hypotheses by evidence. Do not claim a cause when the required evidence is absent.

Prioritize a remediation sample

Select a representative test set from these affected URLs: high-priority pages, low-priority pages, recent pages, old pages, and each major template. Propose one change per hypothesis and state the observable pass signal and rollback trigger. Data: [paste rows].

Test yourself

Resources worth your time

My related writing

• How to Fix “Discovered - currently not indexed” — the Ahrefs guide I review: the five diagnostic areas (crawl budget, content quality, internal linking, backlinks, technical problems) and the fixes for each.
• The Beginner’s Guide to Technical SEO — where crawling and indexing fit in the bigger picture.

Official

• Page Indexing report (Google) — the source for both status definitions.
• Optimize your crawl budget (Google) — crawl capacity + demand, and the doc that explicitly names this status.

From others

• Google On Fixing “Discovered Currently Not Indexed” (Search Engine Journal) — coverage of Mueller’s capacity-vs-quality framing.
• Understanding and resolving “Discovered - currently not indexed” (Search Engine Land) — Dan Taylor’s diagnostic walkthrough.
• How To Fix “Discovered – Currently Not Indexed” (Onely) — technical deep-dive on diagnosing crawl-capacity vs. quality causes, with server-log analysis.
• Google On Discovered – Currently Not Indexed (Search Engine Roundtable) — Barry Schwartz covering Google rep commentary on this status.
• r/TechSEO — the community for crawl/index debugging.

Discovered – currently not indexed

A 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.

Related: Crawled – currently not indexed, Crawl Budget, Indexing

Discovered – currently not indexed

“Discovered – currently not indexed” is a status in Google Search Console’s Page Indexing report. It means Google has found the URL — usually from a sitemap or an internal or external link — but hasn’t crawled it yet. The giveaway is that the Last Crawl date is empty: nothing has been fetched.

Google’s own explanation is that it wanted to crawl the URL, but doing so was expected to overload the site, so it rescheduled the crawl. It can also signal weak crawl demand — Google’s systems not prioritizing the page, which practitioners commonly trace back to overall site quality and internal linking, though that’s an inference from URL-pattern behavior rather than something the status proves on its own.

The one fact that separates it from its sibling status, “Crawled – currently not indexed,” is the crawl itself: Discovered means not yet fetched (empty Last Crawl date), while Crawled means Google fetched the page and is evaluating it for indexing (several possible causes, not a single quality verdict). One is a crawl-priority problem; the other is an indexing-evaluation problem.

On small and mid-size sites, persistent Discovered is more often a demand issue than a true crawl-capacity ceiling — it tends to point at quality, internal linking, or crawl waste, though confirm that against your own Crawl Stats and logs rather than assuming it. “Request indexing” can nudge a handful of priority URLs but doesn’t scale to thousands and doesn’t fix the underlying cause.

Related: Crawled – currently not indexed, Crawl Budget, Indexing

Changelog