Crawled - Currently Not Indexed: How to Tell a Real Problem From a Normal One

"Crawled - currently not indexed" is the Search Console status that means Google fetched your page, looked at it, and chose not to store it. It sits in the Page indexing report under the list of reasons pages are not indexed, and it is the one that generates the most panic per affected URL. If you opened that report this morning, saw a count sitting beside this status, and could not tell whether it signals a broken site or an ordinary week, that is the question answered below.

What follows is a gate for deciding whether to act at all, the one question that separates this status from the one it gets confused with, the causes ordered by how often they turn out to be the answer, and the fix order.

The short version

• Most of the time, nothing is broken. The page was fetched and then held out of the index for now, which is a judgment rather than an error.
• Google's documentation says explicitly that there is no need to resubmit the URL for crawling. Hitting Request Indexing again is the action most likely to waste your afternoon.
• Plumbing failures report elsewhere. A noindex, a robots.txt block, a canonical conflict, and a server error each get their own status, so this one points at the page itself.
• "Discovered" and "Crawled" are different problems with different fixes, and one question tells them apart: did Google fetch the page or not?
• Run the gate before the fix list. On a small, young site, the correct action is often to publish something else and check back in a month.

What does "Crawled - currently not indexed" actually mean?

It means Google requested your URL, received a working page in response, and then kept that page out of the index. Google's Page indexing report documentation defines it in one line: "The page was crawled by Google but not indexed. It may or may not be indexed in the future; no need to resubmit this URL for crawling."

Read that sentence twice. It carries three things: a definition, a forecast that could go either way, and an instruction not to resubmit. The instruction is the one worth writing down.

The confusion underneath the panic is usually a collapsed mental model of three separate stages. Crawling is Google fetching the URL. Indexing is Google deciding the fetched page is worth storing. Ranking is Google deciding where a stored page belongs for a given query.

A page can clear the first stage and fail the second, and that is precisely what this status records. Nothing about it says anything about ranking, because the page never got far enough to be ranked. If the earlier stages are the part you are shaky on, our technical SEO guide walks through all three and the settings that govern each.

You will find this status in the Page indexing report, on the list of reasons a URL did not make it in. The count beside each reason is what people react to first, and on its own it tells you almost nothing. It only becomes a number worth reading once you set it against how many URLs the site has in total.

Is it a problem? Run this gate before you fix anything

Five questions, answered in order. Each one has a verdict attached, and if the first three all come back clean you have almost certainly found normal behavior rather than a defect.

1. What share of your URLs carry the status? Compare the count against your total indexable URLs, not against zero. A handful out of a few hundred is background noise on any site. A third of everything you publish is a pattern, and patterns have causes.
2. How old are the affected pages? Anything published in the last few weeks is still inside the window where Google is entitled to take its time. Pages that have carried the status for months, through several crawls of the rest of the site, are a different case.
3. Is the URL in your sitemap, and does anything on the site link to it? A page that is in the sitemap but has no inbound internal links is reachable but unendorsed. That is a common profile for this status, and it is the one thing on this list you can fix the same afternoon.
4. Would you defend this page to a person? Not to Google. To a colleague who asks what it is for. Tag archives, thin location variants, paginated fragments, and pages written to occupy a keyword rather than answer it are the honest answers to this question, and the honest answer is often no.
5. Does the page repeat something you already published? If two of your own pages cover the same ground, Google indexing only one of them is the system working. The fix is an editorial decision about which page should exist, not a technical one.

The verdict rule: if questions one to three are clean and questions four and five make you uncomfortable, you have a content problem. If question three is the one that fails, you have a linking problem. If question one fails at scale, you have a template or an architecture problem. If nothing fails, you have a waiting problem, and waiting is the work.

How is it different from "Discovered - currently not indexed"?

One question separates them: has Google fetched the page at all? Google's documentation defines the other status as "The page was found by Google, but not crawled yet. Typically, Google wanted to crawl the URL but this was expected to overload the site; therefore Google rescheduled the crawl."

So "Discovered" is a crawl-scheduling outcome and "Crawled" is an indexing decision. They sit at different stages, they have different causes, and the advice for one is close to useless for the other. Sites hitting "Discovered" at volume are usually large, slow, or generating URLs faster than they can be fetched, which is the territory of crawl budget. Sites hitting "Crawled - currently not indexed" are usually publishing pages that do not yet earn the storage.

