Crawled – Currently Not Indexed: How I Fixed My Stuck Pages

“Crawled – currently not indexed” means Google visited your page, read it, and decided it was not worth adding to the index. It is not a crawling error, not a robots.txt problem, and not something you fix by resubmitting the URL. It is a verdict on value.

I learned that the hard way. In mid-2026 I opened the Page Indexing report in Google Search Console for byskh.com and found the majority of my published posts sitting under that one status line. Crawled. Read. Passed over.

My first instinct was the wrong one. I hit “Request Indexing” on a dozen URLs, waited a week, and watched every single one bounce back into the same bucket.

This post is what I did after that — the diagnosis, the uncomfortable conclusion, and the specific changes I made. If you are publishing consistently and still watching pages pile up in this report, the pattern I found will probably look familiar.

Key Takeaways on Crawled – Currently Not Indexed

• It is a quality signal, not a technical bug. One analysis of 1.7 million pages across 18 websites attributed roughly 88% of not-indexed pages to quality issues rather than technical faults.
• Non-indexing is now the norm, not the exception. A study of 16 million pages found that about 62% sat in a “page not indexed” state while only ~37% were fully indexed.
• Volume works against you. Google confirmed in 2026 that mass “crawled – currently not indexed” can indicate site-wide quality doubt, with undifferentiated AI content named explicitly.
• Requesting indexing does nothing if the underlying page has not changed. You are asking for a re-vote with the same ballot.
• Deleting and merging often beats publishing more. Consolidation concentrates signals that near-duplicate pages were splitting between themselves.
• Crawl depth matters. Pages more than three clicks from the homepage get crawled less often and indexed more slowly.
• Recovery is not instant. In my experience, meaningful movement took four to eight weeks after the changes, not days.

What “Crawled – Currently Not Indexed” Actually Means

The status sits in the “Not indexed” section of the Page Indexing report. It tells you Googlebot successfully fetched the URL, rendered it, evaluated it, and then declined to store it in the search index.

That is the crucial distinction. The page is reachable. Nothing is broken. Google simply did not think the result justified a slot in the index.

John Mueller has been consistent on this point for years, noting that crawling something does not automatically mean it will be indexed. Crawling is discovery; indexing is a separate, selective judgement made afterwards.

How it differs from “Discovered – currently not indexed”

People confuse these two constantly, and the fix for each is different.

Discovered – currently not indexed means Google knows the URL exists but has not fetched it yet. That usually points at crawl capacity, server response times, or a weak discovery path.

Crawled – currently not indexed means it already read the page and said no. That points at the content itself.

If you are stuck at the discovery stage instead, my post on getting indexed by Google fast covers the sitemap, internal link, and server-side work that moves URLs out of the queue.

Why Google Got So Much Pickier in 2026

The bar moved. That is the honest short answer, and it explains why pages that would have been indexed automatically a few years ago now get filtered out.

Google’s March 2024 spam policy update and a further enforcement refinement in March 2026 made the system considerably more aggressive about screening low-value pages before they reach the index. Pages that once passed by default are now actively reviewed and rejected.

The driver is supply. Generative tools let anyone produce publishable text at essentially zero marginal cost, so Google sees vastly more URLs than before while its index capacity stays finite. It crawls more than it indexes on purpose, to conserve resources.

On 16 July 2026, Mueller and Martin Splitt publicly confirmed that widespread “crawled – currently not indexed” can reflect site-wide quality doubts, and they named undifferentiated AI-generated content as a live example of what triggers it.

That last detail is the part most people skip past. The status is frequently not about the individual page you are looking at. It is about the pattern your whole domain establishes.

There is some good news buried in the data. Search Engine Journal reported that indexing rates have been improving across tracked datasets, so the door is not closed — the criteria simply got stricter.

How I Diagnosed My Own Stuck Pages

Here is the process I actually ran, in order. It took about two evenings, and the answer was not the one I wanted.

Step one: export everything and count

I pulled the full URL list from the Page Indexing report and put it in a spreadsheet next to publish date, word count, category, and number of internal links pointing in.

Do this before you form a theory. I had assumed my oldest posts were the problem. They were not — my newest ones were, because I had been publishing daily and the recent batch was the thinnest.

Step two: look for clusters, not pages

