Crawled – Currently Not Indexed: What It Means and How to Fix It

“Crawled – currently not indexed” means Googlebot fetched your page, read it, and decided not to add it to the index.

It is not an error. Nothing is broken, no penalty has been applied, and no setting is misconfigured. Google looked at the page and judged it not worth storing.

That judgement is what makes the status frustrating. There is no error message to fix, so most advice defaults to “improve your content quality” — which is true sometimes and useless the rest of the time.

This guide works differently. It walks through the 51 URLs sitting in this status on technoxprt.com, the site you are reading, sorted by what they actually are. The breakdown changes what the fix should be.

The short version

  • It is a judgement, not an error. Google read the page and decided against storing it.
  • Check what the URLs actually are first. On a real site, more than half were feeds, pagination and script files.
  • Fix those technically, not editorially. No writing will index a JavaScript file.
  • If the URLs say “Last crawled: N/A”, you have a different problem — see the Discovered section below.

What the Status Actually Means

Google’s indexing pipeline has three separate stages, and the report names tell you exactly where a URL stopped.

  • Discovery. Google learns the URL exists, usually from your sitemap or a link.
  • Crawling. Googlebot requests the page and downloads it.
  • Indexing. Google processes what it downloaded and decides whether to store it.

“Crawled – currently not indexed” means stages one and two completed and stage three did not. Google has your content. It chose not to keep it.

The word “currently” is doing real work in that phrase. The status is not permanent, and pages move out of it without any intervention. They also move back in.

What it is not

It is not a manual action. Manual actions appear in their own Search Console report and come with a notification.

It is not a crawl block either. A blocked page would show as “Blocked by robots.txt” or would never be crawled at all.

And it is not always about the individual page. Google indexes at the level of a site as much as a page, and a page can be declined because of the company it keeps.


Crawled vs Discovered: Two Different Problems

Search Console has a second status that sounds similar and means something almost opposite.

StatusWhat happenedWhat it signals
Crawled – currently not indexedGoogle fetched the page and declined itA judgement about the page
Discovered – currently not indexedGoogle knows the URL exists but has never fetched itA shortage of crawl resource

The difference matters because the fixes are unrelated. Rewriting a page that Google has never read cannot help, and building crawl capacity does nothing for a page Google already rejected.

Check which list a URL sits in before you touch it. In Search Console the “Last crawled” column settles it: a real date means crawled, and “N/A” means Google has not been there.


What 51 Real URLs Look Like

Here is the current “Crawled – currently not indexed” list on technoxprt.com, a 179-page WordPress blog. The status was first detected in August 2022 and has hovered around 50 URLs since.

Sorted by what the URLs actually are:

Type of URLCount
Articles23
Paginated archives (/page/2/, /page/6/)10
RSS feeds (/category/feed/)6
Location pages on a subfolder microsite4
Web Stories3
Author archives3
JavaScript files2

28 of the 51 are not articles at all. They are pagination, RSS feeds, author archives and, in two cases, WordPress’s emoji script — /wp-includes/js/wp-emoji-release.min.js, listed twice under two different version strings.

No amount of content improvement will index a JavaScript file. Google is behaving correctly on more than half this list.

The 23 that are articles

Sorting those by hand turns up four groups, and only one of them is a content-quality problem.

  • Boilerplate pages. The disclaimer and privacy policy. Every site has them, nobody searches for them, and Google skipping them costs nothing.
  • Dated news. Posts about the Penguin 4.0 rollout, Google dropping DMOZ from snippets, a 2016 search advertising trends piece. Accurate when written, worthless now.
  • Off-topic legacy content. A post about a device that evaluates fruit ripeness, on an SEO blog. Genuinely off-niche and unlikely to ever earn a place.
  • A URL with no slug. /2102/ — a bare post ID, from an old permalink structure that was never redirected.

There is also a near-duplicate: an article called “10 Ways to Write Content That Is SEO Friendly” and a Web Story called “10 Best Ways to Write SEO Friendly Content”. Two URLs, one idea, and Google picked neither.

