Crawled, Currently Not Indexed: What Google Saw and Why It Said No
By Ashikur Rahman18 min readQuick answer: "Crawled, currently not indexed" means Google fetched your page, read it, and decided not to index it. Google's own definition ends with "no need to resubmit this URL for crawling", so pressing Request Indexing again changes nothing: Google is not missing the page, it is declining it. A few URLs in this state is normal housekeeping. A whole page type is a template problem. A whole site with no manual action is a verdict on how the site was built and published. In July 2026 a site I own landed in the third case, and this article uses it to show what the verdict looked like from the inside, what I changed, and the part that has not recovered.
What Crawled, currently not indexed means in Google's words
Google's Search Console help page on the Page indexing report, read on 19 September 2026, gives the status one sentence: "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."
Every clause matters. "Crawled" means the fetch happened. "Not indexed" means that after reading the page, Google chose not to serve it. "May or may not be indexed in the future" means the decision is not final, but not pending either. And "no need to resubmit" is Google telling you that the thing most people do next cannot help.
The status people confuse it with is defined very differently: "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." There, Google has never read the page. Here, it has. That difference decides whether the problem is on the page or around it.
| Status | What Google has done | Where the fault can be | What resubmitting does |
|---|---|---|---|
| Discovered, currently not indexed | Knows the URL exists, has not fetched it | Crawl demand: links, importance, structure. Not the copy, which Google has not seen | Requests a fetch Google declined to schedule; sometimes works for one URL |
| Crawled, currently not indexed | Fetched the page, read it, declined it | The page, the page type it belongs to, or the site's overall pattern | Nothing. Google already has the page and said no |
| Duplicate without user-selected canonical | Fetched it and found a twin it prefers | Two URLs serving the same content, no canonical set | Nothing until the duplication is resolved |
If most of your excluded URLs sit in the first row, the right article is my earlier piece on what Discovered, currently not indexed means about your site, written after a directory I own lost 45 URLs to that status and exactly one to this one. The two statuses share a menu in Search Console and almost nothing else.
Why resubmitting the URL does nothing
Request Indexing asks Google to fetch a page again. For a page in this status, the fetch is the part that already succeeded. Another fetch puts the same HTML in front of the same evaluation, which returns the same answer. People do it ten times and conclude Google is slow. Google is consistent.
Validate Fix is the same thing at scale. The help page says "Validation typically takes up to about two weeks, but in some cases can take much longer, so please be patient." What the button's name implies, and the page never says, is that validation persuades anything. It re-reads. If the pages are unchanged it fails, and "Validation failed" becomes a second status people search for as if it were a new problem. It is the same problem, confirmed. The useful question is not how to get Google to look again. It is what Google saw the first time, and there are three shapes the answer takes.
The three shapes this status takes
Search Console does not tell you which shape you are in. The count and composition of the URL list do. Export it and sort it before you form a theory.
| Shape | What the list looks like | What it usually means | First move |
|---|---|---|---|
| A few URLs | A small share of the site, scattered: tag pages, thin utility pages, near-empty archives | Normal pruning. Google indexes a subset of every large site and these did not make the cut | Confirm each is a page you want indexed. If not, noindex or remove it. If yes, ask what it says that no other page says |
| One page type | Most URLs share a template: product, profile, location or programmatic pages | The template produces pages that differ in name only. Google read several and stopped indexing the type | Measure how much of each page is unique. Fix the template or merge the set, not the individual pages |
| The whole site | Nearly every URL, including pages that used to rank, with no manual action | A site-level verdict on the publishing pattern: velocity, sameness, sourcing, or claims | Stop publishing. Audit the pattern, not the prose. Consolidate and remove what cannot be evidenced |
The third shape is rare, and I can describe it from the owner's chair.
When a whole site sits at Crawled: a site I own that Google dropped
Around 21 July 2026, bestdogcarseat.com, an affiliate site I built, lost its Google indexing. Search Console showed no manual action and no security issue. Every URL sat at Crawled, currently not indexed, including pages that had been earning commissions the week before.
I ran the technical exclusion first, because ruling things out is cheaper than theorising. On 28 July 2026 I checked, live: robots.txt fully permissive, no noindex meta tag on any page, no X-Robots-Tag header on any response, every canonical self-referencing and correct, clean 200 responses to Googlebot's user agent, a sitemap returning 200 with 69 valid URLs. The last deploy had been on 10 July 2026, so a code regression could not explain a drop on 21 July. I also measured prose overlap between posts and got 5.1 percent average 8-gram overlap, which rules out the copy-paste duplication people assume when they hear "affiliate site". Google had read distinct text on every page and declined all of it anyway.
So the fault was pattern, not code and not duplication. Looking at the site the way Google would have, four things stood out.
| Signal | What my site showed | Google's published wording it maps to |
|---|---|---|
| Publishing velocity | 56 posts, 35 of them on three single days: 10 on 22 June, 10 on 1 July, 15 on 10 July, on a domain only weeks old | Content "mass-produced" so that "individual pages or sites don't get as much attention or care" (helpful content self-assessment) |
| Source of every fact | Every price, rating, review count and spec came from the Amazon catalog. No testing, no original photos, nothing that existed because I had done something | "Thin affiliation is the practice of publishing content with product affiliate links where the product descriptions and reviews are copied directly from the original merchant without any original content or added value" |
| Product recycling | 77 distinct products across 50 product posts. One product in 17 posts. 37 pairs of posts sharing 4 or more products | "Stitching or combining content from different web pages without adding value" (scaled content abuse examples) |
| Claims without evidence | Titles and bylines said "8 tested picks", "cab-tested", "tested-by-reviews", "vet-checked", "detailer-tested", "refreshed weekly via the Creators API". None was true | "Does the content have any easily-verified factual errors?" (self-assessment) |
None of those four is a technical error, which is why no technical audit found them. Each page, read alone, passed. Fifty-six of them built from one catalog, fifteen in a single day, decorated with testing claims nobody could back, look like a pattern. Google's spam policies define scaled content abuse as "when many pages are generated for the primary purpose of manipulating search rankings and not helping users", with "using generative AI tools or other similar tools to generate many pages without adding value for users" as the first example. I set out to publish fast, not to manipulate anything. From the outside, those look identical.
Google's helpful content page says its systems aim to "prioritize helpful, reliable information that's created to benefit people, and not content that's created to manipulate search engine rankings." Its self-assessment questions are not marketing. Read against my site, two failed outright: "Does the content provide original information, reporting, research, or analysis?" No. "Is the content mass-produced by or outsourced to a large number of creators, or spread across a large network of sites, so that individual pages or sites don't get as much attention or care?" Yes, by one person with a pipeline, which is the same thing.
Work with me
Which of the three shapes is your Search Console showing?
A handful of URLs at Crawled, currently not indexed is housekeeping. A whole page type is a template problem. An entire site is a verdict on the publishing pattern, and each of those needs a different first move. The export tells you which one you have within an hour, but only if someone reads the dates, the heading structures and the source of every fact on the page rather than the word counts.
Send me the Page indexing export and three URLs from the not indexed list. I will tell you which shape it is, whether the fix is a rewrite, a consolidation or a wait, and what I would not touch. I have done this on a site of my own that Google dropped, and I publish what happened to it, including the part where it has not come back yet.
Ashikur Rahman
SEO and AI Search Specialist
The contact links above go to me directly, so I earn from it if you hire me. Nothing else on this page is a paid placement.
How to read your own footprint before you rewrite anything
The instinct when a page is declined is to improve the page. For the second and third shapes that is the wrong unit of work. The verdict was on the set, so the audit has to be on the set. Four checks, in the order I now run them.
Publishing dates, by day. Count posts per calendar day. Two or three a week is a flat line. Ten or fifteen in a day is a spike, and spikes on a young domain are the loudest signal in the table above. If you built a pipeline like the one in my piece on publishing fifty posts with Claude Code, the architecture is still sound; the release schedule is what has to change.
Template similarity, with names removed. Take the heading structure of ten pages of one type, strip the product or place names, and compare what is left. If only the nouns change, the type is templated in the way Google reads as thin, whatever the word count. Then measure prose overlap with 8-gram shingles. Mine was 5.1 percent, which cleared me of duplication and left the pattern charge standing.
Where every fact came from. Mark each fact on one page by source: catalog, manufacturer, another article, or something you did. If the last column is empty, the page cannot pass "original information, reporting, research, or analysis" because there is none. Every number on my site had come from Amazon. The pages were accurate and contained nothing that would not exist without me.
Claims you cannot evidence. Search the site for "tested", "hands-on", "vet-approved", "expert-reviewed" and every hyphenated variant; a naive pattern on my site missed "cab-tested". Every hit is backed by something you can show or it is a fabrication. Delete them. It is the one fix that costs nothing and helps immediately, whatever Google decides.
Then look at what Google did surface. My own Generative AI report on this site showed question-format titles and comparison pages carrying almost all the AI impressions, with length not the lever. The pages Google shows describe what it finds useful from you; the pages it declines are the negative of that image.
Thin pages and thin information are not the same problem
Word count is the most common false fix. In August 2026 a second site I own, a medical directory, lost most of its indexing, and its profile pages were 1,199 words each. No checker calls that thin. When I measured how much of each profile appeared nowhere else on the site, the answer was 38.5 percent. The blog posts on the same site were 89.0 percent unique at 3,298 words, and all of them stayed indexed. The profiles were long and said almost nothing another profile did not say.
That site's problem was mostly the other status, 45 URLs Discovered against 1 Crawled, and the full diagnosis lives in the Discovered article. But the one URL that did land here is the instructive contrast: Google fetched a 1,199-word page that was 61.5 percent template and declined it. Length did not save it. Information would have.
So the refresh-or-rewrite question, which I set out in whether to update old posts or write new ones, comes down to one test: will the page contain anything that is only true because you looked? A longer version of the same page gets the same answer.
The JavaScript case: when Google crawled a page that was not there
One version of this status is technical, and it should be ruled in or out before any content work. If your site renders in the browser, Google's JavaScript SEO documentation describes three phases, crawling, rendering and indexing, and says of the render queue that "the page may stay on this queue for a few seconds, but it can take longer than that." If rendering fails or produces an empty shell, Google has crawled a page with nothing on it.
The test is in the tool people misuse for resubmission. Run URL Inspection on a declined URL and read the rendered HTML. If your headline and body copy are there, rendering is not the cause. If you see a root element and a script tag, it is. Google's recommendation is plain: "server-side or pre-rendering is still a great idea because it makes your website faster for users and crawlers, and not all bots can run JavaScript." On the major builders rendering is usually no longer the cause, as I set out in why AI-built sites fail to rank, but the half-minute check is the cheapest exclusion in this process.
What I did instead of rewriting 56 introductions
Once the diagnosis was pattern, editing pages one at a time was pointless. Fifty-six better versions of the same set would still be the same set. The work had to reduce the set and put something into it that had not been there.
The consolidation went from 56 posts to 18: 16 rebuilt survivors and 2 new cluster pages. Breed posts collapsed into size guides, because product choice was driven by the dog's weight and body shape, not its breed. Seat-cover posts redirected into the category page they had been competing with. Forty URLs got 301 redirects to the page that absorbed them, and the sitemap went from 69 URLs to 31.
The rebuilt pages run from 2,018 to 4,288 words each, 47,481 words across the 18 survivors, with zero product overlap between adjacent guides so no two pages could look templated against each other. Every fabricated claim came out. In its place each guide carries a callout headed "what this guide is and is not", which says in plain words that no crash testing was done and what the recommendations rest on instead.
It shipped on 28 July 2026. I checked that every one of the 40 redirects returned a 301 on the first hop and landed on a 200, in slash and no-slash forms, and that no surviving page linked to a redirected URL. Then I resubmitted the sitemap and stopped publishing.
What has happened since, and what I am not claiming
As of 20 September 2026, I am not reporting a recovery, because I have not verified one. Most articles about this status end with a fix and an implied happy ending. Google's definition says the page "may or may not be indexed in the future", and for a site-wide verdict the honest expectation is that re-evaluation, if it comes, arrives with a broad ranking update rather than on a schedule you can watch. Recovery would mean the 18 surviving URLs moving to indexed and the category pages receiving impressions again; a single URL flickering in and out would not count. I will publish the outcome either way, because a case study that only reports wins is a testimonial.
The consolidation removed the pattern. Whether that is enough, or whether the site also has to earn what it never had, meaning photographs, measurements and documented use of products actually owned, is the open question. My working assumption is the second, which is why the next post on that site will be about one product I own and have used, not eight I have read about.
What not to do while you wait
Do not buy an indexing service. They automate Request Indexing, which for this status is the action Google has told you is pointless.
Do not rewrite the introduction and call it a refresh. Google read the whole page. A new first paragraph on the same body is the same page.
Do not delete and republish at a new URL. You lose the URL's history and present the same content as a brand-new page on a young domain, which is worse.
Do not keep publishing into the pattern. If the diagnosis is velocity and sameness, every additional templated post is evidence against you. Stop, consolidate, then resume at a pace and a sourcing standard you can defend.
The short version
Crawled, currently not indexed is a decision, not a delay. Google read the page and declined it, and its own definition tells you not to resubmit. Sort the export before you theorise: a few URLs is pruning, one page type is a template, and a whole site with no manual action is a verdict on how it was built. Rule out JavaScript with one look at the rendered HTML, then audit the set, not the page: dates per day, heading skeletons with the nouns removed, the source of every fact, every claim you cannot evidence. On my own dropped site the pattern was 35 posts in three days, one product in 17 posts, every fact from a catalog, and testing claims that were untrue. I consolidated 56 posts to 18 and shipped on 28 July 2026. It has not recovered as of 20 September 2026, and I will say so until it does.
Frequently asked questions
What does "Crawled, currently not indexed" mean in Google Search Console?
Google's definition, read on 19 September 2026: "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." Googlebot fetched the page, read it, and chose not to index it. The decision is not final, but it is not a queue either.
How do I fix "Crawled, currently not indexed"?
Find the shape first. A few scattered URLs usually need nothing beyond a check that they are pages you want indexed. One page type at this status is a template problem, fixed by giving each page information the others lack or by merging the set. A whole site with no manual action is a pattern problem: velocity, sameness, catalog-sourced facts, unevidenced claims. Consolidate, add first-hand value, then wait.
Should I use Request Indexing on pages that are "Crawled, currently not indexed"?
Not until you have changed the page, and then once. Request Indexing asks Google to fetch the URL again, and for this status the fetch already succeeded; the page was declined after being read. Another fetch of the same HTML produces the same decision, which is why Google's definition says "no need to resubmit this URL for crawling."
How is "Crawled, currently not indexed" different from "Discovered, currently not indexed"?
Discovered means Google knows the URL but has not fetched it, so its content cannot be the direct cause; the problem is crawl demand, mostly links and structure. Crawled means Google fetched and read the page and then declined it, so the page, its type or the site's pattern is the cause. On one site I own the split was 45 Discovered to 1 Crawled, which pointed away from content.
Why is my whole website "Crawled, currently not indexed" with no manual action?
A site-wide version with no manual action is an algorithmic verdict on the publishing pattern rather than on any single page. On a site I own, Google dropped every URL around 21 July 2026 after 35 of 56 posts had gone out across three single days, with every fact sourced from a product catalog and testing claims that were not true. Each page passed a technical audit. The set did not.
What does "Validation failed" mean for "Crawled, currently not indexed"?
Validate Fix asks Google to re-check the URLs after you believe you fixed the cause; Google says it "typically takes up to about two weeks, but in some cases can take much longer." If the pages are substantially unchanged when re-read, the same decision comes back and validation fails. It is not a new error. It confirms that whatever changed was not what Google was declining.
Is "Crawled, currently not indexed" a penalty?
No. A penalty is a manual action, which has its own report, a named reason and a reconsideration process. This status is an ordinary indexing decision every site sees on some URLs. Site-wide, it is the visible result of Google's automated systems judging the content against its helpful-content and spam policies. That is a verdict, not a manual one, and there is no form to appeal it.
Does word count fix "Crawled, currently not indexed"?
Rarely, and never alone. A 1,199-word profile page on a site I own was declined because only 38.5 percent of its text appeared nowhere else on the site, while the 3,298-word posts on the same site were 89.0 percent unique and all stayed indexed. Ask whether the page contains anything that is only true because you did something. If not, more words produce a longer page with the same answer.
Can JavaScript cause "Crawled, currently not indexed"?
Yes, if Google's renderer times out or receives an empty shell, because it has then crawled a page with nothing on it. Check the rendered HTML in URL Inspection: if your copy is there, rendering is not the cause. Google states that "server-side or pre-rendering is still a great idea because it makes your website faster for users and crawlers, and not all bots can run JavaScript."
How long does it take to recover from "Crawled, currently not indexed"?
Google publishes no timeline and I will not invent one. A handful of URLs can change within the two-week validation window after a real fix. A site-wide verdict is more likely to be re-evaluated with a broad ranking update than on a schedule. My own consolidated site, shipped 28 July 2026, has no verified recovery as of 20 September 2026, and I would treat any promised duration as a guess.
Transparency: every Search Console status definition, helpful-content question and spam-policy quotation in this article was read directly from Google's own documentation on 19 September 2026. The case study is bestdogcarseat.com, a site owned by Ashikur Rahman, and every figure about it comes from the July 2026 investigation and rebuild; its outcome is reported as unresolved because it is. Where Google publishes nothing, this article says so rather than substituting an estimate. I sell indexing diagnosis and content consolidation as a service, which is a commercial interest you should weigh. There are no affiliate or tracking links on this page.
