Crawled Currently Not Indexed: Why It Happens and 9 Real Fixes

If you're staring at this status in Search Console right now, you're in the most common indexing situation on the modern web, and most advice about it is resubmission theater. This guide gives you the nine real causes I find on WordPress sites, ordered by how often they actually turn out to be the culprit across 100+ audits, each with its specific fix.

What does "crawled, currently not indexed" actually mean?

Google's indexing pipeline has stages: discover the URL, crawl it, render it, evaluate it, and finally index it. This status tells you your page cleared every stage except the last. Googlebot fetched the page successfully, processed what it found, and then made an active decision: not this one, or at least not yet.

That's the key mental shift. The page didn't fall through a crack; it was evaluated and declined. Google indexes a shrinking fraction of the web it crawls, because storage is finite and most pages add nothing the index doesn't already have. Your job isn't to nag the pipeline. It's to change the evaluation.

Is it a penalty?

No. Penalties (manual actions) live in their own Search Console report and come with a written notice. "Crawled, currently not indexed" is an algorithmic quality judgment about specific pages, not a punishment of your site, and plenty of perfectly healthy sites show some pages in this bucket permanently, by design. The status only signals a problem when the pages sitting in it are pages that matter: your services, your products, your best content.

Why does Google crawl a page but refuse to index it?

Because indexing is selective, and selection runs on a few repeated judgments:

• The page doesn't add enough. Thin content, near-duplicates of your own pages, or restatements of what a thousand indexed pages already say.
• The site's overall quality signals drag on it. Google evaluates pages partly through the reputation of the site around them. A site bloated with junk URLs lowers the bar for every real page on it.
• Internal signals say it's unimportant. No internal links, buried five clicks deep, absent from the sitemap: the site itself is telling Google the page doesn't matter.
• Conflicting technical signals. Canonical hints pointing elsewhere, parameter variants competing, redirect leftovers muddying which URL is the real one.

Every one of the nine fixes below maps back to changing one of those judgments.

How do you fix it? The 9 fixes, ranked by how often they're the real cause

This ordering is the part you won't find elsewhere: it reflects how frequently each cause turns out to be the actual culprit on the WordPress sites I audit, most common first. Work down the list and stop when your pages start moving.

1. Consolidate near-duplicate and overlapping pages. The number one cause. Five thin pages circling one topic get judged as noise; one strong page gets indexed. Merge them, 301 the extras, and keep the best URL.
2. Strengthen the thin pages that deserve to exist. If the page matters, make it obviously the better answer: real specifics, real depth, real usefulness. "Add more words" isn't the fix; add more answer.
3. Build internal links to the stranded pages. Link every not-indexed page from relevant, already-indexed pages with descriptive anchors. Pages with zero internal links are wearing a sign that says skip me.
4. Prune the index bloat around them. Noindex or remove the tag archives, attachment pages, and boilerplate URLs polluting your site's quality profile. Shrinking the junk raises the judgment of everything else; that's the site-wide effect covered in the crawl budget guide.
5. Resolve canonical and parameter conflicts. One page, one URL. Kill the www and non-www splits, parameter variants, and stray canonicals pointing the wrong way.
6. Fix the sitemap. Only real, indexable, canonical URLs belong in it. A sitemap full of redirects and noindexed pages teaches Google to distrust its recommendations.
7. Check the rendered page, not the source. Use URL Inspection's rendered HTML. If your theme or builder hides the main content behind JavaScript that fails for Googlebot, the "thin content" judgment is really a rendering problem.
8. Confirm no stray noindex history. A page that carried noindex for months gets deprioritized even after you remove the tag. Verify the current header and meta, then be patient with the recovery.
9. Then, and only then, request indexing. Once a cause is actually fixed, URL Inspection's Request Indexing genuinely helps Google re-evaluate sooner. As step one it's superstition; as step nine it's a nudge on a fixed page.

How long until fixed pages get indexed?

Once the real cause is removed, movement typically starts within days to a few weeks as Google recrawls and re-evaluates. It's rarely instant and rarely uniform: expect your strongest pages to enter first and stragglers to follow. What matters is the trend in the coverage report, checked weekly, not the daily refresh. Pages still frozen a month after a genuine fix usually mean a second cause from the list is still active, most often numbers 1, 3, or 4.

Crawled vs discovered, currently not indexed: which do you have?

They sound alike and mean opposite things. Crawled-not-indexed: Google read the page and declined it, a quality-side problem. Discovered-not-indexed: Google knows the URL exists but hasn't even fetched it, a crawl-side problem, usually budget or server related. The fixes barely overlap, so diagnose before treating: the discovered variant has its own guide, discovered currently not indexed.

When is "not indexed" actually correct?

Sometimes the report is showing you the system working. Tag archives, paginated comment pages, filtered duplicates, thank-you pages, thin utility pages: none of these should be in Google, and their appearance in the excluded bucket is a feature. The audit question is never "how do I index everything" but "are the pages that earn money indexed." Deliberately keeping junk out of the index is its own discipline, and pruning it is fix number four for a reason.