Google Search Console has a report called Page Indexing. It groups the pages Google decided not to index by reason, and one of those groups is Discovered, currently not indexed.
Most advice on this status tells you to improve your content. That advice ignores what the words actually say.
Discovered means Google knows the URL exists. Currently not indexed means it is not in the index. What sits between those two ideas is the part everyone skips. Google never fetched the page. It has not read a word of your content, so your content cannot be the reason.
- Google found the URL and never crawled it. The last crawl date is empty, which is the tell that separates this from every similar status. Read it per URL in URL Inspection, or ask your agent to work through a set of them with ContextBolt SEO.
- Google publishes one typical cause, and it is server capacity. It expected the crawl to overload your site, so it rescheduled.
- The report that checks that is Crawl stats, under Settings. Look at Host status and average response time, not at your word count.
- The second cause is crawl demand. A URL that exists only in your sitemap, with nothing linking to it, gives Google no reason to spend a fetch.
- Requesting indexing on hundreds of URLs does nothing. Neither cause is fixed by asking again.
What the status actually says
Google’s Page Indexing report documentation gives this status one short definition, and it is worth reading twice.
In Google’s words, the page was found but not crawled yet, and typically Google wanted to crawl the URL but expected that to overload the site, so it rescheduled the crawl.
Two things follow from that, and both cut against the standard advice.
First, a crawl and an index are different events. A crawl is Googlebot fetching the page over HTTP. Indexing is Google deciding to store and rank what it read. This status stops at the first step, so nothing about the page’s quality has been assessed yet.
Second, Google names a cause, and the cause is your server. Not thin content, not missing headings, not a schema problem. Google expected the request to be more load than your site could take, so it put the fetch back in the queue.
The tell
Open one of these URLs in Search Console’s inspection tool and look for the last crawl date. On a genuinely discovered page there is not one, because no fetch ever happened.
That single empty field is how you know you are in the right diagnosis. If a crawl date is sitting there, you have a different status and a different problem, and the rest of this page will send you the wrong way.
Where you are seeing this
If you landed here from a search and have not opened the report yet, the path is short.
- Open Google Search Console and pick your property.
- In the left menu, under Indexing, click Pages.
- Scroll past the summary chart to the section titled Why pages aren’t indexed.
- Click the row named Discovered - currently not indexed to see example URLs.
The number next to that row is a count of URLs, and the list underneath it is a sample rather than the full set. That distinction matters more than it looks, and there is a section on it further down.
Google names one cause, and it is your server
This is the half of the diagnosis almost nobody runs, and it is the half Google actually documents.
Googlebot works to a limit that Google’s crawl budget guidance calls the crawl capacity limit, or hostload. It caps how much time Google’s crawlers will spend holding connections open to your server. The limit is not fixed. Google adjusts it based on how your site behaves.
The mechanism is stated plainly in that document. If the site responds consistently and its response times stay stable or improve, the limit goes up. If the site slows down or responds with server errors, the limit goes down and Google crawls less.
So a slow server does not just annoy visitors. It shrinks the number of pages Google will fetch from you at all.
The same page makes the link to this status explicit. It lists three cases where crawl budget is worth managing, and one of them is any site with many URLs marked Discovered, currently not indexed. Google is telling you where to look, in its own documentation, and the popular advice on this status still goes straight to content.
One caveat
Crawl budget is not most people’s problem. Google’s own thresholds are large sites over a million pages updating moderately often, and medium sites over ten thousand pages changing daily.
If you run a 60-page site and have twelve URLs in this bucket, your server is almost certainly fine and the second cause below is yours. Do not go rebuild your hosting over a dozen URLs.
The report that checks it, and why you cannot automate it
There is a report in Search Console built for exactly this question, and it is buried where nobody clicks.
Go to Settings, then Crawl stats. Google’s documentation for the report describes it as statistics about Google’s crawling history on your site, including how many requests were made, what your server responded, and any availability issues.
Two readings do the work.
Host status: green means Google found no significant crawl availability problem on your site. Yellow means it hit one more than a week ago. Red means it hit at least one in the last week, and a red host status next to a growing discovered bucket is about as close to a confirmed diagnosis as this report gets.
Average response time: the average across everything Google fetched in the period. You are not looking for a magic number. You are looking at the shape of the line over ninety days, because a rising line and a growing bucket are the same story told twice.
Now the part that is genuinely annoying, and it is the reason this check gets skipped.
The Crawl Stats report is not in the API. The Search Console API exposes four resources, search analytics, sitemaps, sites and URL inspection. There is no crawl stats endpoint and no crawl errors endpoint. The one report that diagnoses the documented cause of this status is the one report you have to open in a browser and read with your eyes.
That is worth saying out loud, because it explains a lot about the advice online. The checks that got automated are the checks that got written about. This one did not, so it fell out of the standard playbook, and an entire genre of posts now recommends rewriting content to fix a problem that starts at the TCP layer.
The other cause: Google did not think it was worth a fetch
Server capacity is the documented cause. It is not the only one, and on small sites it is rarely the real one.
The other half is crawl demand. Google’s crawl budget guidance describes demand as varying with a site’s size, update frequency, page quality and relevance, compared with other sites. Strip the hedging and it means Google is deciding whether a fetch is worth making at all.
The clearest version of that decision is a URL Google only knows about because it appeared in your sitemap.
https://example.com/blog/post-412
https://example.com/tag/productivity/page/7
https://example.com/products/sku-88213?color=blueThree URLs, all in the sitemap, none linked from anywhere a human would go. A sitemap is a list of addresses you would like crawled. An internal link is a signal from a page Google already fetched that the destination matters. Only one of those is evidence, and it is not the sitemap.
This is why the bucket fills up on programmatic pages, deep pagination, faceted parameter URLs and tag archives. Not because the content is bad. Because nothing on the site argues for them.
The uncomfortable version
If a page has no internal links, gets no traffic and nobody would notice it missing, Google declining to fetch it is not a bug in Google. It is Google agreeing with the rest of the internet.
The instinct is to get the number to zero. On most sites that number should not be zero, because most sites generate URLs nobody needs. The useful question is not how big the bucket is. It is whether anything in it is a page you would be upset to lose.
Discovered versus crawled, currently not indexed
These two statuses sit next to each other in the same report and describe opposite situations. Telling them apart takes ten seconds and saves you fixing the wrong thing. A third neighbor, excluded by a noindex tag, is neither, because that one is your own instruction rather than Google’s decision. A fourth, blocked due to access forbidden, reads like this one and is its opposite, because there Google did make the fetch and your server refused it, so the last crawl date is filled in.
| Status | Did Google fetch the page? | What it is telling you |
|---|---|---|
| Discovered, currently not indexed | No. Last crawl date is empty | A capacity or demand problem. Content untested |
| Crawled, currently not indexed | Yes. It read the page and declined it | A quality judgment on what it read |
| Duplicate without user-selected canonical | Yes. It read it and merged it | You never declared which URL counts |
Content advice belongs in the second row and nowhere near the first. If you are rewriting pages Google has never opened, you are optimizing against a reader who has not arrived. The third row has its own diagnosis, and it is the one people most often mistake for a penalty.
What not to do
Three things that feel productive and are not.
Do not run Request Indexing on hundreds of URLs: the tool is quota-limited and built for individual pages. It is fine for one post you just published and cares about. It does not raise your crawl capacity limit, and it does not give Google a reason to want the page.
Do not resubmit your sitemap daily: Google already has it. Resubmission is not a nudge, and a sitemap that has not changed carries no new information.
Do not delete the pages in a panic: a URL sitting in this status is not being penalized and is not hurting the rest of the site. If it is a page you want indexed, link to it. If it is not, leaving it alone costs you nothing.
The honest version is that this status often resolves itself, and the two things worth doing are slow fixes rather than buttons. Make the server faster. Link the orphans from pages Google already crawls.
Running the check across a whole site
One warning before you plan an afternoon around this.
The report caps its examples. Google states the list is limited to 1,000 items and is not guaranteed to show all URLs in a given status, even when there are fewer than a thousand. So the count on the row and the URLs you can see are two different numbers, and no endpoint hands you the missing ones.
That gap and the honest ways around it are covered in the canonical status walkthrough, which hits the same wall from the other side. The short version is that you generate your own URL list and inspect them one at a time, because per-URL truth is available even when the per-status list is not.
Doing that in an agent is the difference between a script you maintain and a sentence you type. It is the same move as running a full site audit that way, where the agent does the looking and you do the deciding.
Copy this prompt
Read my sitemap and inspect every URL in it against Search Console.
List only the URLs with no last crawl date, and for each one tell me
how many internal links point at it. Sort by internal links, ascending.That output is the whole diagnosis in one table. Zero internal links at the top of the list is your demand problem, sorted by how orphaned each page is. If instead the list is long and includes pages that are well linked, the cause is capacity and you go read Crawl stats.
Where the data comes from
This diagnosis needs two things. Your own index status, which Google gives you free, and somewhere for readings to accumulate, because a bucket of 40 URLs means nothing until you know whether it was 12 last month.
ContextBolt SEO is the tool I build. It puts a read-only Search Console connection and a full SEO toolkit inside the agent you already work in, so inspecting a hundred URLs is a sentence rather than a hundred tabs. The Search Console tools are free and never spend your monthly research credits. It is $35 a month with a 7-day free trial, and there is no dashboard to work in, because every lookup lands on a board that fills itself while you work somewhere else.
Crawl behavior is exactly the kind of thing that needs a history. A single reading tells you almost nothing. Two readings a month apart tell you whether the fix worked, and a dated folder of them does that better than a report you have to remember to open.
What I would actually do
Take ten URLs out of the bucket, not all of them.
Confirm the last crawl date is empty on each. Then open Crawl stats and look at host status. If it is red, you have your answer and the work is on the server, not the page.
If it is green, count internal links to those ten URLs. If most of them have none, you do not have an indexing problem. You have a site architecture that never mentions these pages, and Google is simply reading it correctly.
Then decide which of the ten you actually want indexed. My guess is that it is fewer than ten, and that the honest fix is to link the two that matter and let the rest sit where they are. A number in a report is not a task. Somebody has to decide it is worth doing, and that somebody is not Googlebot.