After removing those groups, the number of genuinely good pages Google has read and rejected is small — a handful, not 51.


What That Breakdown Changes

The standard advice for this status is to improve content quality and rebuild internal links. On this site that advice would have been aimed at the wrong 28 URLs.

The realistic actions here are different in kind:

  • Feeds, pagination and author archives should carry noindex or be removed from the sitemap. They are not content and were never meant to compete.
  • Boilerplate pages need nothing. Leave them.
  • Dated news and off-topic posts get updated, merged into something current, or removed with a redirect to the closest relevant page.
  • The bare-ID URL is a redirect job, not a writing job.

Only the last handful are a content question at all. Reading the list before acting on it saved weeks of pointless rewriting.

Run this categorisation on your own list before you change anything. Export the URLs from Search Console and sort them by pattern — /feed/, /page/, /author/, file extensions — and the shape of the real problem appears quickly.


The Mirror Problem: Discovered – Currently Not Indexed

The same site has 36 URLs in the “Discovered” bucket, and that list looks nothing like the first one.

Twenty-four are blog posts. All twenty-four are current, on-topic SEO articles: ecommerce SEO, Cloudflare SEO, security headers, an SEO proposal template, a Screaming Frog comparison, AI search statistics. The remaining twelve are location pages on the site’s microsite.

Every one of them shows “Last crawled: N/A”. Google knows they exist and has never fetched a single one.

So the two lists are exact opposites. The crawled list is mostly junk Google was right to skip. The discovered list is the site’s best current work, unread.

Why the discovered list is the more serious one

Crawl budget is not distributed evenly across the web. Google allocates it based on how much it trusts a site, and trust is built substantially on links from other sites.

This site has four referring domains that Google counts. That is not enough to earn the crawl attention that would clear a 36-URL backlog.

Which means the fix for that list is not on the pages themselves. It sits in link building and internal linking — giving Google both a reason and a route to visit.


Why Google Declines a Page It Has Read

When a page really is good content and still sits in the crawled bucket, these are the causes worth checking, in the order they are worth checking.

1. The page duplicates something else

Not plagiarism — overlap. Two posts covering the same question, or an article and a Web Story built from the same outline.

Google picks one URL per idea. If two of yours compete, it may decline both rather than choose.

2. Nothing links to it

A page reachable only from the sitemap reads as unimportant. Internal links are how you say otherwise.

Crawl your own site and list pages with zero incoming internal links. Screaming Frog does this in its free tier for sites under 500 URLs.

3. The page adds nothing to what is already ranking

This is the real “quality” cause, and it is narrower than it sounds. The question is not whether the page is well written — it is whether it contains anything the indexed results do not.

A page that restates the top three results has no reason to exist in the index alongside them.

4. The site is new or thinly linked

Google is cautious with sites it has little history with. Pages from those sites sit in this status longer, and there is no page-level fix for it.

5. The page is not really an article

Covered above, and worth repeating because it is the largest group in real data. Tag archives, feeds, pagination, attachment pages and script files all end up here.


A Diagnostic Order That Works

Work through this before changing any content.

  • Export the list. Search Console → Pages → Crawled – currently not indexed → Export.
  • Sort by URL pattern. Separate genuine articles from feeds, pagination, archives and files.
  • Handle the non-articles technically. noindex, sitemap removal, or nothing at all. No writing required.
  • Check the remaining articles for duplication. Search your own site for the topic and see what else covers it.
  • Check internal links. Anything with zero incoming links gets links from relevant posts, in the body text, not a sidebar.
  • Then judge the content, and only then. By this point the list is usually short enough to review by hand.

The order matters because the technical steps remove most of the list, and what remains is a manageable content decision rather than an intimidating one.


When the Report Itself Is Out of Date

Before you act on a URL, check whether the report is still describing reality.

The Page indexing report is a snapshot, not a live view. At the time of writing, the report on this site carries a “Last update” date three days behind the current date — normal, and enough for a page indexed this week to still be listed as not indexed.

So a URL can appear in this status and already be in the index.

How to check a single URL properly

