Discovered – Currently Not Indexed: Why Google Delays the Crawl

"Discovered - currently not indexed" means Google knows the URL exists but has not fetched it yet, so it has not read a word of the page. For pages published in the past few weeks, this is usually a queue and clears without action. When pages you care about stay here for weeks, or the count keeps rising, something on your site is slowing discovery or crawling, and that can be fixed.

What Google says the status means

Google's Page Indexing report documentation (checked October 2026) explains the status in 3 parts: Google found the page but has not crawled it; typically Google wanted to crawl the URL but expected the crawl to overload the site, so it rescheduled; and that is why the report shows no last crawl date. The wording has not changed since at least December 2021, when the report was called the Index Coverage report; the status now sits under "Not indexed".

That definition has 2 consequences. Google has not read this page, so it has not judged this page's content yet, and rewriting the page is rarely the fix. The causes usually sit around the page: how Google found it, how many other URLs compete for the same crawl, how much your site seems worth crawling, and how your server responds.

flowchart TD
    A["Google learns the URL from a link or a sitemap"] --> B["URL waits in Google's crawl schedule"]
    B -->|"crawl postponed"| C["Discovered - currently not indexed"]
    C -->|"rescheduled"| B
    B -->|"crawled"| D["Google reads the page"]
    D -->|"not indexed for now"| E["Crawled - currently not indexed"]
    D -->|"indexed"| F["Page is indexed"]

"Crawled - currently not indexed" is the next stage: Google fetched the page and decided not to index it for now, which is a question about the page itself. We cover that decision in what "Crawled - currently not indexed" means and when to fix it.

Why Google has not crawled the URL yet

The causes run from benign to structural, and a site often has more than one.

1. The URL is new, or the site is. Google's crawl budget documentation (checked October 2026) says crawl demand varies with a site's size, update frequency, page quality and relevance compared with other sites. A new site, or one that rarely changes, tends to get less demand, so its new URLs wait longer.

2. Google knows the URL only from your sitemap. Google describes a sitemap as a hint, and its link documentation says every page you care about should have a link from at least one other page on your site. Google generally crawls a link only when it is an <a> element with an href attribute; a button that navigates with a script is not a dependable path. Typical cases: articles reachable only through a deep paginated archive, products reachable only through on-site search, and ad landing pages nothing links to. Our audit data on important pages with no internal links shows how often a page a site lists in its sitemap had no incoming links from the other pages we examined.

3. Too many low-value URLs compete for the crawl. Google's crawl budget documentation states that without guidance from you, Google tries to crawl all or most of the URLs it knows about on your site. Filter and sort combinations, internal search results, thin tag archives, calendar pages and tracking parameters can outnumber your real pages many times over. Google's faceted navigation documentation is direct about the cost: crawlers access a very large number of filter URLs before they can tell those URLs are useless, and time spent there is time not spent on new, useful URLs.

4. Your server signals strain. This is the reason Google's own description gives. Its crawl budget documentation says the crawl capacity limit goes down when a site answers with server errors (5xx) or rate-limiting signals such as HTTP 429, and when responses slow down. Patterns behind it: pages generated on every request with no caching, a firewall or CDN rule that answers crawlers with 429, and hosting that fails under load.

5. Your sitemap wastes the list you hand Google. A sitemap padded with URLs that redirect, return 404, carry noindex or are blocked by robots.txt sends mixed signals, and all but the blocked ones ask Google to spend requests on pages you do not want indexed. Google also says it uses <lastmod> only when it is consistently and verifiably accurate, and ignores <priority> and <changefreq>. In 29 external sites whose sitemap pages SEOReport fetched between May and October 2026, 8 (28%) listed at least one URL that redirects, is marked noindex or is blocked by robots.txt.

Is "Discovered - currently not indexed" a problem?

It depends on which URLs are in it and for how long. Google's own report guidance says a URL that is not indexed is not necessarily a bad thing.

How to confirm which cause applies

Work from the whole report to single URLs.

1. Split submitted from unsubmitted. In the Page indexing report, use the sitemap filter to compare "All submitted pages" with "Unsubmitted pages only". If most URLs in this status are unsubmitted, Google is finding URLs you never listed, which points to cause 3. If most are submitted, look at links, demand and the server.
2. Read the example URLs for patterns. Google limits the example list to 1,000 rows. Export them and group the rows by path and parameter; ?sort=, /tag/, /page/12/ and /search patterns show up quickly. The patterns exist only across hundreds of rows, which is why checking URLs one at a time, by hand or in a single AI chat session, tends to miss them.
3. Inspect a few important URLs. In URL Inspection, the "Discovery" section lists the submitted sitemaps that contain the URL and a "Referring page" Google may have used to find it. A sitemap with no referring page suggests Google has not found the URL through your links. "Test live URL" confirms whether Google's inspection crawler can fetch the page now; it does not tell you whether Google will index it.
4. Check the server side. The Crawl Stats report, under Settings, shows total crawl requests, average response time and host status. Google's crawl budget documentation also names "Hostload exceeded" in the URL Inspection tool as a sign that your server's capacity is the limit. Google says sites with fewer than 1,000 pages should not need Crawl Stats; there, the "Server error (5xx)" row of the Page indexing report is the quicker check.
5. View the source of the pages that should link to the URL. Confirm the link is a plain <a href> in the HTML, not a script-driven click.

