A page in "Discovered - currently not indexed" is not ranking badly. It is not in Google at all. It cannot rank, cannot earn a click, and cannot be cited by an AI answer.
And Google has never opened it.
That is the whole meaning of the status, and it is why the usual advice misses. Rewriting the content, adding schema, polishing the meta description: all of it edits a page Google has not read.
The status sitting next to it in the same report, "Crawled - currently not indexed", calls for the opposite response.
Two statuses, two opposite problems
"Discovered" means Google knows your URL exists and has not spent a visit on it. "Crawled" means Google visited and decided not to keep the page. One is a decision about whether the trip is worth taking. The other is a verdict on what was found at the end of it.
John Mueller drew the line on a Google podcast in July 2026: for discovered pages, Google knows they exist "but we haven't actually visited them", and a page that has not been visited cannot enter the index.
| Discovered - currently not indexed | Crawled - currently not indexed | |
|---|---|---|
| What Google has | The URL and the signals around it | The full page |
| What Google did | Queued it, then skipped it | Fetched it, then declined it |
| Where the decision happened | Before the visit | After the visit |
| Last crawl date in Search Console | Empty | Filled in |
| Dominant cause | Cost of the visit against expected value | Value of what was found |
| What moves it | Demand for the URL | Merit of the page |
The two also differ in history. Discovered pages have never been in the index.
Crawled pages often have: first-party data from an index monitoring platform found that 70 to 80% of URLs in that status had been indexed before and were later dropped.
The decision happens before Google reads the page
Google cannot judge a page it has not fetched. For a discovered URL it judges the URL instead: the pattern it belongs to, the pages that link to it, and what past visits to similar URLs returned. The page's own content plays no part, because the decision comes first.
Google's own wording on this status changed, and the change says more than the current text does.
- Then, the help center said Google "tried to crawl the URL but the site was overloaded", so the crawl was rescheduled.
- Now, it says Google "wanted to crawl the URL but this was expected to overload" the site.
Picture a courier with a full van.
Before: he drove to your street, found the road blocked, and rescheduled the delivery. Now: he reads the address, remembers that the last three drops on that street came back undelivered, and never loads the parcel.
Nothing about your parcel changed. The decision was made from the address.
An attempt that failed became a prediction that prevents the attempt. With no content to go on, Google extrapolates from the rest of the domain and the shape of the URL.
One thing to be clear about: quality is not absent from this decision. On that same July 2026 episode, Mueller said that when Google's systems have serious doubts about a site's overall quality, they crawl less and index less, which shows up in both statuses.
The lever is what differs. In "crawled", quality was judged on the page, so the page can answer.
In "discovered", it was inferred about the URL before anyone read it, so editing that page cannot reach the decision. What reaches it is crawl demand: how much Google wants to spend a visit on this URL at all.
What actually moves it
Four levers act on crawl demand, in descending order of speed and effect. For a handful of important pages, the first one is usually enough on its own. Before applying any of them, answer one question: do these URLs deserve to exist?
If they are filter combinations, session IDs, or near-duplicates, the fix is to stop emitting them, which the last section covers. If they are pages you need indexed, work down this list.
1. A contextual link from a page Google visits often
The fastest lever available, and the one most site owners apply wrong.
Pick the source page by its last crawl date, visible in URL Inspection. A page Google visited yesterday passes crawl demand this week. A page Google visited in March passes nothing.
Then write the link into the argument rather than bolting it on:
❌ Bolted on: "We also cover crawl depth. Read our guide."
✅ Woven in: "Pages more than four clicks from the homepage get visited far less often, which is where most discovered URLs sit."
Same destination. The woven version tells Google what the target page covers before it decides whether to visit, which is exactly the moment the decision is made. Finding the sentence where that link genuinely belongs is what Unveil SEO does by reading the meaning of every paragraph on the site.
2. Cut the depth, or cut the URLs
If the target sits five clicks from anything Google visits regularly, one link will not fix the pattern.
Either promote the section so the crawl depth drops for the whole template, or apply the fork above and stop emitting the URLs.
3. Sitemap hygiene
Keep the affected URLs in a submitted sitemap with an accurate lastmod.
Weak on its own, cheap, and it compounds with everything else in internal linking and crawl budget.
4. Server response time
If Crawl Stats shows slow responses, this is not one option among four. It is the ceiling on the other three.
A faster server creates no demand. It removes the reason Google predicted the visit would cost too much.
How you will know it worked: the last crawl date on the target URL stops being empty. That changes first, before indexing, before impressions.
What won't move it
Most published fixes act on the page's content or on Google's queue. Neither is where the decision was made. Two of them are things Google explicitly advises against, and one works but is the slowest route to the right variable.
| What people do | Why it doesn't reach the decision |
|---|---|
| Resubmit the URL in Search Console, repeatedly | Requesting indexing can grant a temporary freshness boost that gets the page in briefly, then out again. The symptom clears, the cause does not. |
| Add schema, rewrite the meta description | Both live on a page Google has not fetched. |
| Rewrite the content | Same. The judgment was made about the URL, not the text. |
Apply noindex to save crawl budget | Google advises against it. The page is still requested before the directive is seen, so the visit is spent anyway. |
| Block junk URLs in robots.txt to free budget | Google states the freed budget is not shifted to other pages unless your site is already hitting its capacity limit. |
Backlinks deserve a fairer verdict than the rest of that table. Popularity is one of the factors Google names as feeding crawl demand, so external links act on exactly the right variable. They are simply the slowest way to act on it.
One caveat on the lever this article recommends most: adding internal links in bulk is not the fix either. Ten links from templates Google rarely visits move nothing, while one link from a frequently crawled page, in a sentence that carries meaning, moves the URL.
When the simple fix isn't enough
If the crawl date is still empty after a few weeks, the cause sits one level up. A discovered URL has three of them: your server looked expensive to visit, your URL inventory looked wasteful, or your site looked too weak to be worth the trip. Check them in that order.
Start with a severity check. There is no target ratio of indexed to non-indexed pages, and Google's own developer documentation carries a large share of intentionally unindexed content.
A small count on low-value URLs is normal scheduling. A rising count, or any concentration on pages you need, is the signal.
1. Capacity
Open Crawl Stats and read host status and average response time across the last 90 days, which smooths out one-off blips.
Then check for the trap Google flagged in July 2026: security layers and CDNs that serve an "are you a bot?" challenge to Googlebot with a 200 success code. The visit is spent, and nothing shows up as an error.
Worth knowing where the rules now live. In December 2025, Google moved its crawl budget guidance out of Search Central into a separate crawling documentation site, because the same crawlers now serve products beyond Search.
The rewritten guide adds a line with real consequences: each crawler has its own demand, but the capacity limit is shared across all of them. Your Googlebot capacity is now openly shared with the fetchers behind Google's other products.
2. Inventory
Export the affected URLs and look for a shared pattern: parameters, facets, sort orders, pagination, session IDs.
Four thousand discovered URLs are rarely four thousand problems. They are usually two templates. Grouping them by the pages that link to them, the pass an internal link audit runs, turns the export into two patterns you can act on.
For everything that shouldn't exist: consolidate duplicates, return 410 for what is gone, block in robots.txt what should never be fetched.
3. Site-level demand
The most likely cause by volume, and the last one to act on, because it is the only one measured in months.
The signals: a large share of the site never crawled, thin or templated pages already sitting in the index, content produced at scale. Mueller named undifferentiated AI-generated content as a live example of what triggers those doubts.
Expect weeks, not days. Fix validation in Search Console typically runs up to two weeks and can take longer, and it queues a recheck rather than forcing a visit. On a newer site publishing a lot of content, Mueller has said this state is expected for a while before it shifts over time.
