Discovered – currently not indexed

Diagnose URLs Google knows about but has not yet crawled.

Directional evidence Partially automatable Intermediate

Discovered – currently not indexed means Google knows the URL but has not crawled it yet. Because no crawl occurred, the Page Indexing report normally shows no last crawl date.

Google's report documentation says this status commonly appears when Google wanted to crawl the URL but expected that doing so would overload the site, so the crawl was rescheduled. Google's crawl-budget documentation adds a broader model: crawling is constrained by both what Google can crawl without harming the site (crawl capacity) and what its systems want to crawl (crawl demand).

The status is not proof of one specific defect. Diagnose the affected URL class before trying to force individual URLs through URL Inspection.

First decide whether the URLs should be indexed

Not every discovered URL deserves a crawl or a place in Search. Classify examples into:

Important canonical pages that should be public and searchable.
Duplicate, filtered, sorted, parameterized, print, tracking, or session URLs.
Internal search results or near-empty generated pages.
Expired inventory, empty categories, or deleted content.
Feeds, API endpoints, resources, or other URLs not intended as web-search landing pages.
Unknown URL patterns caused by broken link generation or crawler traps.

The correct fix may be to make an important page easier and safer to crawl. It may instead be to stop exposing an unwanted URL inventory. Do not treat the raw count as a queue of pages that must all become indexed.

Why the last crawl date is empty

The Page Indexing reason records a discovery without a completed page crawl. This is different from Crawled – currently not indexed, where Google fetched the URL and then did not index it.

An empty last crawl date means the report has no completed crawl to describe for that URL. It does not tell you:

Exactly when Google first discovered the URL.
Which discovery source was decisive.
When Google will crawl it.
Whether it will be indexed after crawling.
A URL-specific “quality score.”

The Page Indexing report can also lag. Inspect a few important examples individually: URL Inspection may show a more recent crawl or indexed state that has not yet propagated to the aggregated report.

Diagnose the pattern, not one example

Export the example URLs and add operational fields:

Field	Question answered
URL template or directory	Is one platform rule generating most affected URLs?
Intended index state	Should this URL be searchable?
In canonical sitemap	Is the site explicitly presenting it as a preferred page?
Internal-link depth	Can a crawler reach it through normal navigation?
Unique purpose	Does it offer a distinct, useful landing-page experience?
HTTP and live-fetch result	Can the current page be fetched successfully?
Server-log evidence	Has verified Googlebot actually requested it since the report date?
Created or updated date	Is it new, stale, or part of a recent bulk launch?

The report's examples are limited to 1,000 URLs and are not a complete list. Use representative sampling by template, sitemap, product type, locale, or publication date rather than assuming the examples are the whole issue.

Cause 1: the site exposes too many unwanted URLs

Google's crawl-demand model includes perceived inventory: without clear guidance, Google may try to crawl most URLs it knows about. Duplicate and unimportant URL variants consume attention that could otherwise go to new or updated canonical pages, especially on very large sites.

Common sources of URL explosion include:

Faceted navigation with combinable filters.
Sort orders and view modes with crawlable URLs.
Calendar or pagination paths with no useful endpoint.
Session identifiers and tracking parameters in internal links.
Internal search results.
Relative-link errors that generate endless URL paths.
Multiple protocol, hostname, casing, trailing-slash, or filename variants.
Links to noncanonical parameters in templates.

For each URL family, choose an intentional policy:

Preserve as a distinct canonical page because it serves a real search need.
Consolidate duplicate signals with a redirect or canonical setup.
Remove internal discovery paths and return a truthful 404/410 when the URL should not exist.
Block crawling with robots.txt when Google should not request the pattern at all and the indexing implications are understood.
Use noindex for a public page that must be crawled but must not appear in Search, recognizing that Google still has to crawl it to see the directive.

Do not add unwanted URLs to a sitemap, link to them as if they were important, and then expect a canonical or noindex directive to eliminate all crawl cost.

Cause 2: weak discovery and internal architecture

A sitemap helps Google discover preferred URLs, but it does not guarantee crawling or indexing. Important pages should also be reachable through ordinary crawlable links.

Check that:

The page has at least one descriptive <a href="..."> link from an already known, relevant page.
Users can reach it through normal navigation without submitting a form, selecting a dropdown, or triggering JavaScript that never produces a crawlable link.
Category, hub, collection, or related-content pages link to it.
Internal links use the preferred absolute or consistently resolved URL, not redirecting or parameterized variants.
Pagination or load-more interfaces expose crawlable page URLs when older items need discovery.
Orphan reports exclude intentionally isolated pages and identify truly important orphans.

Submitting an XML sitemap is useful for new launches, migrations, and large URL sets. Include only canonical URLs you want indexed, keep <lastmod> accurate when content meaningfully changes, and remove retired URLs after their transition has been processed.

Cause 3: crawl capacity and host health

Google calculates a crawl capacity limit to avoid overwhelming a hostname. Capacity can fall when the site slows down or produces server errors.

Review Settings → Crawl stats → Host status and the response breakdown for:

