Discovered - currently not indexed: why Google has not crawled your page

Last updated: 2026-10-30

In short

Discovered - currently not indexed means Google found the URL, through a link or a sitemap, but has not crawled it yet. Google says it typically postponed the crawl because crawling was expected to overload the site. Fix it by cutting low-value URLs, improving server response and linking to the pages that matter.

Exact label in Search Console: Discovered - currently not indexed

What it means

Google's Page indexing help says the page was found by Google but not crawled yet. Typically Google wanted to crawl the URL but expected this to overload the site, so it rescheduled the crawl. That is why the last crawl date is empty for these URLs in the report and in URL Inspection.

Because the page has not been fetched, its content has not been judged yet. The questions are about crawling: how many URLs Google thinks your site has, how fast and reliably your server responds, and how much Google wants to crawl these particular pages. Google's crawl budget guide names sites with a large share of their URLs in this status as one of its target audiences, next to very large and fast-changing sites. For the sitemap side of the problem, see Sitemap submitted but pages not indexed.

Is it a problem?

A few new URLs here for a short time is normal: Google says most sites should expect several days at minimum before new pages are noticed. It becomes a problem when important pages stay here for weeks, or when a large share of your known URLs sits in this status. Then the site is usually exposing too many URLs Google does not consider worth crawling, or the server cannot keep up.

Common causes

Too many low-value URLs

Faceted navigation, sort and filter parameters, session IDs, calendars and other infinite spaces can generate far more URLs than real pages. Google's crawl budget guide calls this perceived inventory the factor you can control the most.

Slow or unstable server

Google's crawl capacity limit goes down when response times rise or the server returns 5xx or 429 errors. The Crawl Stats report shows host status and response times.

Weak crawl demand for the pages

Google says crawl demand depends on factors such as popularity, staleness, page quality and relevance. Pages with few internal links and no external links tend to wait longer.

Sitemaps full of URLs you do not want indexed

Google advises against listing URLs you do not want in Search, because this can waste crawl budget on pages you do not want indexed.

Long redirect chains and soft 404s

Google notes that long redirect chains hurt crawling and that soft 404 pages keep getting crawled, which wastes budget that real pages could use.

How to fix it

  1. Check whether the URLs should exist at all. Group the example URLs by pattern. If most are parameters or duplicates, stop generating or linking them, consolidate duplicates with canonicals, or block pure crawl traps such as endless filter combinations in robots.txt.
  2. Review host status in Crawl Stats. Open Settings, then Crawl stats in Search Console. If host status shows problems with robots.txt fetching, DNS resolution or server connectivity, or average response time keeps climbing, fix capacity and speed with your host first.
  3. Link to important pages from crawled pages. Add standard anchor links with an href from relevant, regularly crawled pages such as category hubs or your homepage. Google can only discover links that are real a elements with an href attribute.
  4. Keep sitemaps clean and current. List only canonical, indexable URLs that return 200, with accurate lastmod values. Do not resubmit an unchanged sitemap several times a day; Google lists that among the things to avoid.
  5. Return 404 or 410 for removed pages. Google's crawl budget guide says a 404 is a strong signal not to crawl a URL again, while blocked URLs stay in the crawl queue much longer. Do not use noindex to save crawl budget, because Google still has to fetch the page to see it.

Check it with GSC Magic

Run report_index_health on your sitemap to see how many listed URLs are Discovered - currently not indexed versus indexed, then gsc_inspect_urls_batch on a sample from each directory to see which sections are stuck. gsc_list_sitemaps and gsc_get_sitemap show whether your sitemaps were processed and with which errors or warnings. GSC Magic does not crawl your site or read server logs, so pair these results with your host logs and the Crawl Stats report in Search Console.

Prompts to copy

Run an index health check on my sitemap and tell me what share of URLs are Discovered - currently not indexed. Break it down by top-level directory.

List my submitted sitemaps with their status, errors, warnings and last download date, and tell me which ones look stale or broken.

Inspect these 200 product URLs and separate the ones that have never been crawled from the ones that were crawled but not indexed.

Guides on the blog

Frequently asked questions

Does crawl budget matter for a small site?

Usually not as the main cause. Google's crawl budget guide is aimed at sites with about 1 million or more pages, sites with 10,000 or more pages that change daily, and sites with a large share of URLs in Discovered - currently not indexed. Google calls those numbers rough estimates, not thresholds.

Will submitting a sitemap fix it?

A sitemap helps Google discover URLs, but Google says it does not guarantee crawling or indexing. URLs in this status are already discovered; what is missing is the crawl. Focus on URL inventory, server health and internal links.

Why is the last crawl date empty?

Because Google has not fetched the page yet. Google's help says this is exactly why the last crawl date is empty for Discovered URLs.

Should I use Request indexing on every URL?

No. Google says there is a quota for individual URL requests and that repeated requests for the same URL do not speed up crawling. Use it for a handful of key pages and rely on sitemaps and internal links for the rest.

Sources