"Crawled, currently not indexed" means Google fetched your page, read it, and decided not to put it in the index. Google's own definition ends with an instruction almost every guide on this topic ignores: "It may or may not be indexed in the future; no need to resubmit this URL for crawling" (support.google.com, checked August 2026). The standard advice — hit Request Indexing again — is the one thing Google explicitly says not to bother with.
That sentence changed how we built the alerting in our Bulk Google Index Checker: a page in this state is not a queue problem waiting for another nudge, so treating it as one just burns your daily quota. What follows is what the status actually signals, how it differs from the one it gets confused with, and what moves the needle.
What does "Crawled, currently not indexed" actually mean?
It means the page passed every technical test and still lost on merit. Google reached the URL, rendered it, evaluated it, and judged it not worth a slot in the index. Nothing is broken — no blocked robots file, no noindex, no server error — which is exactly why it is so frustrating to diagnose.
Think of it as a rejection rather than a queue. The page was considered and declined. Resubmitting asks Google to reconsider the same content it just assessed, which is why Google's documentation says there is no need to resubmit and why doing it repeatedly changes nothing.
In practice the verdict is usually about one of three things: the page is thin, it is close to something Google already has, or nothing on the site signals that it matters. The last one surprises people most, because the page can be genuinely good and still fail if it sits in a corner with no internal links pointing at it.
How is it different from "Discovered, currently not indexed"?
The two statuses look almost identical and need opposite fixes. Google's definition of Discovered is precise and rarely quoted accurately: "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."
Read that again, because it contradicts the usual explanation. Most articles attribute Discovered to crawl budget or weak links. Google's stated reason is server capacity — it held off because fetching the page looked likely to strain your site. Hosting and response times are the first thing to look at, not your content.
So the split is clean. Discovered means Google has not looked yet, and the blocker is on the delivery side: server speed, response times, sheer volume of new URLs. Crawled means Google has looked and said no, and the blocker is the page itself. If it turns out to be the first of those, the checks are entirely different and are covered in "Discovered, currently not indexed": it's your server, not your content.
- 1
Confirm the exact status
Open URL Inspection for the specific URL rather than reading the aggregated report, which lags by days
- 2
If Discovered
Check server response times and hosting capacity first, then reduce the number of low-value URLs competing for crawls
- 3
If Crawled
Treat it as a content verdict: is this page substantially different from, and more useful than, what already exists
- 4
Check internal links
A page no other page links to reads as unimportant regardless of how good it is
- 5
Wait for a recrawl
Changes are only re-evaluated when Google returns, which takes days to weeks, not hours
Getting this wrong is expensive. We have watched people spend a fortnight rewriting content for pages that were sitting in Discovered, where the actual problem was a slow server, and the rewrite could not have helped.
Does requesting indexing again fix it?
No, and Google says so in the status definition itself. Request Indexing puts the URL into a priority crawl queue; it does not change the assessment that led to the rejection. If the page is unchanged, a recrawl produces the same verdict.
Where the button genuinely helps is after you have changed something material. Rewrite the page, add substance, fix a canonical, build internal links to it — then requesting a recrawl is reasonable, because there is new evidence for Google to weigh. Pressing it on untouched content is superstition.
There is also a quieter cost. The URL Inspection API allows 2,000 checks per property per day (developers.google.com, checked August 2026), and manual submissions draw on a separate, much smaller allowance. Spending either on pages that have not changed means less capacity for the URLs where a check would actually tell you something new.
How long should I wait before acting?
Give a new page two to four weeks in this state before treating it as a problem. Fresh pages routinely sit in "Crawled, currently not indexed" for a while and then get indexed with no intervention, because Google reassesses as the site accumulates signals. Acting on day three usually means rewriting something that was going to be fine.
The pattern that does warrant action is a cluster. One page in this state is noise. Forty pages from the same template or section in this state is a signal about that template or section — usually thin, near-duplicate output such as tag archives, filtered category views, or product variants that differ by a single attribute.
That distinction is only visible if you can see status across the whole site at once, which the Page Indexing report does not really give you: Google documents its example URL lists as "limited to 1,000 items" and not guaranteed to be complete even below that number. Getting a per-URL answer for every page means going through the API, and the practical way to read that data is covered in how to check if a page is indexed by Google.
What actually gets these pages indexed?
Making them worth indexing, which is unsatisfying but true. In the cases we have seen resolve, the change was substantive: merging four thin pages into one solid one, adding genuine depth where the page was a stub, or linking the page from somewhere Google already crawls often.
Internal linking is the most underrated of those, and the cheapest. A page that nothing links to is telling Google it does not matter, no matter what the content says. Adding two or three contextual links from established pages frequently flips a stuck URL within a crawl cycle or two, and costs nothing.
The tactic that does not work, despite how often it is sold, is pushing the URL through Google's Indexing API. That API is documented for job postings and livestream pages only, and using it on ordinary content is outside its terms; it also does not override an indexing decision that has already been made on quality grounds. We went through what each submission method can and cannot reach in instant indexing: IndexNow, Google's Indexing API, and what actually works.
When is it not worth fixing at all?
Often. Not every page deserves to be indexed, and a site where every filtered view and tag archive is in the index is usually worse off, not better. If a page exists for navigation or for a handful of users rather than for search, this status is Google agreeing with a decision you should have made deliberately.
The honest test is whether you would send a stranger to that URL as the best answer to a real question. If not, the fix is a noindex tag and a clear conscience, not a rewrite. Cutting several hundred pages that were never going to earn a slot concentrates crawling on the ones that will, which tends to help the pages you actually care about.
FAQ
How long does "Crawled, currently not indexed" usually last?
Anywhere from a few days to permanently, and Google gives no timeframe. New pages often clear the status on their own within two to four weeks as the site accumulates signals, which is why acting immediately usually means rewriting a page that was going to be fine. If a page has been in this state for more than a month with no changes, treat it as a decision rather than a delay: Google has assessed the page and declined it, and only a material change to the page or its internal links will prompt a different answer.
Is "Crawled, currently not indexed" a penalty?
No. It is not a manual action and carries no site-wide consequence. It is an ordinary editorial judgement that this specific page does not currently merit a slot in the index, made the same way for every site. A handful of pages in this state is normal on any site of reasonable size, including healthy ones. It only becomes a signal worth investigating when a whole template or section is affected, which usually points at thin or near-duplicate output rather than at anything punitive.
Should I delete pages that are crawled but not indexed?
Only if they serve no purpose for users either. Some pages exist for navigation, filtering, or a small group of visitors, and it is fine for those to stay live and unindexed — adding a noindex tag makes that decision explicit rather than leaving Google to make it. Delete or merge when the page is genuinely redundant, such as four thin variants of the same topic that would be stronger as one. Deleting a page purely because Google declined to index it can remove something users rely on.
Can too many pages in this status hurt the rest of my site?
Not directly, but the underlying cause can. A large volume of thin or near-duplicate pages spreads crawling across URLs that will never earn a slot, which can slow how quickly Google reaches the pages you care about. The fix is not to force the weak pages into the index but to reduce how many of them exist, by consolidating or applying noindex. Sites that cut several hundred low-value URLs often see their remaining pages crawled more promptly afterwards.