Crawled, Currently Not Indexed: 11 Fields, No Reason Why

"Crawled, currently not indexed" means Google fetched your page, read it, and decided not to keep it. Google's definition is exactly that plain: "The page was crawled by Google but not indexed. It may or may not be indexed in the future; no need to resubmit this URL for crawling." [1] Nothing errored. Nothing is blocked. The page was considered and passed over.

That last clause is why the usual advice underperforms. Most guides tell you to improve quality and add internal links, then request indexing. Two of those three are aimed at the wrong status, and the third is the one thing Google explicitly says you don't need to do.

This post gives you the boundary that decides your first move (crawled versus discovered), the three API fields that prove there's no technical block hiding underneath, and the triage rule for deciding which of these pages are worth touching at all.

TL;DR:

• Google's URL Inspection API returns 11 fields, and only three can explain a non-indexed verdict: robotsTxtState, indexingState, and pageFetchState. All three describe technical blocks. "Crawled, currently not indexed" is the case where all three come back clean.
• So the report has already told you everything it knows, and none of it is a reason. The vagueness in every guide on this topic is inherited from the data, not from lazy writing.
• Crawled and discovered need opposite first moves. Google hasn't read a discovered page yet, so the job is getting it crawled. It has read a crawled page, so the job is the page.
• Most of these URLs are not worth touching. Fix the ones you can prove matter: they earned clicks recently, or they carry a change you're still measuring.

What does "crawled, currently not indexed" mean?

It means Google requested your URL, received the page, evaluated it, and chose not to add it to the index. The page is not broken, blocked, or redirected. Google made a judgment call about whether the page was worth storing, and the answer was no, at least for now. Google says it "may or may not be indexed in the future." [1]

The distinction that matters: this is a steady state, not an event. There's no timestamp on it, no "this happened on Tuesday" moment to hunt for. A page can sit here from the day it's published and never generate a single change your monitoring would notice. That property causes more missed pages than the status itself does, and it's the thing to hold onto for the triage section below.

Why does Search Console give no reason for it?

Because the reporting has no field for one. Google's URL Inspection API returns 11 fields describing index status, and exactly three of them can explain why a page isn't indexed: robotsTxtState (is robots.txt blocking it), indexingState (is a noindex rule blocking it), and pageFetchState (did the fetch fail with a 404, 403, 5xx, or soft 404). [2]

Every one of those describes a technical block. "Crawled, currently not indexed" is, by definition, the case where all three come back clean and the page still isn't in. The three explanatory fields have fired correctly and reported nothing wrong, and there is no fourth field carrying the actual judgment.

This is worth internalizing because it reframes the whole topic. Every other not-indexed state names its own cause: a noindex tag names itself, a 404 names itself, a redirect names its destination. This one names nothing, and it's the only one that doesn't. When ten articles all resolve to "improve quality and internal links," that's not ten writers being lazy. That's ten writers looking at the same empty field.

There is one narrow exception, and it fires less often than you'd hope. If Google folded your page into another URL as a duplicate, the googleCanonical field can name that URL, which tells you exactly what happened. But Google's own reference note on that field is blunt: "The URL of the page that Google selected as canonical. If the page was not indexed, this field is absent." [2] So it's worth checking, and it's usually empty. When it does have a value pointing somewhere other than the page itself, you have a duplication problem with a named target, not a quality problem, and the survivor question becomes the real decision.

How is it different from "discovered, currently not indexed"?

Google has read a crawled page and hasn't read a discovered one. That single difference flips the first move. Google describes discovered as a scheduling outcome: "Google wanted to crawl the URL but this was expected to overload the site; therefore Google rescheduled the crawl." [1] Nobody has evaluated your content yet. For a crawled page, somebody has.

Which means the two standard fixes belong to different statuses:

• Internal links and sitemap health are the discovered lever. They tell Google a URL exists and is worth reaching. That's the bottleneck when the page has never been fetched.
• The page itself is the crawled lever. Google already has your content. Adding three more links to a page Google has read and declined doesn't change the thing it judged.

Links aren't useless in the crawled case (a page nothing links to is telling Google something about its own importance), but they're rarely the binding constraint, and they're the first thing most people spend a week on. The honest sequence is to fix the status you actually have. Most lists cover both statuses with one paragraph of advice, which is precisely how you end up doing the discovered work on a crawled problem.

Is "crawled, currently not indexed" a problem?

Usually not on its own. A handful of these URLs is normal on any site, and Google gives no timeline for reconsideration. It becomes a problem in two shapes: when a page that was earning traffic ends up here, or when the count is large enough to describe your site rather than a few pages.

That second shape is the one Google talks about directly. John Mueller, Search Advocate at Google, on what to do when a lot of pages land here:

"It's not so much that I would say you should take these situations and try to fix them. From a technical point of view, it's not that you need to fix this technical issue that Google is not indexing this page at the moment. But rather, you almost need to... when you recognize a bigger pattern like this, like Google is not indexing a lot of your pages, and there's no technical reason, you almost need to take a step back and think about the quality overall." [3]

He's explicit elsewhere in the same discussion that this scales with Google's read of the whole site: "if our systems are seriously worried about the quality of the website that they will reduce the number of pages at the index." [3]

Read as guidance, that's a size test. Three URLs here is housekeeping. Three hundred is not three hundred page-level problems to work through, it's one site-level signal wearing a per-page costume, and grinding through the list one URL at a time is the wrong response to it.

How do you fix crawled, currently not indexed?

