Part of the Indexing Problems topic guide. Use the guide to move from this specific question to the full diagnostic workflow.
“Crawled – currently not indexed” means Google’s report records a crawl of the page but does not currently include it in the index — but does not currently include it in the index. The label records a state, not one guaranteed cause. For a backlink, it means the link can’t be verified as an indexed search result until the page gets indexed; that alone doesn’t prove the link’s value is zero. Most of these resolve on their own over time; the rest need you to improve the quality and signals of the page hosting the link.
This recorded state belongs in the Indexing Problems diagnostic map, where crawl evidence is separated from canonical, directive, availability and content branches.
If you build or sell backlinks, this status is doubly frustrating: you’ve delivered the work, but Google hasn’t “recognized” it. This guide handles that situation specifically — not generic webmaster theory.
What it means (and why it’s not an error)
In Google Search Console, “Crawled – currently not indexed” is an exclusion status: Google records that the URL was crawled but is not currently indexed. The label alone does not identify one cause. A certain number of URLs in this state is normal and can resolve as Google reprocesses them. The key idea: crawled ≠ indexed — being visited doesn’t mean being stored.
The key premise is that crawling and indexing are separate stages, so a recorded crawl does not establish indexed selection.
Why backlinks land here so often
For a backlink, the number-one cause is not your link — it’s the standing of the source page in Google’s eyes. Do not assign the state to the backlink itself: first separate source availability, placement evidence, directives, duplication and property-level indexing evidence. A guest post written purely to place a link, with thin or generic content, gets crawled and then deliberately left out. The thinner the link type, the higher the risk:
| Link type | Risk of “crawled not indexed” | Why |
|---|---|---|
| Self-made PBN / Web 2.0 | High | New pages, little authority, few internal links |
| Blog comment / profile | High | Aggregator pages, low value |
| Forum post | Medium | Depends on how “alive” the thread is |
| Guest post on weak site | Medium | Generic content, thin host site |
| Editorial guest post on strong site | Low | Authority + frequent crawling |
Have hundreds of links to push? Don’t check them by hand — check the whole batch’s index status first.
Use the evidence gates behind link types that struggle to index without treating the category label itself as a diagnosis.
Source page or content? A 4-question diagnosis
Don’t guess. Run these on the stuck URL:
- What does URL Inspection say? If “URL is on Google,” it’s just reporting lag — ignore it.
- Does the source site index at all? Record a dated external observation, but do not treat a
site:query as a complete index count or a private Search Console diagnosis. If authorized owner evidence is available, use it to classify the state. - Does the page have internal links pointing to it? Orphan pages get skipped — that’s a source structure problem.
- Is the content duplicate or generic? If so, it’s a content problem that needs real improvement.
Bottom line: weak source → change your link strategy; weak content → improve it and push signals.
Wait or act now?
- Wait if the source has decent authority, the link is new, and volume is small — this status often resolves on its own, though there is no guaranteed timeframe (a few weeks is a common rule-of-thumb window, not a promise). Track from a dated observation instead of a fixed deadline.
- Act when current evidence shows a repairable delivery, access, directive, canonical or content problem—not merely because a fixed number of days has passed.
How to fix it (when it’s worth saving)
- Add internal links from a strong page on the source site (if you control it).
- Improve the source content — add real value, cut generic filler.
- Strengthen legitimate discovery paths through relevant internal navigation or sitemap declarations when you control the source property.
- Request Indexing in GSC — but only after you’ve changed something.
- For volume, use a bulk backlink indexing service instead of manual requests.
Proving it to a client
This status causes sign-off disputes. Handle it transparently: export a per-URL status list (Indexed / Crawled-not-indexed / Pending) with the check date, note what you did, and sign off the indexed portion while tracking the rest. An honest index rate beats a fake 100% promise every time.
Which evidence source can actually identify this status?
| Evidence source | What it can establish | What it cannot establish |
|---|---|---|
| Search Console indexed report | Google’s recorded status, last crawl and canonical fields for an owned property | The current live page after later changes |
| URL Inspection live test | Current fetch/indexability checks | Whether Google selected the URL for indexing |
| External bulk checker | A time-bound public-search observation at scale | The Search Console exclusion reason |
Therefore, never label a third-party backlink “Crawled—currently not indexed” from an external check alone. Use that label only when the property owner supplies the Search Console evidence.
Before treating the status as a quality decision, verify the page is not excluded by a robots directive and compare the indexed report with the current live response.
What should a provider record before choosing an action?
Use an evidence ledger rather than a single “indexed/not indexed” column. For every delivered source URL, retain the expected landing URL, HTTP outcome, final URL after redirects, link-presence result, observation method, observation time and—only when supplied by an authorized property owner—the recorded Search Console state.
| Observed object | Allowed conclusion | Next decision |
|---|---|---|
| Source is unavailable or access is denied | Delivery cannot be verified at that time | Resolve availability before discussing indexing |
| Source is reachable but the contracted link is absent | The placement fails delivery QC | Repair or replace the placement |
| Link is present; no indexed representation is observed externally | A dated public observation, not a private exclusion reason | Keep the result unresolved or request owner evidence |
| Authorized Search Console evidence records a crawl but no current indexing | The property records the named state | Compare the fetched representation, directives, canonical signals and meaningful page changes |
Worked example: a guest-post URL returning 200 with the expected anchor present can pass placement QC while its index observation remains unresolved. Those are two separate states. Report both instead of turning the second result into a claim that the first failed.
For the complete routing model, use the Indexing Problems hub; for how IndexVero separates observations from causes, see the public methodology.
When the problem is availability or a Soft 404
“Crawled – currently not indexed” does not cover every failed URL. If the response is error-like despite HTTP 200, use the Soft 404 diagnostic. If the fetch failed with 5xx, 429, access, timeout or DNS evidence, use the server and access error guide before making a content diagnosis.
FAQ
How long does “crawled not indexed” last?
There’s no guaranteed timeframe. It often resolves within a few weeks if the page has enough value, and may never resolve if it’s too thin — track from a dated recheck rather than a fixed deadline.
Is it my fault?
The status alone cannot assign fault. Separate the source response, placement evidence and authorized indexing fields before naming a cause.
Does requesting indexing repeatedly help?
Repeated requests do not repair an unchanged access, directive, canonical or content problem. Correct the supported issue before requesting another crawl.
Do nofollow/UGC links get this status?
Yes — index status is independent of the rel attribute; the page still needs enough value to be indexed.