Technical SEO Published September 24, 2026 · By Nabin Thakur 9 min read

How to Fix “Discovered - currently not indexed” in Google Search Console (2026)

“Discovered - currently not indexed” means Google knows your page exists and has never fetched it. Nothing on the page has been judged yet, good or bad. That makes it a different problem from its better-known cousin, with a different fix. I am writing this with twelve of my own URLs in exactly this state, so what follows is what I checked on a real site, including the standard advice that turned out not to apply.

Short Answer

What does “Discovered - currently not indexed” mean, and how do you fix it? Google found the URL, usually through your sitemap or a link, and put off crawling it. Google’s own explanation is that it “wanted to crawl the URL but this was expected to overload the site,” so it rescheduled. On most small sites the server is fine and the real limit is priority: Google does not yet see enough reason to spend a crawl on that page.

Check the server first. Then give Google more reasons to crawl: fewer junk URLs competing for attention, a clean sitemap, links from pages it already visits, and signals from outside your site. Request Indexing helps for a handful of important pages. It is not a fix on its own.

The 30-second version

Google has the URL but has not crawled it. The report shows N/A under Last crawled.
Your content is not the problem yet. Google has not looked at it.
Google blames server capacity. On small sites it is usually crawl priority. Crawl stats tell you which.
Internal links are not always the answer. Mine were already strong, and the pages still waited.

What it means, in Google’s words and in practice

In the Page indexing report, Google describes these as pages it has found but not crawled yet. The usual reason, it says, is that crawling them was expected to overload the site, so the crawl was rescheduled. That is also why the Last crawled column is empty for every URL in this status.

Read that literally and you would go and upgrade your hosting. Sometimes that is right. On a big site with a slow or struggling server, Googlebot really does hold back. But on a site with a few dozen or a few hundred pages, the server is rarely what limits crawling. What limits it is demand: how much Google wants to crawl you at all. Google’s crawl budget documentation splits crawling into exactly those two things, capacity and demand, and a small or young site usually has plenty of the first and very little of the second.

Discovered or Crawled: they are not the same problem

	Discovered - currently not indexed	Crawled - currently not indexed
Has Google fetched it?	No. Last crawled shows N/A	Yes
Has it judged the content?	No	Yes, and passed on it
Usual cause	Crawl priority, sometimes server capacity	Quality, duplication or site trust
What moves it	More reasons to crawl, a healthy server	A better page, or merging it into one that already ranks

If your URLs are in the second column, this is the wrong guide. The “Crawled - currently not indexed” guide covers that one.

A real example: twelve of my own pages

When I pulled the Page indexing report for seorevive.in on 21 September 2026, 49 pages were indexed and 12 were sitting in Discovered - currently not indexed. All 12 showed N/A for last crawled. Google had the URLs and had never fetched them.

The uncomfortable part is which pages they were. Six are the pages that sell things: the services hub and five service pages, including technical SEO audits and Google penalty recovery. Five are the translated versions of the free audit tool, in German, Spanish, French, Portuguese and Arabic. The last one is the privacy policy.

First, rule out a block. URL Inspection’s live test on the service pages came back clean: the URL is available to Google and the page can be indexed. No noindex, no robots.txt block, no canonical pointing somewhere else, a normal 200 response. Nothing was stopping Google. It simply had not come.

Then, the server. Crawl stats for the 90 days to 22 September show about 1,350 Googlebot requests, roughly 15 a day. Average response time was 426 ms and 93% of requests got a normal 200. That is not a struggling server, so Google’s stated reason does not fit here.

Then, where the crawling went. 95% of those requests were refreshes of pages Google already knew, and 5% were discovery. Only about a third were HTML pages at all; the rest went on images, stylesheets and scripts. So in practice Google fetched a handful of pages a day, and nearly all of them were pages it already had.

The advice that did not apply. The usual first fix for this status is “add internal links.” On my site that would have done nothing. All six service URLs are in the main menu and the footer on every page, linked from the homepage between two and seven times each, and linked from between 6 and 25 other pages in the body text. Another service page, the AI visibility audit, sits in exactly the same menu with the same kind of links. That one did get crawled and indexed, and it shows up in search. Same template, same server, same links. Internal linking was not what held the other six back.

What is left, on a site like this, is demand: how much reason Google has to spend its small daily crawl on a page it has not seen before. That is what I am working on now, with the steps below, and I will update this page with what moved and how long it took.

The five real causes

Low crawl demand. A new or small site with few outside links and little sign that a page matters. Google is in no hurry. This is the most common cause on small business sites, and it was mine.
Server capacity. Slow responses, timeouts or server errors make Googlebot back off. This is the cause Google names in its definition. Check it rather than assume it.
Too many URLs competing. Filters, parameters, tag and archive pages, near-duplicates. Discovery gets spread thin, and the pages you care about wait behind ones you do not.
Weak internal linking. A page that exists only in the sitemap, or sits several clicks deep, looks unimportant. This is a real cause on many sites. Just check before you assume it is yours.
A noisy sitemap. If the sitemap lists redirects, noindexed pages or URLs that canonicalise elsewhere, it stops being a reliable list of what matters, and the good URLs in it get lost among the rest.

How to tell which cause is yours

This takes about twenty minutes in Search Console.

Pages report. Click Discovered - currently not indexed and look at what the URLs have in common: one folder, one template, one publishing date.
URL Inspection. Run Test live URL on two or three of them. If the live test says the page can be indexed, you do not have a technical block. Move on.
Crawl stats (Settings, then Crawl stats). Look at host status first. Any problems there, or response times climbing, and capacity is part of your answer. Then look at By purpose. A small number of requests with discovery as a thin slice is a demand problem.
Links to each stuck page. Is it in the main menu? Linked from the homepage? From any post that already gets impressions? Or only in the sitemap?
Wasted URLs. Compare the number of URLs Google knows about with the number of real pages you have. A big gap means parameters, archives or duplicates are soaking up attention.

What to do about it

If the server is the problem, fix that first. It is the one cause Google spells out, and nothing else helps until it is sorted.
Cut what competes. Remove, merge or noindex thin archives, parameter URLs and duplicates. Fewer, better URLs get crawled sooner.
Keep the sitemap honest. Only live, canonical, indexable pages, and lastmod dates that change only when the page really changes.
Link stuck pages from pages Google already visits often, if they are not linked well already. A normal link in the body text, with words that describe the page.
Earn a few real links from outside. Mentions and links from other sites are one of the clearest signals that a URL is worth crawling. On a small site with strong internal links, this is usually what is missing.
Use Request Indexing for the few pages that matter most. It puts the URL in a priority queue. There is a daily limit, and it does not guarantee a crawl leads to indexing.
Then give it time. On a small site, weeks is normal even when everything else is right.

What not to do

Do not re-stamp dates to look fresh. Changing publish dates or lastmod without changing the page teaches Google that your dates mean nothing.
Do not press Request Indexing on the same URLs every day. It will not speed anything up.
Do not change the URL or delete and republish the page. Google starts from nothing again.
Do not buy cheap links to “force indexing.” They are far more likely to hurt than help.

When it is fine to leave it

Pages published in the last few weeks. Give them time before you worry.
Pages that do not need to rank. My privacy policy has been in this status for months and it costs me nothing.
Low-value sections of very large sites, which will always be waiting somewhere.

Worry when the pages stuck here are the ones that make you money. On my own site, they were.