Crawled — currently not indexed” means Google’s bot successfully visited and read your page, but decided not to add it to the search results database.This status is “not a technical error” — it is “a value judgment by Google’s systems,” per Google’s own AI Overview synthesis for this query. Google’s own Search Central community guide confirms the same thing in plainer terms: the page may have crawled fine but been judged “not valuable enough to include,” and “there’s no magic bullet to fix this, as Google’s judgment on what to index can be subjective.” Your page works. Google simply chose not to include it.

That distinction matters more than most articles on this topic admit. If it were a technical error, there would be a fix. Because it is a judgment, there is only evidence-gathering, remediation attempts, and waiting.

The articles ranking for this term that I reviewed all offer the same thing: a confident, numbered checklist, presented as though it reliably ends the problem. I can offer something most of them don’t — a real, fully-documented case, tested against three specific hypotheses, with the evidence for each laid out rather than asserted. Two pages on my own site have carried this exact status since June, and I have not resolved them yet. What follows is the actual investigation, not a tidied-up version of it — the hypotheses I tested, the evidence that ruled two of them out, and an honest statement that as of writing, I do not know whether my current fix will work.

What “Crawled — Currently Not Indexed” Actually Means

Crawled — currently not indexed means Googlebot fetched the page successfully, parsed it, and then declined to index it. It is distinct from a crawl failure, a robots.txt block, or a noindex directive. Google reached the content. It read it. It made an assessment and passed.

The critical structural point is the difference between crawled and discovered. Both appear in Google Search Console’s Page Indexing report and they are frequently confused:

• Discovered — currently not indexed: Google knows the URL exists, usually via a sitemap or an internal link, but has not yet fetched it. Nothing has been read. This is often a crawl-budget or scheduling matter.
• Crawled — currently not indexed: Google has fetched and read the page. The content has been assessed. The decision not to index is a decision about the page, not about crawl scheduling.

These require different diagnostic approaches entirely. A page in the discovered state may simply need better internal linking or a cleaner sitemap. A page in the crawled state has already been evaluated — and passed over.

The Real Case: Two Pages, Stuck Since June

Two pages on svetlanasosnova.com have carried this status for over two months: /online-presence-management/ and /what-is-sxo-search-experience-optimization/. Both were crawled within a day of each other — 20 June 2026 and 19 June 2026 respectively — and neither has been indexed since.

Here is what the GSC Index Inspection API returned for both URLs, checked directly rather than read off a dashboard summary:

• coverageState: “Crawled – currently not indexed”
• robotsTxtState: “ALLOWED”
• pageFetchState: “SUCCESSFUL”

The near-simultaneous crawl dates are worth noting. Two pages, crawled a day apart, both assessed and both declined. That pattern suggests a shared characteristic rather than two independent page-level problems — which shaped how I structured the investigation.

Hypothesis One: A Technical Block. Ruled Out.

The first thing to eliminate is anything technical, because it is the only category with a definitive answer. I ran a Live Test in Google Search Console on both URLs. Both returned a successful page fetch, and both confirmed indexing was allowed. There is no block, no directive conflict, no server issue.

This is the step most generic guidance treats as the whole diagnosis. It is not — it is the step that tells you whether you have a real problem or a simple one. A successful fetch with indexing allowed and a persistent non-indexed status means the technical layer is clean and the cause sits somewhere Google will not report to you directly.

Ruling this out took minutes. Everything after it took considerably longer and produced considerably less certainty.

Hypothesis Two: Thin or Low-Value Content. Tested, Then Ruled Out.

The standard advice for this status is “improve content quality.” That is only actionable if you test it rather than assume it. So I compared both affected pages directly against the pages currently outranking them — extracting the competitor content rather than eyeballing the SERP — to establish whether mine were genuinely thinner.

For /what-is-sxo-search-experience-optimization/, the top-ranking competitor was Yoast. Direct extraction of that page found:

• No Core Web Vitals thresholds stated anywhere
• No mention of AI search, GEO or AEO at all
• A hypothetical example in place of real case data
• Visible spam sitting in its own comment section

My page carried specific cited studies, exact dates, and named case data.

For /online-presence-management/, the top-ranking source was Wikipedia — carrying its own visible quality-warning banners: “needs more citations” and “written like a personal reflection.” A competing Study.com result was largely paywalled.

In both head-to-head comparisons, the affected page was more comprehensive and more current than the page ranking above it. Whatever is happening here, “the content is thin” does not survive contact with the evidence.

Hypothesis Three: A Domain Trust Threshold. The Best Fit for the Evidence.

With the technical and content explanations eliminated, the hypothesis that best fits the remaining evidence is a domain-level trust threshold — Google declining to index a newer practitioner site on broad, heavily-trafficked query spaces already anchored by far more established domains.

