Few Search Console states create more busywork than “Crawled - currently not indexed.” Teams export the list, submit hundreds of URLs for inspection, refresh titles, and wait. The status often returns. The backlog grows. Patience thins.
The status is not a bug in Search Console. It is Google saying: we saw this URL, and it did not clear the bar for indexing under current conditions. Your job is to learn why that bar was missed, and whether clearing it is even desirable for that URL class.
What the status does and does not mean
It means the URL was crawled. So robots.txt is probably not the blocker, and a hard server failure is less likely than for discovery problems. It does not mean the page is broken. It does not mean a penalty. It does not guarantee the page will be indexed if you press “Request indexing” enough times.
- Discovered - currently not indexed: Google knows the URL exists but has not crawled it yet or is choosing not to spend crawl there.
- Crawled - currently not indexed: crawl happened; index selection did not.
- Excluded by noindex: your directives are doing their job.
- Duplicate without user-selected canonical: consolidation logic is in play.
Mixing those states in one cleanup project creates noise. Segment first. This article focuses on the crawled-but-not-indexed bucket.
Segment the URL list before you fix anything
Export examples from Search Console and classify them by template. Category pages, product pages, blog posts, tag archives, location pages, faceted URLs, and paginated series behave differently. A single average “reason” across mixed templates will mislead you.
| Segment | First hypothesis | First check |
|---|---|---|
| Facet and parameter URLs | Low unique value; near-duplicates | Should these be noindexed by policy? |
| Thin location or tag pages | Scaled pages with little unique substance | Keep, merge, or remove via content audit |
| New blog posts | Quality or demand unclear; weak internal links | Compare to indexed peers in the same section |
| PDPs with sparse content | Thin specs, few reviews, weak uniqueness | Template quality and variant canonical rules |
| Older money pages | Lost internal links, outdated content, or duplication | Historical traffic, inlinks, and canonical target |
If most of the list is parameter waste, your problem is index bloat and crawl policy. If most of the list is pages you care about, your problem is quality, duplication, or internal discovery support. Those are different projects. For bloat measurement, see index bloat: find it and what it costs.
Quality and uniqueness checks that hold up
Open a sample of affected URLs as a user would. Ask whether the page offers a distinct result worth ranking. Soft-404 patterns, doorway-style location pages, tag archives that repeat the same posts, and PDPs with three lines of manufacturer copy often fail this sniff test.
Then compare each sample to its nearest indexed sibling. If Google already indexes a stronger category page covering the same intent, a weaker variant may stay crawled but unindexed. That can be correct behaviour. Your response may be consolidation, not coaxing both into the index.
Signals to capture per sample
- Word count is a weak proxy; note unique sections instead: specs, expert notes, FAQs, original media.
- Check whether main content appears in rendered HTML, not only in a client-side shell.
- Count meaningful internal links from relevant hubs.
- Note outbound usefulness: does the page help users complete a task?
- Record duplicate candidates: similar titles, near-identical bodies, overlapping intents.
Content decisions belong in a structured process. When the segment is editorial, run a content audit with keep, refresh, merge, or kill outcomes rather than endless title tweaks. Title rewrites alone rarely move a weak cohort into the index.
Technical causes that still show up
Quality is the common story, but technical issues still contribute. Canonical tags pointing elsewhere, conflicting robots signals between HTML and HTTP headers, alternate page versions, and render failures can leave a URL crawled yet unselected.
Collect indexation-relevant signals for one sample URL
URL="https://www.example.com/blog/sample-post/"
echo "=== Headers ==="
curl -sI "$URL" | egrep -i 'HTTP/|location:|x-robots-tag:|content-type:'
echo "=== Source signals ==="
curl -sL "$URL" | egrep -io '<link rel="canonical"[^>]*>|<meta[^>]*robots[^>]*>|<title>[^<]+</title>|<h1[^>]*>[^<]+' | head -n 20Compare those signals with URL Inspection. If the live page says indexable and unique, yet the status persists across many similar URLs, look at sitewide patterns: thin templates, duplicate clusters, or a section Google treats as low value. A focused technical SEO audit should map those patterns by template rather than arguing about one URL at a time.
When not indexing is the right outcome
Some URLs should stay out of the index. Faceted combinations, internal search results, thank-you pages, filtered sorts, and thin tags often create more harm indexed than excluded. If Search Console shows them as crawled and not indexed, celebrate the restraint and then enforce your policy so crawl budget is not wasted revisiting them forever.
Indexing every crawlable URL is not a goal. Indexing the URLs that deserve to compete is the goal.
Make the desired state explicit in your indexation policy. Add noindex or canonical rules where needed. Remove waste from sitemaps. Reduce internal link pathways that continuously rediscover junk. After that, the crawled-not-indexed count may stay high while your important pages become healthier. That trade can be a win.
A repair sequence for pages you do want indexed
For URLs that deserve to compete, work in this order.
- Confirm the page is indexable in headers and HTML with a consistent self-canonical.
- Improve unique substance and usefulness until it clearly beats near-duplicates.
- Strengthen internal links from relevant, already indexed hubs.
- Ensure the URL appears in an appropriate sitemap only after the above is true.
- Use URL Inspection sparingly on representative samples after changes, not as a bulk hammer.
- Re-check the template cohort two to six weeks later rather than judging one URL overnight.
If a whole money template is affected after a redesign, treat it as an incident. Compare staging versus production render, review release notes, and verify that critical content did not move behind interaction events. Migration and redesign cases often need the continuity checks in site migration pre-launch checks.
How to report progress without fake certainty
Stakeholders want the number to go to zero. It will not. Explain cohort health instead: “Of category templates we care about, 92% are indexed; the remaining 8% are thin seasonal pages we are merging.” That is an adult report. “We submitted 500 URLs” is activity, not progress.
Track indexed coverage for priority templates, organic landings for those templates, and the share of crawl waste still being rediscovered. Those metrics tell you whether diagnosis turned into repair. The Search Console state is an input to that story, not the scoreboard by itself.