Crawled – currently not indexed

Investigate URLs Google fetched but chose not to place in its index.

Directional evidence Partially automatable Intermediate

Crawled – currently not indexed means Google fetched the URL but did not add it to the index. Google says the page may or may not be indexed in the future and explicitly says there is no need to resubmit the URL for crawling.

The label proves that a page crawl occurred. It does not explain the indexing decision, assign a content score, or guarantee that the current live page is identical to the version Google processed.

For an important URL, investigate the indexed evidence, the current rendered page, the canonical cluster, and the wider URL cohort. Repeatedly pressing Request indexing without changing the underlying evidence rarely addresses the cause.

Does this status mean a technical error?

Not by itself. Unlike Server error (5xx), Redirect error, Blocked by robots.txt, or URL marked noindex, this reason does not identify a specific technical failure.

However, technical delivery can still contribute indirectly. A fetch can succeed while the page Google processes is:

Empty or nearly empty.
An error message returned with 200 OK.
Missing its main content after rendering.
Dependent on failed or blocked JavaScript and API resources.
Serving materially different content to Googlebot and users.
An unsupported or unintended resource rather than an indexable web page.
Canonicalized inconsistently after client-side rendering.

Begin with evidence instead of assuming the page needs more words or more indexing requests.

First classify the affected URLs

Export or sample URLs from the reason and group them by type:

Important editorial, product, service, category, or landing pages.
Near-duplicate templates or parameter variations.
Empty categories, out-of-stock states, expired listings, or placeholder profiles.
Feeds, API responses, images, scripts, documents, or other non-page resources.
Internal search, filter, sort, pagination, or session URLs.
Recently launched pages that have had only one crawl.
Old URLs already replaced by another destination.

An RSS feed or JSON endpoint can correctly remain outside the web-page index. A thousand programmatically generated location pages may require a product decision, not URL-by-URL inspection. An important guide or product page deserves deeper diagnosis.

Compare the indexed result with the live page

For representative important URLs:

Open URL Inspection.
Record the reported indexing state, last crawl date, crawled-as user agent, page fetch result, referring page, sitemap discovery, user-declared canonical, and Google-selected canonical when available.
Run Test live URL.
Confirm Crawl allowed?, Page fetch, and Indexing allowed?.
Open View tested page and review the rendered HTML, screenshot, loaded resources, and JavaScript messages.
Compare the main content with what a signed-out user receives.

The indexed result is historical evidence from Google's systems. The live test describes what the tool can fetch now. A successful live test does not prove Google would select the URL as canonical or index it; the live test does not evaluate every indexing condition.

If a recent deployment fixed the problem after the last crawl, the report can remain stale until Google recrawls and reprocesses the URL.

Diagnose technical and rendering problems

A successful 200 response is necessary but not sufficient

Google's HTTP documentation says a 2xx response makes content eligible for processing but does not guarantee indexing. Inspect the response body as well as the status.

Watch for:

A generic “not found,” “no results,” “product unavailable,” or login page returned with 200.
A blank application shell whose meaningful content never renders.
Consent, bot-defense, or geographic interstitials replacing the main content.
A server-side error message embedded in an otherwise successful template.
Very slow or failed API calls required to hydrate the page.
Canonical or robots directives changed by JavaScript.
Main content present only after user interaction.

If the content is truly missing, use a truthful 404/410 or an appropriate redirect. If the page should exist, make its essential content reliably available without depending on fragile interactions.

Confirm the rendered main content

Google renders JavaScript pages, but rendering is a separate processing stage and resources can fail. Compare:

Raw HTML source.
Browser-rendered DOM in a signed-out session.
URL Inspection's tested HTML and screenshot.
Network requests and console messages.

Server-rendering or pre-rendering critical content can improve reliability, but the goal is not a specific framework. The goal is that Google and users can consistently receive the same meaningful page.

Check indexability again

A current noindex directive, robots block, 4xx/5xx response, or redirect would normally lead to a more specific report reason after reprocessing. Still check them because the page may have changed since Google's recorded crawl.

Inspect both:

<meta name="robots" content="noindex">

and the HTTP equivalent:

X-Robots-Tag: noindex

Also verify that no environment, CMS, plugin, CDN, or response middleware injects a conflicting directive.

Investigate duplicate and canonical evidence

During indexing, Google identifies primary content, clusters duplicate or very similar pages, and selects a canonical representative. A URL may ultimately move from this reason to a duplicate or canonical status after Google finishes processing.

For the current cohort, check:

Does each page have a self-referential canonical when it is intended to stand alone?
Is that canonical absolute, valid, indexable, and returned in the HTML <head> or HTTP header correctly?
Do redirects, internal links, XML sitemaps, hreflang, and canonical annotations agree?
Is the purported canonical actually similar enough to be a duplicate?
Are host, protocol, casing, trailing-slash, tracking, and filter variants multiplying the same content?
Is JavaScript changing or adding a conflicting canonical?
Does URL Inspection name a Google-selected canonical different from the intended page?