Work the page, not the request. In order: check whether Google named a different canonical (that's a duplication answer, not a quality one), then diff the page against its closest siblings for near-duplicate coverage, then decide whether the page earns its own URL at all. Only after a real change is there anything to resubmit.

The three outcomes, and picking between them is most of the work:

• Differentiate it. The page overlaps a sibling enough that Google sees no reason to store both. Give it a job the sibling doesn't have. The same-intent test is the useful screen here: two pages covering one topic is fine, two pages doing one job is the problem.
• Fold it in. If the overlap is real and one page should carry the topic, 301 it into the stronger one rather than trying to rescue both. The refresh, consolidate, or retire decision walks that call with the signals to base it on.
• Leave it. Plenty of pages are fine sitting outside the index. Tag pages, thin archive URLs, and near-empty filters don't need rescuing, and the honest move is to record the decision so it stops reappearing on your list.

On resubmitting: Google says there's no need to resubmit this URL for crawling. [1] That applies to the unchanged page, and it's the most commonly wasted action on this status. Requesting indexing on a page you haven't touched asks Google to re-run the evaluation that just returned no. After a substantive change, requesting indexing is reasonable.

One caveat about the "linked from" data Search Console shows for these URLs, because it's a trap we've walked into. The referringUrls sample is Google's own, and it's frequently blank even for pages with healthy internal linking. A blank list is not evidence of an orphan. Count real in-body links in your repo before you conclude anything about the link graph, and remember that navigation, footer, and sitemap entries aren't the links Google is weighing.

Which of these pages are actually worth your time?

The ones you can prove matter. A coverage list sorted by URL is not a priority order, and most of it is genuinely fine. Two signals justify opening your editor: the page earned real clicks in the last 28 days despite being out, or it carries a change you're still measuring, whose result cannot be judged at all while the page sits outside the index.

That second one is easy to miss and it's the more urgent of the two. If you changed a title six weeks ago and you're waiting to see whether it worked, a page that has fallen out of the index doesn't produce a bad result. It produces no result, and the experiment stays open forever while you read the flat line as failure.

This is where we got it wrong on our own account, and the lesson generalizes. Our indexing check was built to watch for pages dropping out: it compared inspection states over time and fired when a page transitioned from indexed to not. That catches real de-indexing well. It completely missed a money page that had been parked in "crawled, currently not indexed" the whole time, because there was no transition to observe. The page never fell out. It was never in. It sat inside a group count that read "47 not indexed" and nothing ever raised it, until we went looking on the live account we read for 30 days in July 2026 and found it by hand.

The fix was to stop asking "what changed" and start asking "what's out right now that we can prove matters," cross-referencing the not-indexed state against clicks in the daily store and against our own open change markers. It's a state check, not a change check, and if you're monitoring this yourself, that's the distinction worth stealing. Anything watching for drops will be blind to a page that was never indexed in the first place.

We tuned the threshold on the same real data: a not-indexed page with no open change joins the list only above five clicks in 28 days, and the list is capped at five pages. The rest stay as group counts. Both numbers exist to stop the check from handing back the entire coverage report with a new coat of paint, which is the failure mode of every tool in this category, ours included until we capped it. If you want that split done for you, separating the blocks worth fixing from the noise is the job that page does.

What can't Search Console tell you about this?

Why Google declined the page. That's the whole shape of the limitation, and everything past the canonical exception is inference, including anything a tool tells you. Three more limits ride along, and they're worth knowing before you trust any coverage number:

• Coverage is reconstructed, not read. The full page-indexing report exists only inside the Search Console interface and is exposed by no API. Every tool in this space, ours included, rebuilds it by inspecting the URLs it knows about, which come from your sitemap. A page missing from your sitemap is invisible to all of them.
• The data describes the last crawl, not your live site. A page you fixed this morning still shows the old state until Google recrawls it. Treat every status as a statement about the past.
• Nothing here can request indexing for you. The URL Inspection API is read-only, and Google's separate Indexing API covers only job postings and broadcast events. That click stays yours.

And the limit under all of them: Search Console stops at the click. It can tell you a page is out of the index and what it was earning before. It can't tell you what that page was worth to your business, which is the number that should decide whether you fight for it.

Reading this without opening the coverage report

By hand, this is a filtering job you do in a browser tab and abandon halfway. You open the page indexing report, click into "crawled, currently not indexed," get a list of URLs with no reasons attached, and start opening them one at a time to work out which ones you care about. It's a check that gets skipped, which is how a page that earns clicks sits outside the index for a month.

QueryScope reads it from your editor instead, and hands your agent the split rather than the list: which URLs are genuinely blocked, which are waiting, which are duplicates Google is handling correctly, and which ones it can prove are costing you something. Your agent already has the repo open, which is where the answer to a crawled-not-indexed page actually lives, since the judgment Google made was about content Search Console can't show you. For the one-line meaning of coverage states and canonicals, the Search Console glossary defines each with its caveat.

Sources

• Google Search Console Help, Page Indexing report ("The page was crawled by Google but not indexed. It may or may not be indexed in the future; no need to resubmit this URL for crawling"; on Discovered: "Google wanted to crawl the URL but this was expected to overload the site; therefore Google rescheduled the crawl"). [1]
• Google Search Console API, UrlInspectionResult reference (the 11 fields of IndexStatusInspectionResult; googleCanonical: "The URL of the page that Google selected as canonical. If the page was not indexed, this field is absent"). [2]
• Search Engine Journal, Google Explains SEO Connection Of Site Quality To Non-Indexed Pages (John Mueller, Search Advocate at Google, July 17 2026: "you almost need to take a step back and think about the quality overall"; "if our systems are seriously worried about the quality of the website that they will reduce the number of pages at the index"). [3]