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 is not 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 is a scheduling decision: Google has decided your site's crawl demand does not justify getting to 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 — usually because 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 tells you whether the problem is site-wide or 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 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 is what tells Google to re-evaluate, but only after there is something new to evaluate.
- 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 does not.
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 is no published timeframe — it is a crawl-scheduling decision and 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 re-evaluated.
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.