flowchart TD
    A["Important URL is Discovered - currently not indexed"] --> B{"Published in the past few weeks?"}
    B -->|"yes"| C["Monitor and make sure it is linked"]
    B -->|"no"| D{"Mostly unsubmitted URLs in this status?"}
    D -->|"yes"| E["Reduce URL bloat: filters, parameters, archives"]
    D -->|"no"| F{"URL Inspection shows a referring page?"}
    F -->|"no, sitemap only"| G["Add crawlable internal links"]
    F -->|"yes"| H{"Slow responses, 5xx or 429 in Crawl Stats?"}
    H -->|"yes"| I["Fix server errors and capacity"]
    H -->|"no"| J["Clean the sitemap and link from strong pages"]

How to fix each cause

Weak links. Link the URL from pages Google already crawls often: the homepage, section hubs, the latest-articles list and closely related pages. Use ordinary anchors:

<!-- Google can follow this -->
<a href="/guides/pool-heat-pumps">Pool heat pump guide</a>

<!-- Google cannot reliably follow this -->
<span onclick="go('/guides/pool-heat-pumps')">Pool heat pump guide</span>

A noisy sitemap. List only canonical URLs that answer 200 and that you want in search results. Remove redirects, 404s, noindexed and blocked URLs, and set <lastmod> only when the page content really changed. Our XML sitemaps guide covers the structure, and the sitemap hygiene audit data shows the failures we see most.

URL bloat. Google's faceted navigation documentation recommends disallowing filter URLs in robots.txt, or moving filters into URL fragments (after #), which are not crawled separately. It calls canonical tags and nofollow on filter links less effective in the long term. Do not use noindex to save crawling: Google's crawl budget documentation notes that Google still requests a noindexed page before dropping it. For removed pages, return 404 or 410. A robots.txt pattern for filters looks like this:

User-agent: *
Disallow: /*?*sort=
Disallow: /*?*color=
Disallow: /search?

Test patterns before you deploy them; a rule that matches more than you meant hides real pages (Disallow: /search without the ? would also block /search-engine-basics). Once disallowed, known filter URLs can move from this status to "Blocked by robots.txt", which is the expected result. Our guide to robots.txt and crawl access explains how matching works.

Server strain. Fix the source of 5xx responses, cache pages that do not change per visitor, and make sure no firewall or CDN rule answers Google with 429. If Crawl Stats shows rising response times or "Hostload exceeded" appears, add server capacity.

How to verify the fix

On the issue details page in the Page indexing report, click "Validate fix". Google queues only the URLs with known instances of the issue, not the whole site, and its documentation says validation typically takes up to about 2 weeks and sometimes much longer. Meanwhile, URL Inspection shows progress per URL: a "Last crawl" date appears once Google has fetched it.

Most often the URL ends up indexed or moves to "Crawled - currently not indexed". The second is still progress: it changes the question from "can Google reach this?" to "does Google want this page?".

What a full diagnosis shows for this status

Search Console tells you which URLs are waiting. A full SEOReport diagnosis audits the site and checks the 2 ways your own site tells Google about your pages, your sitemap and your internal links, and names the pages that are hard to reach or that your sitemap advertises incorrectly: sitemap URLs that redirect, return an error, are noindexed or are blocked, and articles missing from the sitemap or not linked from crawlable pages. Each finding states how many pages it examined. Google's crawl schedule and your server's response times stay in Crawl Stats.

Common questions

Should I click "Request indexing" for every discovered URL?

No. Use it for a handful of priority URLs once the cause is fixed. Google applies a daily limit, and a request does not guarantee indexing. If hundreds of URLs are waiting, the cause is structural, and fixing links, the sitemap or URL bloat moves them all at once.

Does a small site really have a crawl capacity problem?

Usually not. Google writes its crawl budget guide mainly for sites with 1 million or more pages that change about weekly, or 10,000 or more that change daily, plus sites where a large share of URLs sit in this status. Among the 29 external sites SEOReport audited between May and October 2026 whose sitemap listed at least one URL, the median sitemap listed about 90 URLs. Google's own advice that sites under 1,000 pages should not need the Crawl Stats report points the same way: on a site that size, look at internal links and crawl demand before server capacity.

Why does this status list URLs I have never seen?

Google learns URLs from links anywhere it crawls, including other websites, old pages and parameters your own templates add. Select "Unsubmitted pages only" to isolate them, and inspect one: the "Referring page" often shows where it came from.