Both affected pages target exactly that kind of space. One is a general definitional term dominated by Wikipedia. The other sits in a term space dominated by the SEO industry’s own most-established names. In both cases the incumbent has vastly greater domain authority than a newer independent site — and in both cases, as the comparison above showed, the incumbent’s content is measurably weaker.

This aligns with Google’s own framing. If the status is “a value judgment by Google’s systems” rather than a technical error, then the judgment is not solely about the page. It plausibly includes an assessment of whether this domain, at this stage, warrants a slot in a query space that Google already considers well-served.

I want to be clear about what’s actually proven here and what isn’t: this is the hypothesis that best fits the available evidence. It is not confirmed. Google does not report trust thresholds in Search Console, and I have no way to test this one directly the way I tested the first two.

How This Differs From “Indexed, Though Blocked by Robots.txt”

“Indexed, though blocked by robots.txt” is a different scenario and should not be treated as a variant of this one. That status describes a URL that Google indexed and then found itself blocked from crawling — the reverse sequence. My pages were crawled successfully and never indexed at all.

The two produce opposite symptoms and require opposite remediation. A robots.txt-blocked URL is in the index but Google cannot read it, so the listing is typically sparse or unhelpful. A crawled-not-indexed URL is fully readable and simply absent.

I have covered the robots.txt-blocked case, including how to diagnose and resolve it, in my guide to Shopify robots.txt configuration. If your GSC report shows that status rather than this one, that is the correct starting point — the fixes here will not apply.

What I’m Doing Now — and Why I Can’t Tell You If It Works

As of writing, I have submitted a manual indexing request for both URLs through Google Search Console. That is the current remediation step. The outcome is not yet known, and I am not going to write this section as though it were.

A manual indexing request is a request for re-evaluation. It is not an override. It asks Google to reassess the page sooner than it otherwise would — it does not compel a different judgment. If the underlying reason is a domain trust threshold, a re-crawl of unchanged content has no obvious mechanism by which to produce a different result.

So this is where the case sits. Two pages, over two months, technical layer verified clean, content verified stronger than the incumbents, one plausible but unconfirmed explanation, and one unproven remediation step in flight.

I am publishing this unresolved because most of the articles currently ranking for this term present a fix list as though it reliably terminates the problem. In my case it did not, and I suspect that is more common than the published guidance suggests. I am not the only one asking: a Shopify Community thread describes a store owner with over 900 URLs carrying this exact status, asking whether a bulk fix exists. The one reply doesn’t offer one — it reframes the question toward page value and uniqueness instead. No resolution is visible in the thread. If you are watching this status on your own site and the checklist has not worked, you are not doing it wrong. You may simply be in the same position I am.

Frequently Asked Questions

What does “crawled — currently not indexed” mean?

It means Google’s bot successfully visited and read your page but chose not to include it in the search results database. Per Google’s own AI Overview for this query, it is “not a technical error” but “a value judgment by Google’s systems.” The page is accessible and readable — Google simply declined to index it.

Is “crawled — currently not indexed” a technical error?

No. Google explicitly frames it as a value judgment rather than an error. That is why it does not produce a diagnostic code and why Search Console offers no specific reason. In my own case, GSC confirmed robotsTxtState: ALLOWED and pageFetchState: SUCCESSFUL on both affected pages — technically clean, still not indexed.

What’s the difference between “crawled” and “discovered — currently not indexed”?

Discovered — currently not indexed means Google knows the URL exists but has not fetched it yet; nothing has been read. Crawled — currently not indexed means Google fetched and assessed the page, then declined. Discovered is typically a crawl-scheduling matter. Crawled means an evaluation already happened and the page did not clear it.

Does “indexed, though blocked by robots.txt” mean the same thing?

No — it is close to the opposite. That status describes a URL Google indexed and is now blocked from crawling, so it appears in results with limited information. Crawled — currently not indexed describes a URL Google read fully and did not index. I cover the robots.txt-blocked scenario and its remediation in my Shopify robots.txt guide.

How long does “crawled — currently not indexed” last?

There is no reliable published timeframe, and I am not going to invent one. In my own documented case, two pages crawled on 19 and 20 June 2026 remain unindexed more than two months later, with a manual indexing request submitted and the outcome unknown. Community reports describe far longer durations. Treat any article quoting a typical recovery window with scepticism.

Should I just delete or rewrite a page stuck in this status?

Not before testing whether content quality is actually the cause. I compared both affected pages directly against the results outranking them and found mine more comprehensive and more current in both cases — Yoast’s competing page contained no Core Web Vitals data and no AI search coverage; the competing Wikipedia article carried its own quality-warning banners. Rewriting a page that is already stronger than the incumbent addresses a problem you have not confirmed you have.

This case remains open. I will update this post when the status changes — in either direction.