“Discovered – currently not indexed” means Google knows your page exists and has never fetched it.
Not read it and rejected it. Never requested it at all. The URL sits in a queue, and Google has not got round to it.
That distinction decides everything about the fix. Rewriting a page Google has never opened cannot change its mind, because there was no judgement to change.
This guide covers what the status means, why Google defers a crawl, and what actually clears the queue. It uses the 36 URLs currently stuck in this status on technoxprt.com, the site you are reading, and the crawl budget figures behind them.
The short version
- Google has not read the page. Content edits are aimed at a decision that was never made.
- The cause is crawl priority, and crawl priority follows site-level trust.
- Check what share of your crawl budget is wasted before doing anything else. On this site, a fifth of it goes to URLs that return 404.
- Internal links and fewer wasted crawls move the needle. Repeated indexing requests do not.
What the Status Actually Means
Google’s pipeline runs in three stages: discovery, crawling, indexing. This status means stage one finished and stage two has not started.
Discovery usually happens through your sitemap. You submit a sitemap listing 130 URLs, Google reads the file, and now it knows about 130 URLs. Knowing is cheap.
Crawling is not cheap. Every fetch costs Google bandwidth and costs your server a request, so Google rations it. Each URL gets a priority, and low-priority URLs wait.
“Discovered – currently not indexed” is what waiting looks like in the report.
How to confirm it on a specific URL
Open Search Console, go to Pages, and click into the status. The “Last crawled” column is the tell.
A date means Google fetched the page. “N/A” means it never has, and every URL in this status should show N/A.
You can double-check any single URL with the URL Inspection tool. If it reports “URL is not on Google” with no crawl date, the page has genuinely never been fetched.
Crawled vs Discovered: Opposite Problems
Search Console has a similar-sounding status that means something close to the reverse.
| Status | Google fetched it? | What it tells you |
| Crawled – currently not indexed | Yes | Google read the page and declined it |
| Discovered – currently not indexed | No | Google has not reached the page yet |
The first is a verdict on the page. The second is a statement about your site’s crawl capacity.
Mixing them up wastes a lot of effort, because the advice for one does nothing for the other. If you are looking at the other status, the crawled – currently not indexed guide covers it in the same detail.
What 36 Stuck URLs Look Like
Here is the list on technoxprt.com, a 179-page WordPress blog.
- 24 blog posts, all current and on-topic: ecommerce SEO, Cloudflare SEO, security headers, an SEO proposal template, a Screaming Frog comparison, AI search statistics.
- 12 location pages on a subfolder microsite.
Every one shows Last crawled: N/A.
This is worth sitting with, because it contradicts what the status is usually assumed to mean. There is no thin content here, no duplicates, no spam. These are among the better pages on the site.
Compare it with the same site’s “Crawled – currently not indexed” list, where 28 of 51 URLs were RSS feeds, pagination, author archives and two JavaScript files.
So the pages Google read were mostly junk it was right to skip. The pages Google never read are the ones worth reading. That is not a content problem in either direction.
Where the Crawl Budget Actually Goes
Search Console has a report that explains this directly, and most people never open it. It lives under Settings → Crawl stats.
Here are the last 90 days for this site.
| Total crawl requests | 4,780 (about 53 a day) |
| Average response time | 556 ms |
| Host status | No problems in 90 days |
Fifty-three requests a day sounds workable until you break it down.
By purpose
| Refresh | 90% |
| Discovery | 10% |
Nine out of ten requests are Google re-checking pages it already has. Only 10% goes to finding anything new.
That is roughly 478 discovery requests across 90 days — about five a day, shared across every unseen URL on the site.
By response
| OK (200) | 73% |
| Not found (404) | 20% |
| Moved permanently (301) | 4% |
| Moved temporarily (302) | 2% |
A fifth of every crawl request on this site returns a 404. That is around 956 wasted fetches in 90 days, and it lines up with the 80 URLs sitting in the “Not found” bucket of the indexing report.
By file type
| HTML | 28% |
| JavaScript | 23% |
| CSS | 15% |
| Other | 7% |
| Image | 4% |
Only 28% of crawling touches an HTML page. Scripts, stylesheets and images take 42%.
And by crawler type, 10% is AdsBot, which checks landing pages for ads and contributes nothing to indexing.
Stack those together and the picture is clear. A small budget, 90% of it spent re-reading known pages, a fifth of the total thrown at dead URLs, and under a third touching HTML at all. Thirty-six pages waiting in that queue is the arithmetic working as expected.
Why Google Gives a Site a Small Budget
Crawl capacity is not handed out evenly. Google decides how much attention a site gets, and a handful of factors drive that decision.
1. How much the site is linked to
This is the largest factor and the least comfortable one. Links from other sites are how Google judges whether a site is worth returning to.
The site in this example has four referring domains that Google counts. That is not a crawl budget problem you can fix in WordPress — it is a reason to work on earning links.
2. How much of the budget is wasted
Every 404, redirect chain and duplicate URL consumes a request that a real page could have used. This one you can fix, and it is usually the fastest win available.
3. How fast the server responds
Google crawls slower sites more cautiously. At 556 ms average this site is not being throttled for speed, but a site averaging two or three seconds would be.
4. How often the site genuinely changes
Sites that publish consistently get checked more often. A site that publishes once a quarter trains Google to visit once a quarter.
5. How new the site or section is
New domains and new sections start with very little. This resolves with time and links, and there is no shortcut worth taking.
What Actually Clears the Queue
In the order that gives the most return for the effort.
Stop wasting crawl requests
Open Crawl stats and look at your 404 share. Anything above a few per cent is budget being burned.
Find where those URLs are linked from and fix the links, or redirect the URLs to a relevant page. Deleting a page without a redirect is how most of them appear in the first place.
Also cut redirect chains down to a single hop, and keep feeds, pagination and parameter URLs out of your sitemap.
Link to the stuck pages from pages Google already crawls
This is the most direct lever you control. Google discovers and prioritises through links, and a page reachable only from the sitemap reads as unimportant.
Take your stuck URLs and add links to them from your most-crawled pages, in the body text where they make sense. Not a sidebar block, not a footer list.
Your most-crawled pages are usually the homepage, the main category pages, and whatever ranks best.
Request indexing — once
URL Inspection has a “Request indexing” button. Use it on your most important stuck pages, once each.
It genuinely can jump the queue for a single URL. Repeating it for the same URL does nothing, and there is a daily quota, so spend it on pages that matter.
Publish on a steady schedule
Consistent publishing raises how often Google checks a site. It is slow, it compounds, and it works.
Earn links
The slowest fix and the one that raises the ceiling. Everything above redistributes a fixed budget more sensibly. Only links make the budget bigger.
What Does Not Work
- Rewriting the page. Google has not read it. There is no assessment to improve.
- Requesting indexing repeatedly. The quota is spent and the priority does not move.
- Resubmitting the sitemap. The URL is already discovered. That is what the status says.
- Paid indexing services. Most work by generating links from low-quality sites, which creates a separate problem without solving this one.
- Adding the URL to more sitemaps. Discovery is not the bottleneck.
The common thread is that all of these address discovery or quality, and the bottleneck is neither.
Working Through a Long List
Thirty-six URLs can be handled by hand. Three hundred cannot, and treating them all equally is the usual mistake.
Sort the list first. Pages that could realistically earn traffic get internal links and an indexing request; parameter URLs, thin tag archives and old pagination get removed from the sitemap instead.
Most long lists shrink a lot at this step, because much of what is stuck was never worth crawling.
Track the survivors as a group
Put the URLs you actually want indexed into their own sitemap file and submit it separately.
Search Console reports coverage per sitemap, so a dedicated file turns a scattered list into one number that either moves or does not. It changes nothing about how Google treats the pages, and you can delete it once the work is done.
Check Whether It Is Only Google
Before assuming the problem is your content, check whether other search engines have the pages.
Search for one of your stuck URLs in Bing. If Bing has it and Google does not, the pages are fine and you are looking at a Google crawl-priority issue.
If nothing is indexed anywhere, the cause is more likely to be site-wide.
What that check turned up here
On this site it turned up something worth fixing. Bing had indexed nothing at all — searching the brand name returned only an Instagram profile, and Bing autocorrected the name to a different word entirely.
The cause was mundane. Bing Webmaster Tools held one sitemap, submitted in 2015, listing 7 URLs, last crawled in 2019. A current sitemap had never been submitted.
That is worth checking on any site with an indexing problem, because Bing also feeds DuckDuckGo and Microsoft Copilot. Submitting a current sitemap and switching on IndexNow costs twenty minutes, and IndexNow pushes new URLs to Bing as they publish rather than waiting for a crawl.
Google has no equivalent, so it does not fix the status in this guide. It does stop one search engine’s problem being mistaken for a content problem.
How Long It Takes
Fixing wasted crawl budget shows up fastest. Clear a large block of 404s and the Crawl stats report reflects it within a few weeks.
Internal linking takes longer, because Google has to re-crawl the linking pages before it sees the new links. Four to eight weeks is normal before stuck URLs start moving.
Link-driven improvement is measured in quarters, not weeks.
Watch the URL count in the report rather than individual pages, and watch the discovery share in Crawl stats. If that 10% starts climbing, the work is landing.
Frequently Asked Questions
Is “Discovered – currently not indexed” a penalty?
No. Penalties appear as manual actions in a separate Search Console report and come with a notification. This status is a queuing outcome, not a judgement about your site.
How is it different from “Crawled – currently not indexed”?
Crawled means Google fetched the page and decided not to index it. Discovered means Google never fetched it. Check the “Last crawled” column: a date means crawled, “N/A” means discovered only.
Will improving the content get the page indexed?
Not directly, because Google has not read the content. Improving a page only matters after it has been crawled. Spend the effort on internal links and on removing wasted crawl requests instead.
Does requesting indexing in Search Console work?
It can, for one URL at a time, and it is worth using on your most important stuck pages. There is a daily quota, and repeating the request for the same URL does not improve its odds.
Why do new websites see this status so often?
New sites have almost no links, and links are the main input to crawl budget. Google allocates very little crawling until a site has some history and some references from elsewhere.
How many URLs in this status is acceptable?
It depends on what they are. A large site with thousands of low-value parameter URLs in this status is fine. A small site with its best articles stuck there has a real problem.
Can too many 404s cause this?
They contribute. Every 404 consumes a crawl request that could have gone to a real page. On the site in this guide, 20% of all crawl requests return 404, which is a meaningful share of a small budget.
Does site speed affect it?
Yes. Google crawls slower sites more cautiously to avoid overloading them. Average response times of two seconds or more will reduce how much Google fetches, though speed alone rarely explains a large backlog.