How to Fix 'Discovered - Currently Not Crawled' in Google Search Console (2026)

"Discovered - Currently Not Crawled" means Google knows your URL exists — from a link or a sitemap — but Googlebot has never fetched it. No crawl has happened, so Google has evaluated nothing about your content. The URL is sitting in the crawl queue with its fetch postponed.

That makes this the opposite of a content problem. The causes live in crawl scheduling — server capacity, crawl demand, link signals, and URL inventory size — and so do the fixes. This guide covers where to find the status in Search Console, the five causes ranked by how often they are responsible, the concrete fix for each one, how long to wait before acting, and how the status differs from "Crawled - Currently Not Indexed."

TL;DR — Quick Summary

• "Discovered - Currently Not Crawled" means Google found your URL through links or sitemaps but Googlebot has not fetched it — zero crawls have happened
• Content quality is never the cause — Google cannot judge content it has not downloaded
• The five causes, ranked: anticipated server overload, low crawl demand, weak internal linking, URL inventory bloat, and a new domain without crawl trust
• The fixes: internal links from frequently crawled pages, sitemap hygiene with truthful lastmod, robots.txt blocks on parameter noise, faster hosting, and direct URL submission
• Established sites clear newly discovered URLs in days; new domains take 1-4 weeks — act when important URLs show no movement after four weeks
• For stubborn URLs, a direct URL submission service pushes them into Google's crawl systems within hours

---

What Does "Discovered - Currently Not Crawled" Mean?

"Discovered - Currently Not Crawled" is the Google Search Console state for URLs Google learned about through links, sitemaps, or redirects but has not yet crawled. Googlebot scheduled a fetch, then postponed it — most often to avoid overloading your server.

Google's documentation for the Page indexing report is explicit about the default mechanism: Google wanted to crawl the URL but expected the fetch to overload the site, so it rescheduled the crawl. The URL stays in Google's scheduling system and shows no last-crawl date until the first fetch happens.

Three facts follow from "no crawl has happened":

1. Your content plays no role. Googlebot has not downloaded the HTML, so word count, quality, structured data, and canonical tags cannot be the cause.
2. The URL is postponed, not rejected. Google keeps discovered URLs queued and retries on its own timetable.
3. The fixes are crawl-side. Server performance, internal links, sitemap accuracy, and URL inventory size decide when the first fetch happens.

Where Do You Find It in Google Search Console?

The status lives in the Pages report:

1. Open Google Search Console
2. Go to Indexing → Pages in the left sidebar
3. Scroll to the "Why pages aren't indexed" table
4. Click the "Discovered - currently not crawled" row
5. Export the URL list and note which directories and URL patterns dominate it

To confirm an individual URL, paste it into the search bar at the top of Search Console. The URL Inspection result shows the discovered state with no last crawl date — proof that Googlebot has never fetched the page.

---

Why Is Google Not Crawling Your URLs? The 5 Causes, Ranked

Google postpones a first crawl for one of five reasons: it expects the fetch to strain your server, crawl demand for the site or section is low, internal links are too weak to justify a visit, the discoverable URL inventory is too large, or the domain is too new to have earned crawl trust.

Every cause maps to one side of crawl budget — the number of URLs Googlebot can and wants to crawl on your site in a given timeframe. Cause 1 limits what Googlebot can fetch; causes 2 through 5 limit what it wants to fetch.

Cause 1: Google Expects the Crawl to Overload Your Server

Anticipated host load is the reason Google itself names first. Googlebot continuously measures how your server responds and lowers its fetch rate when responses slow down or fail — rising response times, timeouts, and 5xx errors shrink the crawl capacity limit, and queued URLs stay queued.

Diagnose it in Settings → Crawl stats in Search Console: a falling "Total crawl requests" line combined with a rising "Average response time" line means Googlebot is throttling itself on your host.

How to fix it:

1. Reduce server response time with full-page caching and a CDN in front of your origin
2. Eliminate 5xx errors and timeouts — pull the failing URLs from your host's error logs
3. Upgrade shared hosting when response times stay high under normal traffic
4. Keep the origin fast during traffic spikes — sustained slowdowns teach Googlebot to fetch less

Cause 2: Low Crawl Demand for the Site or Section

Low crawl demand means Google judges the site — or one section of it — not worth frequent fetching yet. Demand follows popularity (how many links point at the URLs), real freshness (how often known pages actually change), and the section's track record in search.

The telltale pattern: blog posts get crawled within days while a tag directory or forum archive sits discovered for months. Google is spending its fetches where they have historically paid off.

How to fix it:

1. Feature new URLs on the pages Google already crawls most — homepage, hub pages, top posts
2. Earn external links that point at the neglected section, not only at the homepage
3. Keep lastmod in your XML sitemap truthful — Google uses lastmod when it proves consistently accurate, and a sitemap that lies about freshness gets ignored
4. Publish and update on a steady cadence so fetching your site keeps paying off

Cause 3: Weak Internal Linking Leaves URLs Orphan-Adjacent

Googlebot prioritizes its queue partly by the strength of the paths leading to each URL. A URL referenced only in your sitemap — or only from page 14 of a paginated archive — carries the weakest possible discovery signal and sits at the back of the queue.

How to fix it:

