Why is the last crawl date blank for these URLs?

Because Google has not crawled them yet. Google's help says it found the URLs but rescheduled the crawl, which is why the report shows no last crawl date. Once a URL is crawled it moves to another status, such as indexed or Crawled – currently not indexed.

Can I ask Google to crawl my site faster?

Not directly. Google's Crawl stats documentation says you cannot tell Google to increase your crawl rate; Googlebot adjusts to how quickly and reliably your server responds. Faster responses and fewer server errors are the levers you control.

Will submitting a sitemap fix it?

Not on its own. A URL in this status is already known to Google, often from the sitemap itself, so discovery has worked. What moves it along is a responsive server, fewer low-value URLs competing for crawls, and links from pages Google already visits.

Should I use Request indexing on these URLs?

For a handful of important pages, it is reasonable: an owner or full user can request indexing from the URL Inspection tool, within a daily quota. For hundreds or thousands of URLs it does not scale, and fixing server speed, URL bloat and internal links is the real work.

Discovered – currently not indexed: causes and how to fix it

Google knows the URL but hasn't crawled it yet. Why 'Discovered – currently not indexed' happens, how it differs from Crawled, and what to fix first.

“Discovered – currently not indexed” in Google Search Console means Google knows a URL exists, usually from a link or a sitemap, but has not crawled it yet, so the report shows no last crawl date. Google’s help says that typically it wanted to crawl the URL but expected that to overload the site, so it rescheduled the crawl. The fixes are on the crawling side: a faster and more reliable server, fewer low-value URLs competing for Googlebot’s time, and stronger internal links to the pages that matter.

What does “Discovered – currently not indexed” mean?

Google finds new URLs in two main ways: by extracting links from pages it already knows, and from sitemaps you submit. Finding a URL is the first step. Fetching it is the second, and deciding whether to index it is the third.

A URL with this status has completed step one and is waiting on step two. Because nothing has been fetched, Google has not yet formed any view of the content. That makes this status quite different from its neighbour in the Page indexing report (Indexing → Pages), even though the names are almost identical.

How is it different from “Crawled – currently not indexed”?

	Discovered – currently not indexed	Crawled – currently not indexed
Has Google fetched the page?	No	Yes
Last crawl date	Blank	Shown
What is holding it back	Crawl scheduling: capacity and priority	A decision made after the crawl
Typical causes	Slow or failing server, too many URLs, weak internal links	Thin, duplicate or low-value content
Where to look first	Settings → Crawl stats, your URL inventory, internal links	The page itself, through URL Inspection

In short, Discovered is a crawling problem and Crawled is an indexing problem. If a URL moves from the first to the second, Google has now looked at it and declined, and the advice in Crawled – currently not indexed takes over.

Why does it happen?

Google’s crawl budget guide describes two forces, crawl capacity and crawl demand. They tend to show up in three ways.

The server cannot take more. Google sets a crawl capacity limit so that it can crawl your important content without overloading your server. The guide says the limit goes up when a site responds consistently and its response times hold steady or improve, and comes down when the site slows or returns server errors, including 5xx and HTTP 429 responses. A site on cheap shared hosting, behind an aggressive rate limiter, or with slow database queries on every page can keep Googlebot at a crawl.

There are too many URLs. Without guidance, the guide says, Google tries to crawl all or most of the URLs it knows about. If most of those are duplicates or pages nobody needs, crawl time goes on them instead of your new article. The usual sources are faceted navigation, sort and filter parameters, tracking parameters, session IDs, calendar pages that go on forever, and tag pages for every tag ever used.

There is not enough reason to crawl yet. Crawl demand depends partly on how popular your URLs are and how stale Google’s copy of them has become. A page linked from nowhere except the sitemap, or reachable after a dozen clicks through pagination, has little pulling it up the queue.

Is this a crawl budget problem?

Sometimes. Google’s crawl budget guide is written for large sites (a million or more unique pages, changing weekly), medium or larger sites (10,000 or more pages changing daily), and sites with a large portion of their URLs classified as “Discovered – currently not indexed”. For other sites, Google says, keeping the sitemap up to date and checking the Page indexing report is adequate.

So the size of the list matters. A small site with a dozen URLs in this status is usually looking at weak internal links, a slow server or simple patience. A large site with a big share of its catalogue stuck here probably has a genuine crawl budget problem, and the guide is worth reading end to end.

How to fix it

Check whether the listed URLs matter. Switch the report filter to “All submitted pages”. If the full list is mostly parameter URLs and filtered views, the fix is fewer of those URLs, not more crawling.
Check server health in Settings → Crawl stats (Google’s help for the report). Look at average response time, the host status checks (robots.txt fetching, DNS resolution, server connectivity) and the breakdown of responses. The report is available for root-level properties, meaning a Domain property or a root URL-prefix property.
Fix what slows Googlebot down: server errors, timeouts, and firewall or CDN rules that answer it with 429 or 403.
Shrink the URL inventory. Consolidate duplicates with canonical tags or 301 redirects, block crawling of endless parameter spaces in robots.txt, return 404 or 410 for pages that are gone, and fix soft 404s. Google’s guide lists each of these, along with avoiding long redirect chains.
Link to the pages that matter from pages Google already crawls: navigation, hub pages, related-content blocks. Fewer clicks from the home page is better.
Keep your sitemap current, with accurate lastmod dates for pages that changed. Submitting a sitemap covers the details.
For a few important pages, use Request indexing in the URL Inspection tool. It needs owner or full user access and has a daily quota, so it is for priorities, not bulk.

When to wait

A new site, or a batch of new pages published at once, often spends time here before crawling catches up; Google says crawling can take anywhere from a few days to a few weeks. After you fix server problems, give it time too. Google’s Crawl stats documentation says you cannot tell Google to increase your crawl rate, so the improvement shows up as Googlebot adjusting to a healthier server rather than overnight.

Where QueryWatch fits

QueryWatch is an independent app, not affiliated with Google. It does not show Crawl stats or the Page indexing report’s URL lists, neither of which is in the Search Console API, so that diagnosis happens in the web interface. What it does is keep track of the pages you are waiting on. The free tier includes 5 URL inspections a day, showing each page’s coverage state and last crawl date, and your sitemap list. On Pro you can mark pages as watched and get a push alert when one changes its index verdict or coverage state, so you hear when a page finally gets crawled and indexed instead of re-checking it every morning. Pro also alerts you when a sitemap’s error count rises. Search Console alerts has the details, and the Page indexing report explained covers every other reason in the same table.