Paste it into the URL Inspection tool at the top of Search Console, then click “Test live URL”. That queries Google directly rather than reading the cached report.

If the live test says the URL is on Google, the report is simply behind and there is nothing to fix.

Do not use a site: search for this. It is an approximation and it disagrees with Search Console often enough to be misleading.

Tracking a group of URLs

Inspecting URLs one at a time does not scale past a handful. For a larger set, put the affected URLs into their own sitemap file and submit it separately.

Search Console reports indexing coverage per sitemap. A dedicated sitemap turns a scattered list into a single number you can watch move.

It changes nothing about how Google treats the pages. It is purely a measurement device, and it can be removed once the work is done.


What Does Not Help

Some of the most common responses to this status make no difference, and a few make things worse.

  • Requesting indexing repeatedly. One request is reasonable. Repeating it does not raise your priority.
  • Resubmitting the sitemap daily. Google re-reads sitemaps on its own schedule.
  • Adding words to hit a length target. Padding a thin page makes it a longer thin page.
  • Indexing services that ping third-party sites. These typically generate the kind of low-quality links that create a separate problem.
  • Changing the permalink to force a re-crawl. This creates a new URL and orphans the old one.

How Long It Takes

There is no fixed timeline, and anyone offering one is guessing. What can be said is what the pattern usually looks like.

A technical fix — adding noindex to feeds, redirecting a stale URL — reflects in the report within a few weeks, as Google re-crawls those URLs.

A content or internal-linking fix takes longer, because Google has to re-crawl, re-evaluate, and then act. Two to three months is normal.

A crawl-budget problem is the slowest of all, because it is not solved by a change you make to a page. It improves as the site earns more links, and that is measured in quarters.

Track the count in the report rather than checking individual URLs. The trend line tells you whether the work is landing; a single URL tells you almost nothing.


Frequently Asked Questions

Is “Crawled – currently not indexed” a penalty?

No. Penalties appear as manual actions in their own Search Console report and come with a notification. This status is an ordinary indexing decision, applied automatically, and it reverses on its own regularly.

How many URLs in this status is normal?

There is no threshold, because the number depends entirely on what the URLs are. A site with 200 pages and 50 in this status is fine if 40 of them are feeds and pagination. Ten would be a concern if all ten were your best articles.

What is the difference between “Crawled” and “Discovered – currently not indexed”?

Crawled means Google fetched the page and decided against indexing it. Discovered means Google knows the URL exists but has never fetched it. Check the “Last crawled” column: a date means crawled, “N/A” means discovered only.

Will requesting indexing in Search Console fix it?

Sometimes, for a page that was declined for a temporary reason. It will not work on a page Google has judged unnecessary, and repeated requests for the same URL do not increase its chances.

Do RSS feeds and paginated archives belong in this report?

They frequently appear there, and it is not a problem. Those URLs are not content and are not meant to rank. Adding noindex or removing them from your sitemap keeps the report readable, but leaving them alone causes no harm.

Can this status affect pages that are already indexed?

Indirectly. Google assesses sites as a whole, so a large volume of low-value indexed pages can make it more cautious about the rest of the site. This is a reason to prune stale content, not to panic about the report count.

Should I delete pages that stay in this status?

Only if they have no purpose. Dated news, off-topic legacy posts and duplicates are worth removing with a redirect to the closest relevant page. Pages that serve readers should stay indexed or not, on their own merits.

Does site speed cause this status?

Rarely on its own. Speed affects how much Google crawls, which shows up as “Discovered – currently not indexed”. A page that was crawled successfully was fast enough to be read.

Sandeep
Sandeep
Sandeep has worked in search engine optimisation for ten years, across technical SEO, content strategy, local search and the tools the job actually runs on. He writes and edits everything on Techno Xprt. His approach here is deliberately unglamorous: check the vendor's own pricing page rather than a roundup, confirm a feature still exists before recommending it, and go back and correct a post when the facts move. A large part of the work on this site has been exactly that, finding advice that quietly went out of date and fixing it. He writes for people doing the work themselves, small business owners and in-house marketers, rather than for other SEOs.
Recent Articles

Related Stories