5 min read
Google says "Crawled - currently not indexed" - how do I find out when it started?
By CrawlWarden, which builds the monitoring described at the foot of this article.
Published .
"Crawled - currently not indexed" means Google fetched the page, found nothing blocking it, and chose not to index it anyway. It is a quality and priority judgement, not an error, so there is nothing to fix in the sense of a broken tag. The date it started is the fact that matters, because it tells you which change to look at, and Search Console does not keep it: it shows today's state only.
What Google actually means by it
In the Page indexing report this state sits apart from the error states. Google documents it as the page having been crawled and not indexed, with the advice not to submit it again and that it may be indexed later (Page indexing report).
That phrasing is deliberate on Google's part. The page is not excluded by noindex, not blocked by robots.txt, not a redirect, not a duplicate with a chosen canonical elsewhere: each of those has its own state. What is left is Google deciding the page is not worth a slot right now.
- Thin or near duplicate content, including templated pages that differ only by a variable.
- A page with no internal links pointing at it, which tells Google nobody on the site thinks it matters.
- A new page on a site with little crawl budget, which is often temporary.
- A page whose value fell after an edit: a section removed, a block of links deleted, content replaced with a loader.
Why the start date is the useful fact
Everything above is a hypothesis. What turns a hypothesis into a short list is knowing the week it changed, because something on the site almost certainly changed in that week too.
A page that has been in this state since it was published is a content and linking problem. A page that WAS indexed and entered this state on a particular Tuesday is a change problem, and the answer is in whatever shipped that Tuesday. Those two cases look identical in Search Console today, and they have nothing in common as work.
The four ways to recover the date
| Approach | What it gives you | What it costs |
|---|---|---|
| The Pages report trend | The date the COUNT for this state moved, over up to 16 months. Narrows it to a week. | It is a count, not a page. On a site with many pages the line barely moves for one URL. |
| Performance report, filtered to the URL | The date impressions went to zero, which is usually within days of the state changing. | Impressions can hold for a while after indexing stops, and a page that never had traffic shows nothing. |
| URL Inspection, last crawl date | When Google last fetched it. Sometimes suggestive. | It is one date, overwritten each crawl, and it is not the date of the decision. |
| Your own record of the page | The exact dates things changed on that page, with values before and after. | Only exists if something was recording it before the problem started. |
What to do with the week once you have it
- Look at what shipped in that week, including dependency and plugin updates nobody considers a release.
- Check whether internal links to the page survived. A navigation or related posts change can orphan a page without touching the page itself.
- Check whether the page still contains what it contained: a word count that halved, or a block replaced by a client side loader, both read as the page getting thinner.
- Check the canonical and the sitemap. Neither produces this exact state, but both commonly change in the same edit, and both narrow the cause.
- If nothing shipped, consider that Google reassessed rather than reacted. A core update in the same window is a reasonable reading, and the Search Status Dashboard publishes the dates.
Where CrawlWarden fits, plainly
CrawlWarden reads Google's own verdict for each watched page once a day and reports when it changes, so the state entering "crawled, currently not indexed" becomes a dated event with an email rather than something you find next time you open the report.
Because it has also been recording what the page itself contained every few hours since it was added, the alert arrives with what changed on that page beforehand: the canonical, the title, the word count, the internal link count, with timestamps. It does not claim one caused the other. It gives you the week, which is the thing Search Console cannot.
This half of the product needs no traffic at all. Google holds a verdict on a page with ten visits a month, and that verdict changing is news whatever the page earns.
The checks that report this
CrawlWarden watches a list of URLs you choose and reports what changed. It does not diagnose and it does not score. Severity is a property of the check rather than a setting: the number below is how many consecutive runs must see the new value before it becomes an email, and it is never less than two, because one observation is noise.
Google index statusconfirmed over 2 consecutive runs
Reports when Google stops listing a watched page as indexed, and the raw coverage state Google gave sits in the evidence.
Google fetch resultconfirmed over 3 consecutive runs
Reports when Google's last fetch of the page ended differently, confirmed over three days because one failed fetch on Google's side is ordinary.
Google-selected canonicalconfirmed over 2 consecutive runs
Reports when Google decides another URL speaks for this page, which is the state next door and a frequent cause of pages quietly losing their slot.
Word countconfirmed over 3 consecutive runs
Reports when the page's own content shrinks, which is the change most often behind a page being judged not worth indexing.
Every check is available on every plan, including the free one. CrawlWarden pricing, per site rather than per URL.
Questions
- Is "Crawled - currently not indexed" an error?
- No. Google lists it separately from the error states. The page was fetched and nothing blocked it; Google chose not to index it. There is no tag to fix, which is why people get stuck on it.
- Should I request indexing again?
- Google's own documentation says not to submit the URL again for this state. Repeated requests do not change the judgement, and the quota is better spent elsewhere.
- How long does it take to come back?
- There is no published figure, and anyone quoting one is guessing. Pages do return, often after the content or the internal linking changes. What you can control is knowing the date it started so that the change you make is aimed at the right thing.
- Does Search Console keep a history of coverage states?
- Not per URL. The Pages report charts the COUNT per state over time, and URL Inspection shows the current state. The history of one URL's state is not something the report retains.
Related
- what Search Console can and cannot tell you when clicks fall
- the triage order when a page has left the index entirely
- the noindex tag, which produces a different state with the same symptom
- canonical drift, the state next door
- every failure mode CrawlWarden watches for
- every check it runs, and what a change in it means
Sources
What was checked, and where. An entry with no link is something that could not be verified, named here rather than left out.
The definition of "Crawled - currently not indexed", that it is not listed as an error, and the advice not to resubmit the URL.
That the tool reports the current state and the last crawl date, and keeps no per URL history.
Google: Debugging drops in Google Search traffic
Using the Performance report filtered to one URL to date the change, and treating a core update window as a cause of reassessment.
Google: Search Status Dashboard
That ranking update dates are published, so "Google reassessed" can be checked against a date rather than assumed.
Not verified: how long pages typically stay in this state
Google publishes no timeline and no recovery rate. The page deliberately gives no figure.
Know the moment this happens to you
Give CrawlWarden a domain, keep the pages it suggests, and the first check runs immediately. Free forever for one site.