“Crawled – currently not indexed”: what it actually means and what to do

Of all the messages Search Console can show you, “Crawled – currently not indexed” is the one that generates the most confusion — and the most wasted effort. It sounds like an error. It isn’t. It is a decision.

Google found the URL, fetched it, looked at it, and chose not to put it in the index. Nothing is broken. No rule was violated. Your page simply did not clear the bar Google set for this site, on this day, for this piece of content.

That distinction matters, because it rules out most of the fixes people try first.

What the status is not

It is not a robots.txt block. That has its own status, and the API reports robotsTxtState: DISALLOWED.

It is not a noindex tag. That is “Excluded by ‘noindex’ tag”, and it appears in the API as indexingState: BLOCKED_BY_META_TAG or BLOCKED_BY_HTTP_HEADER.

It is not a crawl failure. A 404, a 5xx or a redirect loop all produce their own pageFetchState values — NOT_FOUND, SERVER_ERROR, REDIRECT_ERROR. If any of those were the problem, you would see them instead.

And it is not a manual action. Penalties appear in the Manual Actions report, not in the coverage state of a single URL.

What you have is a page Google can reach perfectly well and has judged not worth storing — at least for now.

How it looks through the API

In the URL Inspection API, this state comes back inside inspectionResult.indexStatusResult:

{
  "verdict": "NEUTRAL",
  "coverageState": "Crawled - currently not indexed",
  "robotsTxtState": "ALLOWED",
  "indexingState": "INDEXING_ALLOWED",
  "pageFetchState": "SUCCESSFUL",
  "lastCrawlTime": "2026-08-14T09:12:41Z"
}

Read those five fields together and the picture is unambiguous: crawling is allowed, indexing is allowed, the fetch succeeded, Google has a copy — and the verdict is still not PASS. Every technical gate is open. The page did not get through anyway.

The lastCrawlTime is the field most people ignore, and it is the useful one. A page crawled three days ago and still not indexed is a live decision. A page last crawled four months ago is a page Google has stopped caring about, which is a different problem with a different fix.

Why it happens

In practice, “crawled but not indexed” clusters into a handful of causes.

The page adds nothing that isn’t already indexed. Near-duplicates are the largest bucket by far: product variants, location pages built from one template, thin tag and archive pages, syndicated copy, category pages that repeat their children’s snippets. Google already has this content; it declines to store another copy.

The page is effectively an orphan. If nothing links to it from pages Google already trusts, it looks like a leaf that nobody in your own site considers important. Sitemap inclusion is not a substitute for internal linking — a sitemap tells Google the URL exists, internal links tell Google it matters.

The site’s overall crawl priority is low. New domains, sites with a large ratio of low-value URLs, and sites that recently ballooned in size all get triaged. Individual good pages get caught in that triage.

The content is thin relative to intent. Not “thin” as in word count — thin as in it does not answer the query it targets any better than what is already ranking.

Something changed in rendering. If the meaningful content arrives via JavaScript and the render times out or fails, Google indexes what it actually got: a shell. The fetch succeeds, so nothing looks broken, but there is nothing worth indexing in what was fetched.

What actually helps

Start by confirming it is really this status and not a soft 404 wearing a disguise. Empty search-result pages, out-of-stock products and deleted posts that still return HTTP 200 are routinely classified as SOFT_404 — and the fix for those is entirely different (return the correct status code, or restore the content).

If the status is genuine, the interventions that work are the boring ones:

Link to it from pages that are already indexed. Not from the footer. From body content on relevant, established pages. This is the single most reliable lever, and it is the one most teams skip because it takes editorial work rather than a settings change.

Consolidate the near-duplicates. If you have eleven pages saying roughly the same thing, pick the one that should win, canonicalise or merge the rest, and give the winner the depth the eleven never had individually.

Make the page worth storing. Original data, a table nobody else assembled, a genuinely complete answer. Rewriting the title tag will not change a judgment about the body.

Check the rendered output, not the source. Fetch the page the way a bot would and confirm the content is actually present in what comes back.

Then wait, and watch. Many of these pages flip to indexed on their own once the site’s crawl budget or the page’s internal link profile improves. That is why the status says currently.

What does not help

Pressing “Request indexing” repeatedly does not raise your standing; the queue is not a priority lane, and hammering it on the same URL changes nothing. Third-party “instant indexer” services do not have a private channel into Google’s index. Adding the URL to a sitemap for the fifth time tells Google something it already knows. And rewriting metadata while leaving the body untouched addresses none of the reasons above.

The part that catches people out

This status is not stable. Pages move out of it without warning, and pages move into it months after being happily indexed — which is the same problem in reverse.

Search Console’s Page Indexing report will tell you eventually, but it aggregates and it lags, typically by several days. By the time a URL appears in that report, it has been out of the index for a while. If it was earning traffic, you have already lost that traffic.

The only precise answer for a specific URL at a specific moment comes from inspecting that URL — either by hand in Search Console, or through the URL Inspection API. Doing that once tells you where you stand today. Doing it on a schedule tells you the day something changes, which is when the fix is cheapest.

That is the entire premise behind Crawlert: check every URL you care about through the official API, every day, and say something the moment a verdict flips.