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

"Crawled - currently not indexed" is one of the more frustrating rows in the Page Indexing report, because unlike most of its neighbors, it doesn't tell you what to fix. "Blocked by robots.txt" tells you to edit robots.txt. "Page with redirect" tells you there's a redirect. "Crawled - currently not indexed" tells you almost nothing: Google visited the URL, read it, and chose not to add it to the index. No reason is given in the report, and that single line covers at least three genuinely different situations that call for different fixes.

The practical problem is that people usually respond to this status with the wrong action for their situation: hitting "Request Indexing" a few more times when the real issue is a broken render, or rewriting a paragraph when the real issue is that the page has almost no internal links pointing to it. This article walks through what the status actually asserts, how to tell which of the three underlying causes you're dealing with, what to change for each one, and when resubmitting is actually worth doing.

What This Status Actually Means

In the Page Indexing report, and in the per-URL detail you get from the URL Inspection tool, "Crawled - currently not indexed" means the crawl already happened. Googlebot fetched the URL, ran it through rendering if the page depends on JavaScript, and passed the resulting content to Google's indexing systems for evaluation. The outcome of that evaluation was: not now. That's different from the neighboring status "Discovered - currently not indexed," which means Google knows the URL exists, usually from a sitemap or a link, but hasn't gotten around to crawling it yet. Discovered-but-not-crawled is a crawl-priority question. Crawled-but-not-indexed is a judgment question, and the judgment has already been rendered on the version of the page Google actually saw.

That last clause matters more than it looks. The report doesn't show you what Google saw, only that it looked. Every diagnosis below starts from the same move: go find out what version of the page Google actually evaluated, because it is not automatically the same page you see in your own browser.

Rule Out a Technical Block Before You Diagnose a Judgment

Before treating this as a quality or duplication problem, confirm it isn't a disguised access issue. Three checks take a few minutes and rule out the most common false leads.

First, check for a noindex directive that only fires under certain conditions, such as a meta robots tag added by a plugin for a specific template, or an X-Robots-Tag header set at the server or CDN level that doesn't appear in a quick view-source because it's an HTTP header, not HTML. Second, check the canonical situation using the indexed-version details in URL Inspection, which show both your "User-declared canonical" and Google's "Google-selected canonical." If Google has picked a different URL as canonical, the page isn't really excluded from the index so much as folded into another URL, and the fix is a canonicalization decision, not a content rewrite. Third, confirm robots.txt isn't blocking a resource the page depends on for its main content, which produces a state that looks like indexing exclusion but is actually a partial access block.

Once those three are clean, self-referencing canonical present and respected, no conditional noindex, no robots.txt interference, you're left with a genuine "crawled, evaluated, excluded" case, and the cause is one of three things.

Three Reasons Google Crawls a Page and Sets It Aside

Each of these produces the identical status in the report, which is exactly why the report alone isn't a diagnosis.

• Quality or thinness relative to what already exists: the page's unique content, once you subtract navigation, boilerplate, and template text, doesn't add enough beyond what similar indexed pages already say for the same query.
• Duplication, formal or informal: the page overlaps heavily with another URL on the same site, or occasionally elsewhere, even without a canonical tag declaring the relationship. Google's own duplicate-detection can reach this conclusion independently of your canonical tags.
• Rendering or access inconsistency: the page looks complete to a human visiting in a browser, but the version Googlebot fetched and rendered was empty, truncated, or materially different, so there was effectively nothing substantial to index.

Diagnosing a Rendering or Access Problem

This is the fastest of the three to rule in or out, and it's worth doing first because it's binary: either Google saw your content or it didn't.

Open URL Inspection, run a live test, and look at the rendered screenshot and the rendered HTML, not the page source. If the screenshot is blank, missing the main content block, or showing a loading state instead of the finished page, that's your answer: whatever assembles your content, a client-side framework, a personalization script, content gated behind a scroll or click event, isn't finishing in time or isn't running the way it does in a real browser. Compare the rendered HTML tab specifically for whether your primary text actually appears in the DOM Google captured. A page that reads fine in your browser can still render empty for Google if the content is injected after an API call that times out, or after a user interaction Googlebot never performs.

Next, check the "Page resources" section of the test for anything Google couldn't fetch: a JavaScript bundle blocked by a stricter robots.txt rule on a subdomain or CDN, a font or stylesheet timing out, or a third-party script returning an error. A blocked resource that the page depends on to assemble its DOM produces an empty or broken render even when your raw HTML source looks completely normal in a plain view-source.