Sorting by category exposed the real issue immediately. I had five separate posts on affiliate networks, three on web hosting, and three on low-code platforms.

Each cluster targeted essentially the same query intent. That is textbook keyword cannibalisation, and the consequence is well documented: when two of your pages chase one intent, they split the signals that would otherwise concentrate on a single strong page.

Google does not need five near-identical takes from one mid-authority site. It indexes one, maybe, and quietly discards the rest.

Step three: read the pages as a stranger would

This was the uncomfortable part. I opened ten stuck posts and asked one question of each: what is in here that is not already on the first page of results for this query?

For six of them, the honest answer was nothing. No original data, no worked example, no first-hand account, no contrarian read. Competent, readable, and completely replaceable.

Thin content is repeatedly cited as the single most common cause of this status, and “thin” does not only mean short. A 2,000-word post that restates the consensus is thin in the way that matters.

Step four: check crawl depth and orphan status

I crawled my own site and mapped how many clicks each stuck URL sat from the homepage. Several were four or five deep with a single inbound internal link.

That compounds the problem. Pages within about three clicks of the homepage get priority crawling, while deeply nested URLs are fetched less often and indexed more slowly.

True orphan pages are worse still — with no inbound internal link, the only discovery route is your XML sitemap, and a sitemap is a weaker signal than the link graph itself.

The Fixes That Actually Moved Pages Into the Index

I want to be careful here, because SEO advice tends to overpromise. These are the changes I made and what I observed afterwards, not a guarantee.

Fix one: merge the cannibalised clusters

I took the five affiliate-network posts and rebuilt the strongest one into a genuinely comprehensive guide, folding in the unique sections from the other four. The remainder were redirected into it with 301s.

This is the highest-leverage move available to most small sites, and the case-study evidence supports it. One agency documented a 32% traffic increase from a structured pruning programme, and another reported a client going from roughly 3,000 to 10,000 monthly visits after pruning 400 low-quality pages.

An ecommerce pruning case study from Inflow makes the same underlying point from the commercial side: removing weak pages concentrated performance in the pages that mattered.

Counterintuitive as it feels, deleting your own work is often the fastest route to getting the survivors indexed.

Fix two: add something only I could add

For posts worth keeping, I rewrote with one constraint: every article had to contain at least one thing that could not be copied from another site.

Usually that meant my own numbers, a specific failure, a screenshot of my actual dashboard, or a process I run personally. Google’s own guidance on creating helpful content is blunt about this — it asks whether your page provides original information, reporting, or analysis beyond the obvious.

If you cannot answer that question about a page, no amount of reindexing requests will save it. My content decay and refresh system covers the mechanics of doing this at scale across an existing archive.

Fix three: cut publishing frequency, hard

I went from daily to twice a week. This was the change I resisted longest and the one I now think mattered most.

The logic follows directly from what Google confirmed in July 2026: if a steady stream of undifferentiated posts is what teaches the algorithm to doubt your site, then slowing that stream is not a compromise, it is the treatment.

Fewer, stronger pages also let me put real internal-linking effort behind each one instead of spraying links thinly across an ever-growing archive.

Fix four: rebuild the internal link graph

I made sure every post I cared about had at least three contextual internal links pointing at it from related articles, and that nothing important sat more than three clicks from the homepage.

Internal links do double duty here. They create discovery paths for crawlers, and they signal which of your pages you consider important — a signal Google demonstrably uses when allocating limited index space.

If you want the structural version of this, my internal linking strategy guide lays out the hub-and-spoke pattern I use, and the pillar-cluster playbook covers how to organise a topic so the cluster reinforces itself.

Fix five: stop requesting indexing on unchanged pages

The URL Inspection tool’s “Request Indexing” button is not a vote of confidence you can spend. It re-queues a crawl.

If the page is materially the same as the one Google already rejected, you are asking the same question and will get the same answer. I only use it now after a substantive rewrite — and even then I treat it as a nudge, not a fix.

What Does Not Fix This Status

Plenty of common advice is either irrelevant or actively wasted effort here. Worth naming it.

Crawl budget optimisation. Mueller has said plainly that for most normal websites, crawl budget is not something you need to focus on. It becomes relevant at roughly a million-plus URLs, or 10,000+ pages changing daily. For a typical blog, what looks like a crawl budget problem is a content quality or internal linking problem wearing a disguise.

