Pages stuck in "Discovered" and "Crawled — currently not indexed"
"Discovered — currently not indexed" and "Crawled — currently not indexed" look like the same problem in Search Console. They are not, and treating them the same is why so many pages sit in them for months. Here is how each one is diagnosed and what actually moves a page out.
Method, not a metric. A method study drawn from the coverage states we see most across IndexerNow accounts. It carries no aggregate recovery rate: coverage outcomes depend on the page, and a single blended percentage across unrelated sites would not mean anything you could apply to yours.
The problem
Both states are silent failures. The page is live, the sitemap lists it, Search Console shows no error, and the page still isn't in Google. Most owners respond by clicking "Request indexing" again, which is the correct move for exactly one of the two states and a waste of time for the other.
"Discovered — currently not indexed" means Google has the URL on file and has not fetched it. That's a scheduling decision: Google has judged that your site's crawl demand doesn't justify reaching this page yet. New domains, large catalogues and sites with thin internal linking hit this constantly. Re-presenting the URL through the Indexing API is genuinely useful here, because the request is a crawl hint and crawling is precisely what has not happened.
"Crawled — currently not indexed" is a different verdict. Googlebot fetched the page, evaluated it, and chose not to index it. Submitting it again asks Google to repeat a decision it has already made. Nothing changes until the page does, and the reason is usually that it duplicates another page, has near-empty content, competes with a stronger internal page, or carries a canonical pointing elsewhere.
What we ran
- 1
Read the state from Google, not from a guess
Run the URLs through Google's URL Inspection API against your own verified property so you get the actual coverage state, the last crawl date, and the canonical Google selected. Bulk-checking a whole set at once is what makes the pattern visible. One URL tells you nothing; two hundred tell you whether the problem is site-wide or confined to a section.
- 2
For "Discovered": fix the crawl path, then request
Check the page is reachable by internal links from something Google crawls often, that it is in the sitemap, and that nothing in robots.txt or a noindex contradicts the request. Then push it through the Indexing API, paced under your daily quota. Sites with thousands of orphaned URLs need the internal linking fixed first. The API request buys attention for one page; internal links buy it for the whole section.
- 3
For "Crawled": change the page before you resubmit
Find why Google passed. Is there a near-identical page? Does the canonical point somewhere else? Is the unique content below the boilerplate a couple of sentences? Fix that, then resubmit. The resubmission tells Google to look again, but only once there's something new to look at.
- 4
Verify and keep the record
Re-inspect after a few days and keep the batch history. The value compounds: after two or three cycles you can see which sections of the site convert from submitted to indexed and which ones never do, which is a far better content roadmap than a keyword tool.
What changed
The change that matters is diagnostic, not cosmetic: instead of one undifferentiated pile of "not indexed" pages, you get two piles with different jobs: one that needs crawl attention and responds to submission, one that needs the page rewritten and doesn't.
Sites that make that split stop spending their daily API quota on pages Google has already rejected, which frees the whole allowance for pages that have never been fetched. That reallocation is usually worth more than any increase in submission volume.
Takeaways you can copy
- Discovered = not crawled yet. Submitting genuinely helps.
- Crawled = fetched and rejected. Submitting again changes nothing; the page has to change.
- Bulk-inspect to see the pattern. One URL is an anecdote; the set is a diagnosis.
- Orphaned pages need internal links, not more requests.
- Keep the batch history. Which sections convert is the most useful content signal you will get.
Run the same workflow on your URLs
Everything above runs on your own Google account, your own Cloud project and your own quota. Never a shared pool. Start with the free bulk check to see which of your pages Google actually has.
Tools and guides used here
Frequently asked
How long does "Discovered — currently not indexed" usually last?
There's no published timeframe. It's a crawl-scheduling decision, and it depends on how much crawl demand Google assigns your site. It can clear in days on an established domain and persist for months on a new one. What shortens it is making the page easy to reach and explicitly requesting the crawl, rather than waiting.
Will resubmitting a "Crawled — currently not indexed" page eventually work?
Not on its own. Google fetched the page and decided against indexing it; the same page submitted again is the same decision. Change what Google evaluates (the uniqueness and depth of the content, the canonical, the internal competition) and then resubmit so it gets looked at again.
Does the Indexing API work for normal pages, or only job postings and livestreams?
Google's documentation scopes the Indexing API to JobPosting and BroadcastEvent structured data. In practice a submission for other page types functions as a strong crawl request, and Google does not guarantee indexing for any of them. That is why this workflow always pairs submission with a URL Inspection check rather than treating a 200 response as success.