Finally, check for server-side inconsistency independent of JavaScript: fetch the URL with a plain command-line request and compare it, byte for byte if you have to, against what a logged-out browser receives. A CDN edge occasionally caching a partial or stale response, or a bot-mitigation rule quietly serving a lighter fallback page to non-browser user agents, both create a mismatch that reads to Google as thin or missing content. This is not the same thing as cloaking in the deceptive sense, but the effect on indexing is the same: Google indexed what it received, and what it received wasn't the real page.

Diagnosing a Quality or Duplication Judgment

If the render is clean, the screenshot matches what you see, all resources loaded, the server response is consistent, then the explanation left standing is evaluative rather than technical, and the fix has to be evaluative too.

Start by comparing the excluded page against two or three sibling pages on the same template that ARE indexed. Read them side by side and ask, specifically, what unique information the unindexed page contributes that the indexed ones don't already cover. This is uncomfortable to do honestly, because the templated structure that makes a page fast to produce is often exactly what makes it interchangeable with its siblings. A location page, a tag archive, or a lightly-varied product variant page are the classic cases: the boilerplate is most of the page, and the small part that's actually unique isn't enough to justify a separate index entry when a near-identical page already serves the same intent.

Check for internal near-duplication too, not just the external competitive picture. Take the page's most distinctive sentence or two and run it through your own site search, or a site-restricted search engine query. If two or three other URLs on your own domain return close variations of the same passage, Google is choosing among your own pages, not between you and a competitor, and the version losing that internal contest usually has fewer internal links, less history, or a canonical signal pointing away from it, rather than anything specifically broken about its writing.

The Internal Linking Problem Nobody Checks First

Internal links do more than help users navigate. They are one of the main ways Google estimates how important a given URL is relative to every other URL on the site, and they're part of what triggers a re-crawl and re-evaluation later. A page that exists only as one entry among thousands in an XML sitemap, with no contextual link from any page Google already trusts, sends a weak signal regardless of how good the writing is.

To check this, open the Links report in Search Console and look at internal links to the specific URL, then cross-reference with how many clicks deep it sits from the homepage. A page with zero or one internal link, reachable only three or four clicks deep with no category or hub page pointing to it directly, is a strong candidate for this cause, especially if the content itself reads fine and isn't an obvious duplicate.

The fix is adding contextual, in-content links from pages that are already indexed and already crawled regularly: a relevant hub or category page, a "related content" module driven by actual topical relevance, or a natural link from another article that references the same subject. Links repeated identically on every page, such as a footer link or a generic sitewide menu item, carry less weight for this purpose than a specific, in-context link, because Google can discount boilerplate that appears unchanged across the entire site. It's also worth checking that the pages doing the linking are themselves indexed; ten links from other unindexed pages don't transmit much, because the equity has to originate from somewhere Google already trusts enough to keep crawling.

What to Actually Change Before You Resubmit

Requesting indexing or running "Validate Fix" only makes sense after something real has changed. If nothing about the page, its rendered content, or its position in the internal link graph is different, the inputs to Google's decision haven't changed, so there's no real reason to expect a different outcome on the next pass.

If your diagnosis was rendering or access, fix the underlying template or resource-loading issue first, then re-run URL Inspection's live test to confirm the rendered screenshot and HTML now actually contain the content. Only request indexing once you've confirmed that, not before.

If your diagnosis was quality or duplication, the fix is substantive: add information the sibling pages don't have, a worked example, a distinct data point you can actually attribute, a genuinely different angle on the topic, not padding for word count. If your diagnosis was weak internal linking, add the contextual links first and give Google a normal crawl cycle to encounter them before assuming the fix didn't work.

In every case, plan for the re-evaluation to take longer than a manual refresh of the page. Indexing decisions are processed in batches rather than instantly, so a single request submitted minutes after a fix won't reflect an updated verdict yet. Resist the urge to resubmit repeatedly in the interim; it doesn't speed anything up, and it makes it harder to tell later which specific change, if any, actually moved the needle.

When to Stop Fighting for a Separate URL

Sometimes the right response isn't to get this exact URL indexed at all. If, after an honest read against its siblings, the page serves the same intent as an already-indexed page and only exists as a separate URL because of pagination, a filter combination, or a leftover from a migration, consolidating is usually faster and healthier for the site than continuing to push for a second index entry. A 301 redirect into the stronger page, or a canonical tag pointing to it, folds in any residual relevance and incoming links instead of leaving two pages to quietly compete for one slot.

Keep pushing for separate indexing only when the page genuinely answers a distinct question or serves a distinct segment of intent that the sibling pages don't cover. In that case, the earlier diagnosis steps, checking the render, checking for duplication, checking internal links, are exactly the right ongoing checklist, and a status that persists across a real content change and a real linking improvement is itself useful information: it tells you the page's topic, not its execution, is the limiting factor.