Crawled — currently not indexed is the most confusing Search Console state: Google looked, then chose not to index.
What it means
In Search Console → Pages → Not indexed → Crawled — currently not indexed:
- ✅ Google knows the URL exists
- ✅ Googlebot fetched it
- ❌ Google decided not yet to add it to the index
The 5 most likely causes (in order)
- Insufficient content quality. Under ~300 words, mostly images, or substantially duplicative — Google judges it “not worth indexing”
- Sparse internal links. No other page on the site links to it; no equity flows in
- New-domain sandbox. New domains see 1–3 months of conservative treatment across all new content
- Too similar to other pages on your site. Google picks one and skips the rest
- Canonical points elsewhere. Even great content won’t be indexed if the canonical aims at another URL
Shortest fix path
- Expand the article to 800+ words, add 2–3 captioned images, add an FAQ
- Link to it from at least 3 internal pages (home, category, related)
- In Search Console, use the URL inspection tool and click
Request Indexing - Wait 7–14 days. This state doesn’t flip overnight.
When this guide applies
Only for Crawled — currently not indexed. For Discovered — currently not indexed (knows but hasn’t crawled), causes and fixes differ.
Decision checklist
- If the error started right after a change, roll back or isolate that change before trying unrelated fixes.
- If the error happens only in production, compare environment variables, build output, cache, permissions, and platform settings.
- If the error happens only for one account or browser, test permissions, cookies, extensions, quota, and regional availability.
- If two fixes seem possible, choose the one that is easiest to verify and easiest to undo first.
When to stop debugging
Stop and escalate when you cannot reproduce the issue, when logs contradict the UI, when billing or account security is involved, or when every fix requires production access you do not control. At that point, package the exact error, timestamp, project ID, reproduction steps, screenshots, and recent changes before asking support or another engineer. Good escalation notes often solve the problem faster than another hour of guessing.
Diagnostic flow
- Reproduce the issue once and write down the exact path. If you cannot reproduce it, collect more evidence before changing settings.
- Check scope: one user or everyone, one browser or all browsers, local only or production only, new content only or old content too.
- Check the last change first. Most troubleshooting work is not about finding a mysterious root cause; it is about identifying which recent change created the mismatch.
- Split the system in two: input vs output, local vs hosted, account vs project, source file vs generated file, prompt vs model. Test which side still fails.
- Apply the smallest reversible fix. Avoid changes that touch DNS, permissions, billing, deployment, and code at the same time.
- Verify the original reproduction path and one nearby path, then write down what fixed it.
Minimal reproduction template
Issue:
- [exact error or broken behavior]
Where it happens:
- URL / tool / project:
- Account:
- Environment: local / preview / production
- Browser / device:
Steps to reproduce:
1.
2.
3.
Expected:
-
Actual:
-
Recent changes:
- Code:
- Config:
- DNS / permissions / billing:
- Prompt / model / uploaded files:
Evidence:
- Screenshot:
- Console error:
- Server or platform log:False fixes to avoid
- Clearing cache without checking whether the underlying file, permission, route, or setting is correct.
- Reinstalling packages when the error is actually caused by environment variables, credentials, quota, or platform config.
- Changing several unrelated settings at once, then not knowing which one mattered.
- Copying a fix from another framework or platform without checking whether the routing, build output, or auth model is the same.
- Treating a temporary platform outage as your own bug before checking status pages and recent reports.