Discovered – Currently Not Indexed: What It Means and What to Check

“Discovered – currently not indexed” means Google knows a URL exists but has not crawled it yet. Because the crawl has not happened, Google cannot yet have evaluated that page's full content for indexing.

That distinction should shape your response. Do not start by adding filler, changing the canonical or requesting indexing every day. First find out whether you have one recent URL waiting for a crawl, a neglected section, a large unwanted URL space or a host that Google struggles to reach.

This guide focuses on that pre-crawl state. If Search Console shows a different reason, begin with the broader guide to why Google is not indexing your website.

What the status tells you—and what it does not

Google's Page Indexing documentation defines the status precisely: Google found the page but has not crawled it yet. The documentation says Google typically rescheduled the crawl because it expected that crawling could overload the site. The report therefore has no last-crawl date for the URL.

The label gives you three useful facts:

• Google has recorded the URL.

• Google has not fetched the page yet.

• The URL cannot enter Google's index through that crawl until a crawl happens.

It does not prove that Google inspected the current copy and rejected its quality. It also does not prove that your server is overloaded now. Search Console reports a recorded state; your live site may have changed since Google discovered the URL.

Keep this status separate from Crawled – currently not indexed. In the latter state, Google fetched the URL and then did not include it in the index at that recorded point. The two labels sit on opposite sides of the crawl event and require different first checks.

If the discovery, crawl, index and ranking sequence is unfamiliar, read What Is SEO?. For this diagnosis, the critical fact is simple: you are investigating why the fetch has not happened.

1) Record the evidence before changing the page

Inspect the exact canonical URL in Search Console. Do not infer its state from a broad site: search or from a similar URL.

Record:

• the full inspected URL;

• the exact Page Indexing reason;

• whether the last-crawl field is empty;

• the referring page or sitemap shown, if available;

• the date you first saw the status;

• the sitemap in which Google found the URL;

• whether the page is new, recently migrated or generated from a template; and

• how many related URLs share the state.

Then run Test Live URL. A successful live test does not contradict the recorded status. It answers a different question: can Google access the page now? The recorded status tells you what Google's indexing systems had processed at their last update.

Use the live test to confirm that the current URL:

• returns the intended page rather than a login or error message;

• permits crawling;

• resolves without a loop or irrelevant redirect; and

• exposes its main content and links.

Do not treat a successful test as a guarantee that Google will crawl or index the URL. It only rules out some current access failures.

2) Classify the affected pattern

One URL and 50,000 URLs do not call for the same response. Group the affected set before choosing a fix.

This grouping prevents a common error: rewriting one page when the evidence points to a site-wide serving or inventory problem.

Export the examples from the Page Indexing report and add operational fields: page type, directory, creation date, sitemap, internal-link count, response code and template. A pattern often appears once the URLs are sorted by those fields.

Glarify can help organise connected Search Console, sitemap, coverage and indexing signals in one workspace. Use that view to group and track evidence, then verify the exact URL in Search Console and confirm server-side behavior in your own logs. A tool cannot guarantee that Google will crawl or index a page.

3) Trace how Google discovered the URL

A sitemap entry explains how Google may have learned the URL. It does not establish the page's place in your site.

Google's sitemap guidance says sitemaps help search engines discover important URLs but do not guarantee that every listed item will be crawled or indexed.

For an important page, check whether:

• the final canonical URL appears in the sitemap;

• the sitemap returns 200 and Search Console has accepted it;

• at least one useful, already accessible page links to the URL;

• the link uses a standard HTML anchor with a resolvable href;

• the destination does not depend on an internal search form, button click or URL fragment; and

• navigation and breadcrumbs place it in a sensible section.

An isolated sitemap URL can be known without receiving clear site-importance signals. Add links only where the destination helps a reader continue a task. A footer stuffed with every URL is not a substitute for coherent architecture.

For implementation, use Amplify's guide to building an internal linking strategy. Point links to one clean canonical form and update the source pages that logically introduce the destination.

If the page is new and already has a valid sitemap entry plus useful crawlable links, record that evidence before doing more. Repeated sitemap submissions will not make the signal qualitatively stronger.

4) Check whether the host is limiting crawling

Google defines crawl budget as the URLs it can and wants to crawl. The two parts are crawl capacity and crawl demand.

Capacity describes how much crawling the host can handle without being overwhelmed. Google's current crawl-budget documentation says the limit can fall when response time deteriorates or the host returns server errors such as 5xx and rate-limiting responses such as 429.

Review Search Console's Settings → Crawl stats for a root-level property. Check:

• host status;

• average response time;

• total crawl requests;

• response-code distribution;

• robots.txt availability;

• DNS resolution; and

• server connectivity.

Do not read one slow request as a trend. Compare the period when affected URLs accumulated with the crawl and availability timeline. Then inspect CDN, firewall, load-balancer and application logs for Googlebot requests around the same dates.

Look for evidence such as:

• clusters of 429, 500, 502, 503 or 504 responses;

• rising time to first byte;

• connection resets or timeouts;

• intermittent DNS failures;