These four statuses are the ones readers confuse with each other, and a single question separates each pair.

Status	What actually happened	The question that identifies it
Crawled - currently not indexed	The page was retrieved in full, then held back from storage	Does URL Inspection show a last crawl date?
Discovered - currently not indexed	The URL is on Google's list, but no fetch has happened yet	Is the last crawl date empty?
URL marked 'noindex'	You told Google to keep the page out	Does the page serve a noindex directive?
Duplicate, Google chose different canonical than user	Google folded the page into another URL	Does the Google-selected canonical differ from yours?

If you are reading this because a number went up in the Page indexing report, check the last crawl date on two or three affected URLs before you read any further. It costs a minute and it decides which half of this article applies to you.

How long should you wait before treating it as a problem?

Longer than feels comfortable, and there is no single number worth quoting. Google's URL Inspection tool documentation says only that "Indexing typically takes only a day or so, but can take much longer in some cases," which is deliberately loose because the honest answer depends on the site.

What is worth knowing is that a new page and an edited page are on completely different clocks, and conflating the two produces a lot of false alarms.

On a property we run, as of September 2026, posts published that week showed a last crawl date on the same day they went live. Edits to pages that were already indexed behaved nothing like that: one page edited in late August had still not been refetched more than two weeks later, and it was sitting happily in the index the entire time on its older version. Publishing gets attention. Republishing waits in a much longer queue.

What restarts the clock: a genuine change to the page's URL, a change to its canonical, or a redesign that changes what the crawler receives. Changing a paragraph and republishing does not restart anything; it just queues a recrawl that may take weeks to arrive.

From my experience working on indexing problems, the useful threshold is not a number of days but a comparison. If Google has crawled other pages on your site since the one you are worried about was published, and still has not indexed it, the delay is a decision rather than a backlog. That is when it becomes worth diagnosing.

Which causes actually produce this status?

Four causes account for most of what we find, and they are not equally likely. The order below is roughly how often each turns out to be the answer, which makes it a useful order to check them in.

Cause	What it looks like in the report	How to confirm it
The page does not earn its slot	Scattered individual URLs, often the newest content	Read the page against the query it targets. Does it answer more completely than what currently ranks?
Nothing links to the page	Sitemap-only URLs, often older and forgotten	Check inbound internal links. Zero is the signal.
Templated pages at scale	Large blocks of URLs sharing a path pattern	Open three of them side by side. How much text differs?
Near-duplicates of your own pages	Pairs or clusters covering the same query	Search your own site for the target query and count the candidates.

The second cause is the one most worth checking first, because it is the cheapest to fix and the easiest to prove. A page with no inbound links is an orphan page, and Google's willingness to index it is being asked to rest entirely on a sitemap entry. Google's sitemap documentation is direct about the limit of that: a sitemap "helps search engines discover URLs on your site, but it doesn't guarantee that all the items in your sitemap will be crawled and indexed." Discovery is not endorsement.

A caution on the first cause: Google does not say this status means your content is low quality. The documentation describes a decision that "may or may not" go your way later, and stops there. What the status genuinely tells you is that the page did not clear the bar on the day it was crawled. That is compatible with low quality, and it is equally compatible with a perfectly good page on a site with no authority yet.

Which causes do NOT produce this status?

Several of the things people fix first cannot produce this status at all, because each of them reports under its own name. Fixing one of these because a page is crawled and not indexed is work that cannot possibly help.

• A robots.txt block: a blocked URL cannot be crawled, so it reports as "URL blocked by robots.txt" instead. The status you are looking at proves Google fetched the page.
• A noindex directive: a page deliberately excluded with noindex reports under the noindex exclusion. If you are seeing this status instead, the directive is not what is stopping indexation.
• A canonical conflict: when Google picks a different canonical, it says so, under a duplicate status that names the URL it chose instead.
• Server errors and redirects: 5xx responses, soft 404s and redirect chains all have their own rows in the report. A page that returned an error was not crawled successfully.

Confirm this on the URL itself rather than from the report summary. Open URL Inspection on one affected page and read the indexing allowed state, the robots.txt state, and the Google-selected canonical. If all three look normal, every item on the list above is eliminated in about thirty seconds.

