Discovered - Currently Not Indexed: What It Means and How to Fix It

Discovered - currently not indexed means Google knows the URL exists, from a link or a sitemap, but hasn't crawled it yet. Google's Page indexing report help says the crawl was typically rescheduled because fetching the URL then was expected to overload the site, which is why the last crawl date is empty in the report. It isn't an error on the page and it isn't a penalty. It's a scheduling decision, and fixing it means changing what that decision depends on: how much crawling your server can take, and how much Google wants to crawl your URLs.

It's one of the reasons listed in Google Search Console's page indexing report, and it's often confused with its neighbor, Crawled - currently not indexed. The two have different causes and different fixes.

What Discovered - currently not indexed means

Google finds URLs in three ways: pages it already visited, links extracted from known pages, and lists of URLs you submit, such as sitemaps (How Google Search works). Finding a URL is discovery, fetching it is crawling, storing it is indexing, and ranking comes after. This status sits between discovery and crawling: the URL is on Google's list, and Googlebot hasn't requested it.

Google hasn't fetched the page, so the decision can't rest on that page's content. It rests on what Google knows about the site and the URL: according to the same page, Googlebot uses an algorithmic process to decide which sites to crawl, how often and how many pages to fetch from each, and it tries not to crawl a site so fast that it overloads it.

Why Google hasn't crawled the page yet

Google's guide to managing crawl budget describes two limits: the crawl capacity limit (how much crawling your server can handle) and crawl demand (how much Google wants to crawl). The guide targets large sites (over a million pages that change weekly, or over 10,000 that change daily) and sites with a large share of URLs in Discovered - currently not indexed. Crawl budget covers the topic in full; here is how each limit produces this status.

The server can't take more crawling

When a site slows down or returns server errors, Google lowers the capacity limit and crawls less. A 429 response is read as rate limiting and has the same effect. Common culprits are slow server-rendered pages, timeouts, and bot protection or a firewall rule that answers Googlebot with 429 or a challenge page. In URL Inspection, a page fetch result of Hostload exceeded means, in Google's words, “Your site seems to be at maximum capacity for Google crawling or inspection requests.” Server error (5xx) covers the errors themselves.

Google doesn't see enough demand

Crawl demand depends on a site's size, update frequency, page quality and relevance, and URLs that are more popular on the web are crawled more often. Asked in a 2023 office-hours session whether cutting 8 million product pages to 2 million would fix this status, John Mueller pointed to server capacity on large sites, then added, “In most cases though, it's more about overall website quality.”

Low-value URLs compete with the ones you care about

The crawl budget guide says that, without guidance, Google tries to crawl all or most of the URLs it knows about on your site. In What crawl budget means for Googlebot, Gary Illyes listed the low-value URLs that drain crawling from valuable pages: faceted navigation and session identifiers, on-site duplicates, soft error pages, hacked pages, infinite spaces and proxies, and low quality or spam content. Google's faceted navigation guide adds that crawling spent on useless URLs leaves less time for new, useful ones.

Few or no internal links point to the page

A URL that appears only in a sitemap, or sits behind twenty pages of pagination, gives Googlebot few paths to it and little sign that it matters. Google's guidance on crawlable links is that every page you care about should have a link from at least one other page on your site, and that it can generally only crawl links that are <a> elements with an href. More in internal linking for SEO.

The site or the page is new

Even when you ask for a recrawl, Google says crawling can take anywhere from a few days to a few weeks (Ask Google to recrawl your URLs). A few fresh pages in this state on a new site is the normal queue.

How to diagnose the cause

1. See which URLs are affected. In the Page indexing report, switch the filter above the chart between All submitted pages (URLs from your sitemaps) and Unsubmitted pages only (URLs Google found elsewhere), and compare the count for this reason. If most are filters, parameters or old paths, the problem is your URL inventory, not your content. The examples table stops at 1,000 rows and may not list every affected URL.
2. Inspect a few URLs. In URL Inspection, no Last crawl date confirms the status, Referring page shows a page Google possibly used to find the URL, and Sitemaps lists the sitemaps that point to it. Then click Test live URL: it fetches the page in real time and tells you whether Google can get it from your server at all.
3. Read the Crawl Stats report (Settings, then Crawl stats). Host status covers robots.txt fetching, DNS resolution and server connectivity. Check the average response time, the share of server errors by response, and the split by purpose: Discovery is a URL Google never crawled before, Refresh a recrawl. Google says a site with fewer than a thousand pages shouldn't need this report (Crawl Stats report help). More in the crawl stats report.
4. Check your server logs. They show what Googlebot actually received, which a firewall or CDN dashboard may not.