• a robots.txt endpoint returning 429 or 5xx;

• security rules challenging or blocking verified Googlebot; and

• deployment spikes that coincide with the affected URL group.

Google's Crawl Stats guidance notes that the report is advanced and that sites with fewer than about 1,000 pages generally should not need this level of crawling detail. On a small site, check the basics first. A broad crawl-capacity investigation becomes reasonable when the status persists across a meaningful portion of the site or when host evidence supports it.

5) Audit the URLs competing for crawl attention

A site can expose far more URLs than it intends to publish. Filters, sorting, tracking parameters and generated archives may create an effectively unbounded crawl space.

Inspect the URLs Google discovers, not only those in your sitemap. Common sources include:

• faceted product filters;

• sort-order combinations;

• internal-search result pages;

• calendar links that create endless future dates;

• session IDs and tracking parameters;

• print or alternate-format URLs;

• duplicate HTTP, HTTPS, www and non-www routes;

• pagination that repeats or loops; and

• malformed relative links that generate new paths.

Measure each pattern before blocking anything. Ask:

1. Does the URL serve a distinct user task?

2. Should it appear in search?

3. Does a preferred canonical version exist?

4. How does Google discover the unwanted variation?

5. Can the source link or generation rule be removed?

6. Should duplicates consolidate, redirect, return 404/410, or remain crawlable for another reason?

Fix generation and canonical routing at the source where possible. Do not add a robots.txt block to an important URL that you want Google to crawl. Do not use noindex as a generic crawl-budget control: Google must request a page to read that directive.

For a site with millions of valid URLs or tens of thousands of rapidly changing pages, involve the development and infrastructure teams. For a 50-page service site, first repair broken links, sitemap noise, redirect variants and missing architecture.

6) Improve crawl demand without manufacturing signals

Crawl demand reflects which URLs Google wants to revisit and how it allocates finite resources. Google's documentation names factors such as site size, update frequency, page quality, relevance, perceived inventory, popularity and staleness.

You cannot force demand with a button, but you can make the site's priorities coherent:

• maintain a useful, finite URL inventory;

• link important pages from relevant hubs and related content;

• stop generating near-duplicate routes that have no search purpose;

• consolidate genuine duplicates;

• keep sitemap URLs canonical, live and current;

• make meaningful updates when facts or user needs change; and

• publish pages that own a clear task instead of splitting one answer across thin variants.

Do not change a date without changing the page. Do not add generic paragraphs simply to make an uncrawled page longer. Google has not fetched that page in this recorded state, so you cannot honestly attribute the delay to a particular sentence or word count.

Page usefulness still matters at the site and inventory level, but it belongs in a broader prioritisation decision: should this URL exist, where does it fit, and which other page would it duplicate?

7) Match the fix to the evidence

Use the narrowest action that addresses the observed pattern.

After the fix, test representative URLs and the shared template. Use Request Indexing sparingly for a repaired, important URL. For a large affected set, validate the shared change and monitor the Page Indexing group rather than submitting every example.

8) Work through a hypothetical Kenyan ecommerce pattern

Consider a hypothetical Nairobi office-furniture retailer that adds a category page for ergonomic office chairs.

Search Console reports the clean category URL as Discovered – currently not indexed. The live test works, the sitemap lists the URL and the server currently returns 200. Rewriting the category introduction would not yet explain the state.

The team exports the affected examples and finds that most belong to the catalogue. Its faceted navigation creates crawlable combinations for colour, material, stock status, price order and tracking parameters. The clean chair category receives no contextual link from the office-furniture hub because users reach it through an internal search interface.

The server logs also show periods of 429 responses during inventory imports. This produces two evidence-backed workstreams:

1. Inventory and architecture: The developer prevents unwanted filter combinations from generating crawlable routes, aligns sitemap entries with final canonical categories and adds a useful link from the office-furniture hub to the chair category.

2. Serving capacity: The infrastructure owner reviews the rate limit and import process so legitimate crawl requests do not encounter recurring 429 responses.

The team tests the clean category and representative filter URLs after deployment. It records the change date and monitors Crawl Stats plus the affected Page Indexing group.

The scenario does not promise that the category will be crawled or indexed on a particular date. If Google later crawls it but reports a different exclusion, the team starts a diagnosis for that new state instead of continuing to solve the old one.

9) Monitor the transition, not a promised deadline

Google says crawling and indexing can take days or weeks and does not guarantee that every submitted page will enter the index. That makes a fixed “wait seven days” rule unreliable.

Create a simple monitoring record:

A move from Discovered to Crawled – currently not indexed is not a failed crawl fix. It shows that Google crossed the crawl stage and now reports a different indexing decision. Diagnose the new state on its own evidence.

The practical sequence is: confirm the exact status, classify the pattern, verify discovery, inspect host health, control the URL inventory, fix the shared cause and monitor. That is more defensible than changing the page until the label disappears.

If the affected set spans a migration, catalogue, JavaScript application, firewall or persistent host errors, request a technical SEO audit from Amplify SEO. Bring the URL export, Crawl Stats timeline and server evidence so the audit can start with the pattern you already found.