What is the fix order?

Cheapest and most reversible first. Each step below names the evidence that tells you it worked, because the temptation with indexing work is to do all four at once and learn nothing.

Step 1. Decide whether the page should exist: for templated pages, thin variants, and near-duplicates, the correct fix is consolidation or removal, not promotion. Merge the page into the stronger version and redirect it, or noindex it deliberately so the report stops counting it as a problem. Evidence it worked: the URL leaves this status and appears under a status you chose.

Step 2. Give the page real inbound links: two or three contextual links from pages that are already indexed, placed inside sentences rather than in a related-posts block. Our guide to internal linking covers how to choose the source pages. This is the highest-yield step for most sites and it is entirely within your control. Evidence it worked: a fresh last crawl date within a few weeks, followed by a status change.

Step 3. Make the page answer the query more completely: not longer. More complete. Find the subjects a full answer to the target query covers and add the ones your page skips, then cut whatever was padding. Evidence it worked: the page is recrawled and indexed, or it is indexed and starts collecting impressions for the query.

Step 4. Fix the pattern, not the page: if a whole URL pattern is affected, editing individual pages is a treadmill. Change the template, reduce the number of URLs it generates, or stop generating the thin ones. Evidence it worked: the count against this status stops growing week over week.

None of these is guaranteed. Indexing is Google's decision and the documentation is careful to keep it that way. What the order does guarantee is that you learn which lever moved the page, which matters more than the individual page does.

What does not work?

Four things absorb an enormous amount of effort and change nothing.

Pressing Request Indexing repeatedly: Google's own instruction for this status is that there is no need to resubmit the URL, and the URL Inspection documentation adds that "Submitting a request does not guarantee that the page will appear in the Google Index." There is a daily submission limit, so the practical effect of hammering the button is that you spend your quota and still hold the same page.

Resubmitting the sitemap: resubmission tells Google where your URLs are, which it already knew, since the URLs are in this report precisely because it found and fetched them. A sitemap helps discovery. This status is past discovery.

Buying an indexing service: Google declines to promise indexing even for the submission tool it built itself, so a guaranteed outcome is the part of the pitch to interrogate. Ask which mechanism the service actually uses, and what it does when Google ignores that mechanism. The decision belongs to Google either way.

Adding words for the sake of a word count: padding a page that already failed to earn its slot makes it a longer page that fails to earn its slot. If you cannot name the subject you are adding and why a reader needs it, the edit is not an improvement.

How do you confirm the page actually got indexed?

With URL Inspection. Three fields there carry the verdict, and the two shortcuts people reach for instead are each weaker than they look.

• Coverage state: this is the verdict. "Submitted and indexed" or "Indexed, not submitted in sitemap" both mean the page is in. Anything else means it is not.
• Last crawl date: this tells you which version Google is holding. Google's documentation is explicit that the tool shows the indexed version, not a live fetch, so a crawl date older than your last edit means Google has not seen your change yet.
• Google-selected canonical: if it differs from yours, the page is not indexed under its own address, whatever else the report says.

What the shortcuts are worth: a URL appearing in your sitemap says only that you listed it. A site: query on one exact address is a legitimate quick look, and Google's Page indexing report guidance offers it first to sites with fewer than 500 pages. What it will not give you is the reason, the crawl date, or the canonical Google picked, which is why that same guidance says the report "isn't used to investigate the index status of specific pages" and sends you to URL Inspection for exactly that job.

What is the habit that prevents most of this?

Check the Page indexing report on a cadence rather than in a panic. Once a month, on a calendar entry, with the previous month's counts written down somewhere you can compare against. The number that matters is the direction of travel, not the absolute count, and you cannot see direction from a single alarmed visit.

The second half of the habit is publishing with the link already in place. A new page that ships with two contextual inbound links from indexed pages starts in a materially better position than one that ships into a sitemap and waits to be noticed. That is a five-minute step at publish time and it removes the most common cause on the list above before it happens.

This week, open URL Inspection on the three pages you most want to rank, and write down the last crawl date for each. If any of those dates predate your last meaningful edit to that page, you have found something more actionable than the report count ever gives you. If you would rather have someone run the full diagnosis across the site, this is the kind of work that sits inside how we run technical SEO.