Resubmitting your sitemap. Google already has your sitemap. Sending it again does not change its assessment of the content.

Padding word count. Adding 800 words of filler to a thin post makes it a longer thin post. Depth is about substance per paragraph, not total length.

Buying indexing services. Anything promising to force pages into the index is either exploiting a temporary loophole or doing nothing. Neither is a foundation.

How Long Recovery Takes

Longer than you would like. Google has to re-crawl the changed pages, re-evaluate them, and in the case of site-wide quality signals, re-evaluate the domain’s overall pattern.

In my case, the first URLs moved into “Indexed” about four weeks after the merges and rewrites went live. The broader shift took closer to two months. Consolidation studies commonly report ranking movement in a 45- to 60-day window, which lines up with what I saw.

Resist the urge to change everything again at week two. You will have no idea what worked.

What to watch while you wait

Track the raw count of URLs in each Page Indexing status weekly, not daily. Daily numbers are noise.

Watch for pages moving between statuses as well as out of them. A URL shifting from “crawled – currently not indexed” to “indexed” is the win, but movement in the other direction on a page you did not touch tells you the site-wide signal is still weak.

Summary

“Crawled – currently not indexed” is Google telling you it read your page and was not persuaded. Treating it as a technical fault leads you into a loop of resubmissions that change nothing, because the input has not changed.

The diagnosis that worked for me was structural rather than page-by-page: find the clusters where my own pages competed with each other, be honest about which posts contained nothing original, and recognise that publishing frequency itself was feeding the problem.

The fixes were merging cannibalised posts, adding genuine first-hand substance to the survivors, cutting output from daily to twice weekly, and rebuilding internal links so important pages sat close to the homepage. Recovery took roughly four to eight weeks — slow, but real.

Frequently Asked Questions

Is “crawled – currently not indexed” a penalty?

No. It is not a manual action and it is not a penalty in any formal sense. It is an editorial decision by Google’s indexing systems that the page does not currently earn a place in the index. The distinction matters because penalties require a reconsideration request, while this status only requires you to make the page genuinely worth indexing and wait for a re-crawl.

How many pages in this status is normal?

Some is completely normal — tag archives, paginated pages, and thin utility URLs land here routinely and that is fine. The concern is proportion and identity. If a large share of your primary content pages are stuck, that is a site-level signal worth acting on. Given that one 16-million-page study found roughly 62% of tracked URLs unindexed, seeing a substantial number is not unusual, but seeing your best work there is.

Will republishing with a new date fix it?

Not on its own. Changing the published date without meaningfully changing the content is a cosmetic edit, and Google evaluates the content rather than the timestamp. A date change paired with a substantive rewrite is worth doing, because the rewrite is what earns the reconsideration. The date alone earns nothing.

Should I delete pages stuck in this status?

Delete or redirect them only when they are genuinely redundant — near-duplicates of a stronger page, or content you have no intention of improving. If a page targets an intent you care about and you can add real substance to it, improving it is better than removing it. When two of your pages chase the same query, merging them into one is almost always the right call.

Does AI-assisted writing cause this status?

Using AI is not itself the trigger; producing undifferentiated content at volume is. Google explicitly named undifferentiated AI-generated content as an example of what prompts site-wide quality doubt, which is a comment about sameness and scale rather than about the tool. An AI-assisted post carrying your own data, experience, and judgement is a different object from an AI-generated summary of page one.

Can internal links alone get a page indexed?

They help meaningfully but rarely suffice by themselves. Internal links create the discovery path and signal importance, which is why orphan pages struggle so badly. If the underlying content still offers nothing distinctive, however, better links just mean Google reaches the same conclusion sooner. Fix the substance, then fix the links.

The Takeaway

The hardest thing about this status is that the fix is rarely technical, and technical fixes are the comfortable ones. Merging posts you spent hours writing, and publishing less often when every instinct says publish more, both feel like going backwards.

They are not. Google indexes a smaller share of the web every year, and the pages that survive that filter are the ones carrying something the rest of the internet cannot supply. That is the whole game now.

Open your Page Indexing report, sort by the pages you actually care about, and ask the uncomfortable question about each one. The answer will tell you exactly what to do next.