1. Link every new URL from at least one page Googlebot fetches frequently — identify those pages in your server logs by Googlebot hit count
2. Keep important URLs within three clicks of the homepage
3. Add "latest" and "related" modules to high-crawl templates so new URLs inherit their crawl frequency
4. Never rely on sitemap-only discovery — a sitemap entry announces a URL; internal links argue for crawling it

Cause 4: Huge URL Inventories Dilute Crawl Budget

Faceted navigation, sort and filter parameters, calendar archives, and session IDs multiply one page into thousands of discoverable URLs. Googlebot spreads its fetch allocation across the whole inventory, and legitimate pages queue behind parameter noise. Google's guide to managing crawl budget for large sites prescribes exactly this cleanup: block crawling of URLs that should never be fetched and consolidate duplicates.

How to fix it:

1. Disallow facet and parameter patterns in robots.txt (for example Disallow: /*?sort=) — robots.txt is the only directive that prevents fetches, because noindex still requires a crawl to be seen
2. Remove internal links to parameter permutations and link the canonical version everywhere
3. Keep the sitemap canonical-only: no parameters, no redirect chains, no 404s
4. Consolidate near-duplicate facet pages into one canonical listing per intent

Cause 5: A New Domain Has Not Earned Crawl Trust

New sites start at the lowest crawl priority: no link signals, no serving history, no demonstrated demand. Discovered-but-uncrawled URLs on a week-old domain are normal, and the queue clears as trust accumulates.

How to fix it:

1. Submit your sitemap in Search Console on day one
2. Get the first external links from pages Google already crawls — real sites, not link farms
3. Use Request Indexing for the handful of pages that matter most
4. Work through the full checklist in our guide for a new website not showing in Google
5. Submit priority URLs through a direct submission service instead of waiting out the trust deficit

---

How Do You Force the First Crawl?

Two mechanisms ask Google to fetch a specific URL instead of waiting for the scheduler: the Request Indexing button in the URL Inspection tool, and direct URL submission through an indexing service.

URL Inspection. Paste the full URL into the Search Console search bar, wait for the inspection result, and click Request Indexing. The URL enters a priority crawl queue. It works one URL at a time with a small daily quota per property — practical for a few priority pages, impractical for hundreds.

Direct URL submission. An indexing service like IndexBolt submits URL lists directly into Google's crawl systems, which triggers first fetches within hours instead of weeks. It handles bulk lists and works for URLs you don't control — backlink pages on other hosts included.

After either route, verify the outcome: run your list through the free Google Index Checker to see which URLs made it into the index, and watch the Pages report. After its first fetch, a URL either gets indexed or moves to the post-crawl evaluation state.

---

How Long Should You Wait Before Acting?

Wait through one normal crawl cycle for your situation — days on an established site, up to four weeks on a new domain — and act when important URLs show no movement past that window.

Wait when:

• The URLs went live within the past two weeks on an established site
• The affected URLs are parameters, facets, or archives you never needed indexed
• The discovered count is small and flat month over month

Act when:

• Product, landing, or lead-generation URLs sit discovered past a normal cycle
• The discovered count grows every month — a widening crawl deficit
• Crawl Stats shows falling crawl volume alongside rising response times
• A new domain shows no crawling at all after four weeks despite a submitted sitemap

---

How Is It Different From "Crawled - Currently Not Indexed"?

The two states sit on opposite sides of the fetch: discovered URLs have never been crawled, while crawled-not-indexed URLs were fetched, rendered, evaluated — and left out of the index anyway.

A URL leaves the discovered state the moment Googlebot fetches it — and then faces the indexing decision. Fixing crawl access gets you to that decision; it does not pre-win it. If your URLs graduate to the post-crawl state, switch playbooks: our guide to fixing "Crawled - Currently Not Indexed" covers the content-side causes and fixes.

---

Frequently Asked Questions

How long does "Discovered - Currently Not Crawled" take to resolve?

Established sites usually clear newly discovered URLs within days; new domains take one to four weeks, sometimes longer. Treat four weeks with no movement as the signal to intervene — strengthen internal links, clean the sitemap, or submit the URLs directly for crawling.

Does "Discovered - Currently Not Crawled" mean my content is low quality?

No. Googlebot has never downloaded the page, so Google holds no information about its content. Quality judgments start only after the first crawl. This status reflects crawl scheduling — server capacity, crawl demand, and link signals — nothing else.

Should I resubmit my sitemap to fix it?

No. Google re-reads submitted sitemaps on its own schedule, and resubmitting an unchanged file adds zero new information. What moves crawls is accuracy: a sitemap whose lastmod values change when — and only when — the pages actually change, with every listed URL canonical and live.

Can I use Request Indexing for every discovered URL?

No. URL Inspection processes one URL at a time and enforces a small daily quota per property. Reserve it for a handful of priority pages; for the rest, fix the crawl signals above or use bulk direct submission, which has no per-day URL ceiling on your side.

---

Next Steps

1. Export the discovered URL list from Indexing → Pages in Search Console
2. Separate URLs you need indexed from parameter and facet noise
3. Block the noise in robots.txt and keep the sitemap canonical-only
4. Link every needed URL from a page Googlebot crawls frequently
5. Check Crawl Stats for server-side throttling and fix response times first
6. Request crawling for priority URLs via URL Inspection
7. Submit stubborn URLs through IndexBolt for a first crawl within hours
8. Monitor the Pages report until the discovered count trends down