# Googlebot requests that got a 429 or a 5xx (combined log format)
grep "Googlebot" access.log | awk '$9 == 429 || $9 >= 500' | wc -l

# Has Googlebot ever requested this URL?
grep "Googlebot" access.log | grep -c "GET /blog/my-post"

# Is that IP really Googlebot? Reverse lookup, then forward lookup on the name it returns
host 66.249.66.1
host crawl-66-249-66-1.googlebot.com

Anyone can send a Googlebot user agent. Google's verification steps are a reverse DNS lookup that must end in googlebot.com, google.com or googleusercontent.com, then a forward lookup on that name that must return the original IP.

How to fix Discovered - currently not indexed

Work in this order: capacity, then inventory, then links and quality. Indexing requests come last.

1. Give Googlebot a fast, stable server

Cut response times, stop rate-limiting or challenging verified Googlebot, and fix the errors the logs show. The crawl budget guide adds two levers: support 304 responses, which tell Google to reuse its cached copy of a page that hasn't changed, and add server resources if you need more capacity. Once errors drop, Google raises the crawl rate again on its own (Reduce the Googlebot crawl rate). A quick check of a page's status code and time to first byte:

curl -s -o /dev/null -w "%{http_code} %{time_starttransfer}s\n" https://example.com/blog/my-post

2. Shrink the URL inventory

The crawl budget guide's list: block crawling of duplicate sorted and filtered versions of a page in robots.txt, consolidate duplicates, return 404 or 410 for pages that are gone for good, fix soft 404s and avoid long redirect chains. Rules for filter parameters, in the pattern Google's faceted navigation guide uses:

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

Don't use noindex to save crawling: the same guide says Google will still request the page, then drop it.

3. Link the pages from pages Google already crawls

Add plain <a href> links from the homepage, category or hub pages and related articles. Links that only exist as click handlers or router attributes may not be followed.

4. Keep the sitemap to URLs you want indexed

List canonical URLs that return 200, as absolute URLs, with a <lastmod> that is accurate: Google uses it only if it's consistently and verifiably right, and it ignores <priority> and <changefreq>. Google calls submitting a sitemap a hint, not a guarantee (Build and submit a sitemap).

5. Make the pages worth crawling

Merge thin or near-duplicate pages into stronger ones and improve what remains. Deleting pages to lower the count isn't a fix in itself: in the same answer, Mueller said it's easy to spend time reducing indexable pages without making the site better, which wouldn't help in search.

6. Request indexing for the few that matter

For a handful of important URLs, click Request indexing in URL Inspection. Google's URL Inspection tool help says there is a daily limit, that you can't request a page the live test considers non-indexable, and that submitting a request doesn't guarantee indexing. Its recrawl guide adds that requesting the same URL again won't get it crawled any faster. Request indexing covers the limit.

What won't help

• The Indexing API. Google documents it only for pages with JobPosting or a BroadcastEvent embedded in a VideoObject. Using it for other pages is outside Google's documented use, submissions go through spam detection, and abuse can get access revoked (Indexing API quickstart). See the Google Indexing API.
• IndexNow. Google isn't among the participating engines listed on indexnow.org, so a notification doesn't reach it.

How long Discovered - currently not indexed lasts

Google publishes no timeline for this status. For a crawl you ask for, it says a few days to a few weeks. For URLs it doesn't prioritize, it can be much longer: in a February 2022 office-hours session, Mueller was asked how long the status can last and answered, “That can be forever.” The Page indexing report help is direct about it: “Don't expect every URL on your site to be indexed.”

If a page is still here after a few weeks, with internal links and clean server responses, treat it as a demand problem: quality and inventory. To follow one URL, inspect it rather than waiting on the report's totals.

How IndexCyborg tracks discovered pages

IndexCyborg inspects every URL in your sitemaps with the URL Inspection API, new pages straight away, within Google's 2,000 inspections per property per day. It stores Google's coverage state word for word, with the last crawl time, files the page under Discovered, not indexed so you can filter for it, and re-checks it after 7 days. The MCP tool get_unindexed_pages gives a coding agent these pages along with every other inspected page Google reports as not indexed. Technical checks on your sitemap URLs raise an issue, with the evidence, when a page returns an error, redirects, carries a noindex, is blocked by robots.txt or declares a different canonical: the URLs that don't belong in a sitemap.

When the Chrome extension picks pages itself, known-unindexed ones (discovered and crawled) come first, at most 10 per property per rolling 24 hours, and the same page isn't picked again within 14 days. It clicks Request indexing in your own Search Console session, the same button you would, so it can't make Google crawl sooner than Google chooses. More on the features page.

Frequently asked questions