Discovered - currently not indexed: why Google hasn't crawled it yet
Discovered - currently not indexed means Google knows the URL but postponed the crawl. Check server capacity in Crawl Stats, then raise demand with links.
LLaunchScaler·Published ·8 min read
Discovered - currently not indexed means Google has found the URL, through a link or your sitemap, but has not crawled it yet. Google's help names the usual reason: it wanted to crawl the URL but expected the crawl to overload your site, so it rescheduled it; the other cause is that Google does not yet rate the URL as worth fetching.
Those are two separate problems with separate checks. One is crawl capacity, meaning your server cannot take more requests. The other is crawl demand, meaning Google sees little reason to spend requests on these URLs. Find out which one you have before you change anything.
What does "Discovered - currently not indexed" mean?
It means the URL is in Google's queue and has never been fetched. Search Console's help says: "The page was found by Google, but not crawled yet. Typically, Google wanted to crawl the URL but this was expected to overload the site; therefore Google rescheduled the crawl. This is why the last crawl date is empty on the report."
That empty crawl date is what separates it from Crawled - currently not indexed, where Google read the page and declined it. Here Google has not read a word of the page, so rewriting the content does nothing yet. The question is only whether Google can and wants to send the request.
Google's crawl budget guide defines the budget as "the set of URLs that Google can and wants to crawl," made of two parts: a crawl capacity limit and crawl demand. The same guide names "sites with a large portion of their total URLs classified by Search Console as Discovered - currently not indexed" as one of the groups it was written for. For where the status sits among the others, see the page indexing report guide.
Is it a capacity problem or a demand problem?
Capacity is the server side: Google lowers how hard it crawls when your site responds slowly or returns errors. Demand is the value side: Google crawls less when most of the URLs it knows are duplicates, parameter variants or pages nothing links to. Check capacity first, because it takes minutes and rules out the cause Google names in its own definition.
Questions, answered
What people ask about this
01
What does discovered currently not indexed mean?
Google has found the URL, through a link or a sitemap, but has not crawled it yet. Google's help says it typically wanted to crawl the URL but expected the crawl to overload the site, so it rescheduled it, which is why the last crawl date is empty.
Google holds back to avoid overloading your server
Settings, then Crawl stats: host status, average response time, the By response table
Host status warning, response times climbing, 5xx or timeout responses, "Hostload exceeded" in URL Inspection
Crawl demand
Google knows the URLs but does not rate them worth a request yet
The URL list itself: patterns, internal links, sitemap
Parameter or filter URLs, pages linked only from the sitemap, a new site with few links in
How do you check crawl capacity in Crawl Stats?
Open the Crawl Stats report from Settings in the left menu, then Crawl stats. It works only on root-level properties, meaning a Domain property or a URL-prefix property at the root such as https://example.com. Read three things: host status, the average response time chart, and the responses Google received. If all three are clean, capacity is not your problem.
Google says a site with fewer than a thousand pages should not normally need this report. With this status on your key pages, it is still the fastest way to rule the server in or out.
Read the host status. It has three states: no significant availability issues in the past 90 days; at least one issue in the last 90 days but more than a week ago; or an issue in the last week, which the help says you should check for a recurring problem.
Click host status to see its three categories: robots.txt fetching, DNS resolution and server connectivity. Each chart has a dotted red line. Google gives an example: DNS resolution failing for more than 5% of requests on a given day counts as an issue.
Check the average response time chart. It averages every resource Google fetched, pages and assets alike, so look at the trend and at spikes rather than one number.
Open the By response table. Server error (5XX), Page timeout and DNS errors all count as bad responses. Click a row to see example URLs and when the errors happened.
Inspect a few affected URLs with URL Inspection. Google's troubleshooting guide says a "Hostload exceeded" warning there "means that Googlebot can't crawl as many URLs from your site as it discovered."
For response times, web.dev's thresholds are a sensible target. It rates Time to First Byte good at 0.8 seconds or less and poor above 1.8 seconds. Those thresholds were written for users, but Google's crawl budget guide ties crawling to the same thing: if response times get longer, or the site returns 5xx or 429, "the limit goes down and Google crawls less." If the site responds consistently and stays fast, the limit goes up.
Fixing capacity is server work: cache HTML at the edge or behind a CDN, cache slow database queries, and remove whatever returns 5xx. Google's troubleshooting guide adds a test: if Google keeps crawling at your serving limit and important URLs still wait, increase serving resources "for a month and see whether crawling requests increased during that same period." The time to first byte guide covers the server-side fixes in detail.
How do you raise crawl demand for the URLs?
Give Google fewer useless URLs and better reasons to fetch the useful ones. Google's crawl budget guide says the factor you "can positively control the most" is perceived inventory: without guidance, Google tries to crawl every URL it knows about, and duplicates waste that time. Then link the URLs you want crawled from pages Google already indexes.
Link the URLs from indexed pages, not only from the sitemap
A URL that only your sitemap mentions has no internal links, which makes it an orphan: Google knows it exists and nothing on your site says it matters. Google's link guidance says "Every page you care about should have a link from at least one other page on your site," and that links are how Google finds new pages to crawl.
Pick the URLs from this row that you actually need indexed.
For each one, find a related page that URL Inspection reports as "URL is on Google."
Add a standard <a href> link from that page's body text, with anchor text that says what the target covers.
Link new sections from your navigation or a hub page, so every page is a few clicks from the homepage.
The orphan pages guide shows how to find every page with no internal links.
Remove parameter and faceted URL explosions
Filters, sorts and session IDs in query strings multiply one listing page into thousands of URLs. Google's faceted navigation guide says crawlers "will typically access a very large number of faceted navigation URLs before the crawlers' processes determine the URLs are in fact useless," which slows the discovery of your real pages.
If you do not need filtered URLs in search, Google's own example blocks them in robots.txt:
If you need them indexable, point each variant's rel="canonical" at the unfiltered URL, which Google says "may, over time, decrease the crawl volume" of the variants. Google also suggests URL fragments (#color=red) for filters, since Google generally does not crawl fragments. The crawl budget guide for small sites covers when any of this matters below a few thousand pages.
Keep the sitemap and its lastmod accurate
List only canonical URLs that return 200, and give each a <lastmod> that changes when the page changes. Google says it uses lastmod "if it's consistently and verifiably (for example by comparing to the last modification of the page) accurate," and that it uses the value "as a signal for scheduling crawls to URLs that we previously discovered."
Google's troubleshooting guide lists what to avoid: submitting the same unchanged sitemap several times a day, expecting Google to crawl everything in it immediately, and including URLs you do not want in Search. Its words: "Sitemaps are useful suggestions to Googlebot, not absolute requirements." The sitemap lastmod guide covers the date format and when to update it.
How long should a URL stay discovered before you act?
A few days is normal and a few weeks is possible. Google says "crawling can take anywhere from a few days to a few weeks," and its troubleshooting guide adds that "for most sites, new pages will take several days minimum to be noticed." A page published this week sitting in this row is Google's queue working as designed.
Act when a URL you care about stays here for several weeks while the capacity checks are clean and the page is linked from indexed pages. At that point:
Inspect the URL in URL Inspection and run Test live URL to confirm Google can fetch it and nothing blocks indexing.
Click Request indexing for that URL. It has a daily quota per property, and Google says requesting the same URL several times "won't get it crawled any faster," so save it for key pages.
Look at the pattern of the whole row. If most URLs in it share a parameter or template, the demand fixes above will do more than any individual request.
Check what your site sends to crawlers
To see how your pages look to a crawler before Google's next attempt, run the free scan on LaunchScaler. It needs only the URL, no account, and runs 156 checks across 6 of its 7 categories for free. Several line up with this status: server response time against web.dev's 0.8-second bar, including timeouts, 5xx responses, query parameters that multiply into endless URLs, whether a sitemap is discoverable and carries lastmod dates, sitemap entries that do not return 200, and a page with too few internal links. It reads your live site rather than Google's queue, so fix what it flags and then watch the row in the Page indexing report.
First check the Crawl Stats report for server trouble: a host status warning, rising response times or 5xx responses. Then give Google a reason to crawl: link the URLs from pages that are already indexed, remove duplicate parameter URLs, and keep your sitemap and its lastmod dates accurate.
03
How long can a page stay discovered but not indexed?
Google says crawling can take anywhere from a few days to a few weeks, and that most sites should expect several days before new pages are noticed. If a key page with working links and a fast server stays in this status for several weeks, investigate it.
04
What is the difference between discovered and crawled currently not indexed?
Discovered means Google has not fetched the page yet, so it has not judged the content. Crawled means Google fetched the page and decided not to index it, which points to content or duplication rather than crawling.
05
Does a sitemap fix discovered currently not indexed?
A sitemap tells Google the URL exists, which is how many of these URLs were discovered in the first place. Google calls a sitemap a hint and its crawling suggestions not absolute requirements, so internal links from indexed pages carry more weight.
Google found duplicate URLs with no canonical and picked one itself. Add one absolute self-referencing canonical per page, and 301 http and www duplicates.
Excluded by noindex tag means Google saw noindex in a robots meta tag or an X-Robots-Tag header. Find which one with curl and view-source, then remove it.
