Discovered currently not indexed (Google writes it “Discovered – currently not indexed”) is a Search Console status that means Google knows your URL exists but hasn’t crawled it yet. Google’s help page gives the usual reason: it wanted to crawl the page, but doing so “was expected to overload the site,” so it rescheduled. That’s why the last crawl date is empty.
The fix is rarely a button. You either make the site easier to crawl or give Google a better reason to want the page.
I’ll be straight about one thing up front. Nobody can promise when a URL leaves this status, including me. What I can give you is the order I diagnose it in, because the right fix depends entirely on which URLs are stuck.
What Google Means by “Discovered – currently not indexed”
Here’s the full definition from Google’s Page indexing report help: “The page was found by Google, but not crawled yet. Typically, Google wanted to crawl the URL but this was expected to overload the site; therefore Google rescheduled the crawl.”
Notice what’s missing. Google hasn’t judged the content yet, because it hasn’t read it. That makes this status different from “Crawled – currently not indexed,” where Google fetched the page and still passed on it. Different status, different problem.
Google also says, on the same page, that you “should not expect all URLs on your site to be indexed, only the canonical pages.” So a few stuck URLs aren’t an emergency. A stuck money page is.
Why Does Google Find a Page and Then Not Crawl It?
Google’s crawling docs split the decision into two parts. One is about your server. The other is about how much Google wants your pages. Both show up as the same status in Search Console, which is exactly why people apply the wrong fix.
Crawl capacity is how hard Google can push your server. Google’s crawl budget documentation says the limit goes up when response times stay stable, and goes down when the site slows or returns 5xx errors or HTTP 429 rate limiting. Slow or flaky hosting means fewer crawls. Simple as that.
Crawl demand is how much Google wants to crawl you at all. For Googlebot, that depends on “a site’s size, update frequency, page quality, and relevance, compared to other sites.” The factors you can move are perceived inventory, popularity and staleness. Google calls inventory the one “you can positively control the most.”
Here’s my honest read after 8 years of looking at this report. On small and medium sites, the problem is almost always demand, not capacity. The same Google doc says it’s written for sites with 1 million unique pages or more, very fast-changing sites, and sites where a large share of URLs sits in this exact status.
Which Pattern Is Your Site Showing?
Before fixing anything, open Indexing > Pages, click the status in the “Why pages aren’t indexed” table and read through the example URLs slowly, because the kind of URL that’s stuck tells you far more than the total count ever will. Start there. This is the table I use:
| What the stuck URLs look like | Most likely cause | Where I’d start |
|---|---|---|
| A handful of posts published this week | Normal queue | Wait, and link to them from strong pages |
| Real posts that are only in the sitemap | Weak internal linking | Fix 2 |
| Tag pages, filters, parameters, search results | Crawl waste | Fix 5 |
| Thousands of near-identical generated pages | Low demand from thin content | Fix 1 and Fix 6 |
| Important pages across the whole site, plus slow load | Server capacity | Fix 4 |
| URLs you’ve never heard of | Old links, spam or a CMS leak | Fix 3 and Fix 5 |
If you only remember one row, make it the tag and filter row. It’s the big one. In my audits, junk URLs outnumbering real ones is the most common story behind a big count in this status.
The Fixes, in the Order I Apply Them
These run from cheapest to most expensive. I don’t move to the next one until I’ve ruled out the one before it.
Fix 1: Confirm the Page Deserves an Index Spot
Ask whether this URL should exist as its own page. If it’s a thin tag archive, a near-copy of another article or an auto-generated location page, the kindest thing is to merge it, redirect it or return a 404. Google’s docs say a 404 or 410 is “a strong signal not to crawl that URL again.”
If the page is genuinely useful, keep going. Be honest, though. I’ve seen people spend weeks pushing pages that Google was right to ignore.
Fix 2: Link to It From Pages Google Already Crawls
Google’s help page says a page “must be linked from a known page, or from a sitemap” to be found. Found is not the same as prioritized, though. A URL that lives only in the sitemap, with no internal links, looks unimportant.
So link each stuck page from 2 or 3 relevant pages that are already indexed, using descriptive anchor text that tells both readers and Google what they’ll find on the other side of the click. Your homepage, category hubs and top posts are the strongest places. A clean folder layout helps too, and my guide to URL structure SEO shows how I group pages so crawlers find related content faster.
Fix 3: Clean Up the Sitemap
Your sitemap should list only canonical URLs that return 200 and that you want in search. Google’s sitemap docs say to include “the URLs in your sitemap that you want to see in Google’s search results.” Redirects, noindexed pages and parameter URLs in there are noise. Cut them.
Two details people miss. Google ignores the <priority> and <changefreq> values completely. And it only uses <lastmod> when it’s “consistently and verifiably” accurate, so a plugin that stamps today’s date on every URL trains Google to ignore it. If you haven’t submitted the sitemap properly yet, how to submit a sitemap to Google Search Console walks through it.
Fix 4: Check Server Health in Crawl Stats
Open Settings > Crawl stats in Search Console. Look at average response time and the Host status panel, which reports problems with robots.txt fetching, DNS resolution and server connectivity. Then check the responses breakdown for 5xx and 429 codes.
Google notes that sites under a thousand pages shouldn’t need this report, so don’t obsess over it on a small blog. On a large store or a site on cheap shared hosting, though, this is where the capacity problem shows itself. If URL Inspection ever says “Hostload exceeded,” Google’s own advice is to add server resources.
Fix 5: Cut Crawl Waste
This is the fix that moves big numbers. Google’s list of best practices is refreshingly concrete:
- Consolidate duplicate content so Google crawls unique pages, not unique URLs.
- Block truly unwanted URLs, like endless sorted views, with robots.txt.
- Don’t rely on noindex to save crawling, because Google still has to fetch the page to see it.
- Eliminate soft 404s, which “will continue to be crawled, and waste your budget.” My guide to fixing soft 404 errors matches each cause to its fix.
- Avoid long redirect chains.
Filters are the usual offender on ecommerce sites. My category page SEO guide covers which filtered pages deserve to be indexable and which should stay out of the crawl. If the URLs point to other pages with a canonical tag, you’ll often see them later under a different status, which I explain in Alternate Page With Proper Canonical Tag: Should You Worry?.
Fix 6: Make the Pages Worth Crawling
Remember, page quality is one of the demand factors Google names. If a site publishes 300 posts in a burst and half of them repeat each other, Google has little reason to hurry. Merging overlapping posts into one stronger page often does more than any technical fix.
Google’s crawl budget doc says crawling resources for Search factor in “popularity, overall user value, content uniqueness, and serving capacity.” Three of those four are about the content, not the server.
Fix 7: Request Indexing for a Few Key URLs Only
URL Inspection lets you ask Google to crawl a single URL. Use it for your five or ten most important stuck pages, after fixes 1 to 6. Google’s help says there’s a daily limit, that submitting “does not guarantee” indexing, and that for many pages a sitemap is the better route.
Don’t request the same URL every day. It doesn’t stack. Once is enough. I use it once per page, after the page is actually ready.
Fix 8: Validate, Then Give It Time
Once the pattern is fixed, click Validate fix on the issue page. Google’s help says validation “typically takes up to about two weeks, but in some cases can take much longer.” It also offers a useful trick: submit a sitemap of only your most important pages, filter the report by it, then validate that smaller set.
How Long Does It Take to Clear?
There’s no fixed timeline, and I’d be wary of anyone who gives you one. Google’s own numbers are the only honest anchors. A new page “can take a few days” to be indexed, a requested URL can take “up to a week or two,” and validation can run about 2 weeks or longer.
In my experience, fixes to internal links and crawl waste show up gradually, a few URLs at a time, because Google recrawls the site at its own pace and nothing you do in Search Console forces that schedule. If nothing moves after several weeks, recheck the pattern table. Usually a second cause was hiding behind the first one.
When Is It Fine to Leave Discovered Currently Not Indexed Alone?
More often than people think. If the stuck URLs are parameters, internal search results, feed URLs or pages you’d never want ranking, the status is harmless. Google isn’t crawling junk, which is what you’d want anyway.
What I care about is the list of pages that should earn traffic. If every page on that list is indexed, a big number in this status is a housekeeping job, not a traffic problem.
What Won’t Fix It
A few things I see recommended all the time don’t help:
- Indexing API plugins. Google’s Indexing API is only for pages with JobPosting or BroadcastEvent embedded in a VideoObject structured data. It isn’t a shortcut for blog posts.
- Resubmitting the same sitemap every day. Google already reads sitemaps regularly.
- Deleting and republishing the post. The new URL still has to be discovered and scheduled, and whatever held back the old one is still there.
- Adding noindex to the rest of the site. It saves no crawling, since Google still has to fetch each page to see the tag.
When the Problem Is Bigger Than a Checklist
If thousands of important pages are stuck, the site is large, or the cause looks like hosting and architecture together, it’s worth getting a technical SEO specialist and your host involved. That usually means server logs, crawl data and a careful plan for what to consolidate.
That’s the kind of project our SEO service handles, and the deeper server and crawl work sits with our technical SEO service. For a do-it-yourself pass, my technical SEO checklist covers the basics this post builds on. You can also request a free SEO audit and I’ll tell you which row of the pattern table you’re in.
Frequently Asked Questions
Is Discovered – Currently Not Indexed a Penalty?
No. It’s a crawl scheduling status, not a manual action or a quality verdict. Google hasn’t even read the content yet. Manual actions appear in their own report in Search Console, so if nothing shows there, you’re dealing with crawl priority, not punishment.
Will Requesting Indexing Fix Discovered Currently Not Indexed?
Sometimes, for a single page. Google says a request doesn’t guarantee indexing and has a daily limit, so it can’t fix a site-wide pattern. Use it for a few key URLs after you’ve fixed internal links, the sitemap and any crawl waste.
Does a Small Site Have a Crawl Capacity Problem?
Rarely. Google’s own guidance says sites under a thousand pages shouldn’t need the Crawl Stats report. On a small site, stuck pages usually point to weak internal linking, thin or overlapping content, or a sitemap full of junk URLs.
Should I Delete Pages Stuck in This Status?
Only the ones that shouldn’t exist, like thin tag pages or duplicates. Return a 404 or 410 for removed pages, or redirect them to a close match. Pages that deserve to rank need better links and content, not deletion.
Last updated: September 2026 by Mizanur Rahman