Repeated 5xx responses.
429 Too Many Requests, which Google treats as a server-overload signal.
DNS failures.
robots.txt fetch failures.
Connection resets, timeouts, refused connections, or truncated responses.
A sustained response-time increase.

Then correlate those times with CDN, firewall, load balancer, application, database, and origin logs. Verify Googlebot requests rather than trusting a spoofable user-agent string.

Typical fixes include:

Restore reliable 2xx responses for important pages.
Correct overly broad WAF, rate-limit, or bot-management rules.
Cache expensive pages and resources appropriately.
Remove slow redirect or application chains.
Fix database queries, dependency failures, and resource exhaustion.
Scale capacity if verified crawl requests compete with legitimate traffic.
Keep robots.txt consistently available. A missing robots.txt that returns 404 is acceptable; repeated 5xx/429 or connection failures are not.

Do not deliberately return 5xx or 429 to unimportant URLs as an indexing-control technique. Those statuses communicate host trouble and can reduce crawling more broadly.

Cause 4: insufficient crawl demand

Even when a server can handle more crawling, Google's systems may not demand every URL. Google's current crawl documentation lists factors such as:

Site and URL popularity.
Update frequency and staleness.
Page quality and relevance for the Google product.
Overall user value and content uniqueness.
The amount of duplicate or unwanted URL inventory.

This does not produce a formula or threshold you can calculate in Search Console. It does mean that thousands of interchangeable pages are unlikely to be solved by submitting them repeatedly.

For important page families, ask:

Does each page satisfy a distinct user need, or only swap a few tokens?
Does the template provide the main information immediately, including when rendered?
Are empty, unavailable, or thin states prevented from publishing as indexable pages?
Is the page meaningfully connected to the site's subject and navigation?
Are there independent reasons for users or other sites to discover and reference it?
Is the canonical page unambiguous across links, sitemaps, redirects, and annotations?

Consolidating redundant inventory and improving the actual usefulness of the remaining pages is more durable than manufacturing internal-link volume.

A reliable investigation sequence

1. Measure the affected cohorts

Group examples by URL pattern, template, sitemap, created date, language, and business value. Compare the trend with releases and bulk publishing events.

2. Confirm current eligibility

For representative important URLs:

Open URL Inspection.
Check whether the indexed result still says not crawled.
Run Test live URL.
Confirm Crawl allowed? Yes, Page fetch: Successful, and Indexing allowed? Yes.
View the tested page to confirm the main content and essential resources render.

A successful live test proves current accessibility; it does not guarantee a scheduled crawl or indexing.

3. Audit discovery

Verify the canonical sitemap entry, crawlable internal links, link depth, and whether templates point to preferred URLs. Remove contradictions such as sitemapping one URL while linking everywhere to another.

4. Audit host capacity

Use Crawl Stats and infrastructure logs to look for site-level or template-level failures. A fast browser visit from your own location does not disprove intermittent, regional, Googlebot-specific, or peak-load failures.

5. Reduce unwanted inventory

Fix crawl traps and systemic duplicate generation before adding more sitemap submissions or indexing requests.

6. Improve the intended inventory

Make each important canonical page useful, complete, unique enough for its purpose, and connected through the site's architecture.

7. Let Google recrawl naturally

For a few urgent, corrected URLs, use URL Inspection's indexing request. For many URLs, use a sitemap. Google states that crawling can take days to weeks and that repeated requests for the same URL do not make crawling faster.

When requesting indexing helps

Request indexing only after the page is:

Publicly accessible.
Returning a successful response.
Allowed by robots.txt and indexing directives.
Canonicalized consistently.
Linked and included in the correct sitemap when appropriate.
Worth indexing as a distinct page.

The request is most useful for a small number of important new or substantially changed URLs. It is not a batch fix for a template producing thousands of deferred URLs, and it cannot guarantee inclusion.

How to know whether the fix worked

Track cohorts rather than checking one URL repeatedly:

Number and share of intended canonical URLs in this status.
Time from publication to first verified Googlebot crawl in server logs.
Successful Googlebot responses and response time by template.
Movement from Discovered to Crawled, Indexed, Duplicate, or another truthful state.
Indexed count for submitted canonical sitemaps.
Search impressions for newly indexed page groups after sufficient time.

A falling Discovered count is not automatically success if URLs merely move to errors or inappropriate canonical clusters. The desired outcome is that important canonical pages are crawled and evaluated, while unwanted URL inventory stops expanding.

Common mistakes

Treating every discovered URL as a page Google should index.
Assuming the phrase “expected to overload the site” proves the server is currently down.
Looking only at homepage uptime instead of Crawl Stats and infrastructure logs.
Creating more sitemap files without cleaning the URL inventory.
Adding sitewide links to low-value pages solely to trigger crawling.
Blocking URLs in robots.txt and expecting their report entries to disappear immediately.
Using noindex as a crawl-budget tool; Google must crawl the URL to see it.
Repeatedly requesting indexing before fixing the underlying page family.
Expecting immediate movement in an aggregate report that can lag.