"Discovered - currently not indexed" in Search Console
Google knows this URL exists and has not fetched it yet. Unlike its near-namesake, this one usually has a measurable cause: your server is slow, or you are asking for more crawling than you have earned.
This URL is not indexed and it should be. Something is in the way.
Is it still happening?
Paste the URL. We time three requests to measure what Google experiences, count how many URLs your sitemaps advertise in total, and check whether this one is among them and linked from your homepage.
Whether your server is fast enough for Google to crawl freely, how much crawling you are asking for, and whether anything prioritises this URL.
We cannot see Google's crawl queue or your position in it, and we measure from one location on one network, so our timings are an indication rather than what Googlebot experienced. The Crawl stats report in Search Console shows the response times Google actually recorded, and that is the authoritative number.
What this error actually means.
Google found this URL, put it in the queue to crawl, and has not got to it. It has never seen the content. There is nothing on the page for it to have objected to.
The word to notice is "discovered", not "crawled". Discovery already worked: a sitemap or a link told Google the URL exists. What has not happened is the fetch. Google's own documentation says the usual reason is that requesting the URL would have overloaded the site, so it rescheduled.
That makes this the more tractable of the two "currently not indexed" rows. Its sibling is a judgement about content quality that no tool can verify. This one is mostly about server capacity and crawl budget, and both are measurable from outside.
The exception is scale. A large site that publishes faster than Google is willing to crawl it will always have URLs sitting here, and that is normal rather than a fault.
5 things that produce this error.
Ordered by how often they turn out to be the cause, not by how obvious they look.
The server is slow enough that Google throttles itself
Google adjusts crawl rate to what a site can absorb, and backs off when responses are slow or start erroring. A page that takes over a second to answer is a page Google will fetch sparingly, and the effect compounds across a site rather than showing up on one URL.
for i in 1 2 3 4 5; do
curl -s -o /dev/null -w "%{time_starttransfer}s\n" https://example.com/page
doneMore URLs advertised than the site has crawl budget for
Faceted navigation, calendar archives, parameter combinations, and paginated tag listings can put tens of thousands of URLs in a sitemap. Google spends its allowance in priority order, and a genuinely important page can sit behind thousands of filter permutations it will never index.
The URL is advertised but not prioritised
It sits in a sitemap and nothing else refers to it. A sitemap entry establishes that a URL exists; internal links from pages that are already crawled frequently are what move it up the queue. A URL with only the first signal waits.
A publishing burst Google has not caught up with
Import a few thousand pages at once and this row fills up for weeks. Nothing is broken. Google is working through a backlog at whatever rate your site has earned, and the fix is patience plus not adding more.
The site is new and has little crawl allowance yet
Crawl budget scales with a site's established importance. A domain with few external links gets crawled slowly regardless of how fast the server is, and new sections of a large site behave the same way.
How to clear it.
Measure the response time before assuming anything else
This is the documented primary cause and the only one you directly control. Sample time to first byte several times rather than once. If the median is over a second, that is your answer and no amount of internal linking will compensate for it.
Make the expensive path cheap
Cache the render, move slow third-party calls out of the request path, or serve the page statically. Crawl rate rises on its own once your server demonstrates it can absorb more, without you asking Google for anything.
Stop advertising URLs you do not want crawled
Audit what is actually in your sitemaps. Parameter variants, empty filter combinations, and thin archive pages consume the same budget as your real pages. Removing them is usually faster than trying to earn more budget.
# How many URLs are you asking Google to crawl?
curl -s https://example.com/sitemap.xml | grep -c "<loc>"Link to the page from somewhere Google already crawls often
A contextual link from a page that gets crawled daily is the strongest way to move a URL up the queue. Your homepage, a hub page, or a recently published article all work; a footer link buried on every page does not carry the same weight.
Request indexing once, then leave it
For a single time-sensitive URL, URL Inspection plus Request Indexing jumps the queue. It does not scale and it does not fix the underlying rate, so use it for the page that matters and address capacity for the rest.
Next to check.
LintPage rules covering this: ttfb-pro, performance, sitemap-presence
Questions, answered.
What is the difference between "Discovered" and "Crawled - currently not indexed"?
How long does "Discovered - currently not indexed" last?
Does site speed affect indexing?
Will requesting indexing fix it?
Should I remove pages from my sitemap to fix this?
Is this caused by low-quality content?
Catch this one before Search Console does.
Search Console tells you weeks after the fact. LintPage runs 60 checks against a URL in about 30 seconds. Free, no signup.
run a full scan →