Do not make every similar page self-canonical and expect Google to treat it as unique. Self-canonical annotations are signals, not declarations that override content similarity.

If pages are meant to be separate, their primary content and user purpose must differ clearly and substantially. Changing only a title, city name, or a few tokens may not create a distinct page.

Evaluate whether the page earns a distinct index entry

Google's documentation states that indexing is not guaranteed and lists low content quality as one possible indexing issue. This is not a license to invent a word-count threshold—Google publishes none.

Review the page as a product:

Purpose: Is there a clear audience and task the page completes?
Distinctness: Does it add information or utility beyond other pages in the same cluster?
Completeness: Can a user accomplish the expected task without returning to search for a better explanation?
First-hand value: Does it provide original evidence, experience, data, tools, examples, or expertise where appropriate?
Accuracy and trust: Are claims supported, authorship clear, and important facts maintained?
Template balance: Is the primary content substantial relative to navigation, ads, repeated boilerplate, and empty modules?
Current usefulness: Is an expired, unavailable, or empty state still valuable enough to remain a landing page?

For templated inventory, compare pages side by side. If the unique portion is negligible, consolidate, improve the underlying data and experience, or decide that the variants should not be indexed.

Check internal importance and sitemap consistency

Google has already discovered and crawled the URL, so adding any link is not a magic indexing fix. Still, site architecture helps communicate which pages are important and how they relate.

For an intended canonical page:

Link to it through relevant, crawlable navigation or contextual links.
Avoid making it an orphan reachable only through a sitemap.
Point internal links directly to the preferred URL, not redirects or parameters.
Include it in an XML sitemap only when it is canonical, current, and intended for indexing.
Use an accurate <lastmod> when the primary content meaningfully changes.
Remove duplicate, redirected, 404, noindex, or otherwise noncanonical URLs from canonical sitemaps.

Internal-link volume alone does not make a page useful. Add links where they improve navigation and establish a truthful relationship.

Diagnose by cohort and timeline

One URL can be noise; a template-wide change is evidence.

Build a table by:

Directory and template.
Publication date.
Sitemap.
Locale or market.
Content type.
Availability state.
Intended canonical status.
Last crawl date.
Release or migration date.

Then look for patterns:

A new frontend release caused rendered main content to disappear.
A feed or asset directory was newly exposed to crawling.
A publishing job created large numbers of empty pages.
A canonical template started pointing every page to a category.
An ecommerce change turned unavailable products into identical 200 responses.
Localized pages lost their translated primary content.
A site migration left internal links and sitemaps on old variants.

Fix the generating rule, data source, or component rather than editing example URLs one at a time.

When to wait and when to act

Waiting can be reasonable when

The page is new, useful, technically sound, and has had only a recent crawl.
A confirmed fix occurred after Google's last crawl.
Only a small number of low-priority URLs are affected.
The URL is not actually meant to be a web-search landing page.

Act when

Important canonical pages persist in the state.
The count grows after a release, migration, or bulk publication.
A high-value template has no indexed examples.
The rendered page lacks its main content.
Many pages are empty, interchangeable, or incorrectly canonicalized.
Indexed pages dropped while this cohort rose.

There is no universal number of days that proves a page has failed. Account for site size, update patterns, crawl frequency, and the last processed evidence.

What to change before requesting another crawl

Make a substantive, verified correction first:

Restore missing rendered content.
Correct the response or soft-error state.
Remove accidental noindex, robots, authentication, or security barriers.
Align redirects, canonicals, internal links, sitemaps, and hreflang.
Consolidate redundant pages or make intended pages meaningfully distinct.
Improve the page's usefulness and completeness.
Fix the template or publishing system affecting the whole cohort.

Then test the live URL. For a few important examples, request indexing once. For a large corrected group, publish an accurate sitemap and let Google recrawl it normally.

Google says repeated requests for the same URL do not make crawling faster, and its Page Indexing definition for this status says resubmission is unnecessary.

Measure the outcome responsibly

Track:

Count of important intended canonicals in the status.
Share of a submitted sitemap that becomes indexed.
Movement into Indexed, Duplicate, Redirect, error, or another accurate reason.
Time between a verified fix, recrawl, and changed indexed state.
Search impressions and clicks only after indexing has had time to settle.
Quality signals from users and the business, not only index counts.

Do not call the work successful merely because the status count fell. URLs could have moved into 404, noindex, duplicate, or server-error groups. Define the expected destination state for every cohort before making changes.

Common mistakes

Treating the label as a penalty or a single known algorithmic judgment.
Assuming 200 OK proves the page is indexable and useful.
Adding arbitrary word count without improving the page's purpose.
Making every variant self-canonical despite nearly identical content.
Requesting indexing repeatedly with no underlying change.
Inspecting only raw HTML on a JavaScript-dependent page.
Fixing a few examples while the template continues generating the problem.
Trying to index feeds, resources, internal-search pages, and other unintended URLs.
Expecting the live inspection to reproduce canonical selection.
Measuring only the aggregate count instead of important URL cohorts.