How to Fix “Discovered – Currently Not Indexed” in Google Search Console: 7 Steps

What Is “Discovered – Currently Not Indexed”?

“Discovered – currently not indexed” is a reason listed in Google Search Console's Page indexing report for URLs that Google knows exist but has not yet crawled, usually because it postponed the crawl to avoid overloading the site.

Google's Page indexing report documentation adds that this is why the last crawl date is empty for these URLs. It is different from “Crawled – currently not indexed”, where Google has fetched the page and decided not to index it for now; for that status Google says there is “no need to resubmit this URL for crawling”. In other words, “Discovered” is a problem about getting crawled, and “Crawled” is a problem about getting chosen. (Google's help documentation writes the label with a hyphen.)

Two parts of Google's crawl budget guide explain why it happens. Crawl capacity: Google limits how hard it crawls a host, and the limit falls if the site “slows down” or returns server errors (5xx) or rate-limiting signals such as HTTP 429. Crawl demand: Google crawls less when it wants less, and for Googlebot demand “varies based on a site's size, update frequency, page quality, and relevance, compared to other sites”. The guide is explicit that “even if the crawl capacity limit isn't reached, if crawl demand is low, Google will crawl your site less.” So although the report's wording points at server load, a small site on a fast server can still see this status because Google does not yet want those URLs badly enough.

Nothing here can force indexing: Google states that it “doesn't guarantee that it will crawl, index, or serve your page, even if your page follows the Google Search Essentials” (How Search works). For how long indexing normally takes, see how long Google takes to index a new page.

How to Fix “Discovered – Currently Not Indexed” at a Glance

Time: the checks take an hour or two on a small site (our estimate); results take days to weeks. Tools: Google Search Console, access to your CMS or server, and server logs if you have them. Cost: none beyond your time or a developer's. Skill level: intermediate; Steps 3 and 4 may need a developer.

What You Need Before Starting

• A verified Search Console property for the site, with owner or full-user permission. Google says requesting a crawl through URL Inspection requires being an “owner or full user of the Search Console property” (Ask Google to recrawl your URLs).
• A list of the pages you actually want in Google, so you can tell wanted URLs from noise.
• Access to change pages, redirects, robots.txt and the sitemap, or someone who has it.
• Your sitemap URL, if you have one. If you have not submitted one, see how to submit a sitemap to Google and Bing.
• Optional but useful: raw server logs, to confirm whether Googlebot is requesting the affected URLs.

Step 1: Measure How Many URLs Are Affected and Whether You Submitted Them

Open the Page indexing report in Search Console and find “Discovered – currently not indexed” in the table Google titles “Why pages aren't indexed”. This tells you whether you have a handful of URLs waiting or a large share of the site stuck.

Process: note the number of affected URLs and compare it with the number of indexed pages. Then use the sitemap filter at the top of the report. Google's help lists the options “All known pages”, “All submitted pages” and “Unsubmitted pages only”. Run it under each. If most affected URLs are unsubmitted, Google is finding URLs you did not intend to offer, such as parameter or filter URLs. If most are submitted, Google is putting off pages you explicitly asked it to crawl.

Expected result: a count and a rough split between submitted and unsubmitted URLs. How to verify: open the issue and export or scroll the example URLs; patterns (a shared folder, a query string, a date range) should be visible. Common mistake: treating a small number of new URLs in this status as a problem. A page published days ago may simply be waiting in the queue.

Step 2: Inspect a Sample of Affected URLs

Inspect five to ten affected URLs with the URL Inspection tool, either by typing the full URL into the inspection bar at the top of Search Console or by clicking the inspect icon next to a URL in the report. This shows how Google found each URL and whether it is a page you want indexed at all.

Process: in the page indexing section of the result, look at Discovery (how Google found the URL) and at the user-declared canonical. Ask of each URL: is it a page you want people to land on from Google, or a duplicate, a parameter variation, an internal search result, a thin tag page? Then click “Test live URL” to confirm the page can be fetched and is not blocked by noindex or robots.txt. Google notes that “Discovered – currently not indexed” itself cannot be tested in the live test, so the live test checks indexability, not whether Google will schedule the crawl.

Expected result: each sample URL sorted into “want indexed” or “don't need indexed”. How to verify: the live test shows the page fetch as successful and indexing allowed for the pages you want. Common mistake: requesting indexing for every sampled URL at this stage, before you know whether they deserve it.

Step 3: Remove, Redirect or Consolidate URLs You Do Not Want Crawled

Reduce the number of URLs Google has to work through. Google's crawl budget guide calls this “perceived inventory” and says that if many known URLs are duplicates or unwanted, “this wastes a lot of Google crawling time on your site. This is the factor that you can positively control the most.”

Process: match the fix to the URL type. Google's best-practice list includes consolidating duplicate content, blocking crawling of unimportant URLs with robots.txt, returning 404 or 410 for permanently removed pages, eliminating soft 404s, avoiding long redirect chains and keeping sitemaps up to date.

• Duplicates of a page you keep: redirect them or add rel="canonical" pointing to the preferred URL. Google's canonicalization guide ranks redirects and rel="canonical" as strong signals and sitemap inclusion as a weak one.
• Pages that no longer exist: return a real 404 or 410, not a “not found” message with a 200 status (a soft 404).
• Endless URL spaces you never want crawled (internal search results, sort and filter combinations): block them in robots.txt. Google says not to use robots.txt for canonicalization, so use it only for URLs that should not be crawled at all.
• Thin pages you keep for users: consider merging them into fewer, more substantial pages.

Expected result: over the following weeks, fewer unsubmitted URLs appear in the report. How to verify: re-inspect a removed URL with a live test and confirm the redirect, 404/410 or robots.txt block. Common mistake: blocking a duplicate in robots.txt when you wanted its signals consolidated; a blocked URL cannot be crawled, so Google cannot see its canonical tag. Before blocking anything, read whether blocking a crawler removes you from search.

Step 4: Check Server Health in the Crawl Stats Report

Open the Crawl Stats report (in Search Console's settings, under Crawl stats) and check whether Google is meeting errors or slow responses. The crawl budget guide says the crawl capacity limit goes down when a site slows down or returns 5xx errors or HTTP 429.

Process: look at the host status checks Google reports (robots.txt fetching, DNS resolution and server connectivity) and the breakdown of responses by type. Look for spikes of server errors (5xx) or 429s, and for rising average response time. Check whether a firewall, bot-protection service or rate limiter is challenging or throttling Googlebot. If the URL Inspection tool reports “Hostload exceeded”, Google's guide says to “add more server resources if that makes sense for your business.” If you use server logs, confirm that requests claiming to be Googlebot are genuine; how to verify a crawler is real explains the method.

Expected result: no sustained error or rate-limiting pattern, or a fix for the one you find. How to verify: in the weeks after a fix, the share of bad responses in Crawl Stats falls. Common mistake: spending time here on a small site with no errors. Google says the Crawl Stats report is aimed at advanced users and that a site with “fewer than a thousand pages” should not need it; for most small sites, Steps 3, 5 and 6 matter more.

Step 5: Link to the Pages You Want Indexed

Add internal links to each affected page you want indexed, from relevant pages that are already indexed. Google says it uses links “to find new pages to crawl” and that “every page you care about should have a link from at least one other page on your site” (Link best practices for Google).

Process: for each priority URL, find two or three related pages and add a contextual link with descriptive anchor text. Make sure links are standard <a href> elements that Google can follow. Check that new pages are linked from a hub, category page or the homepage rather than reachable only through the sitemap.

Expected result: no orphaned priority pages. How to verify: view the page source or a live test of the linking pages and confirm the links are present as plain <a href> elements. Common mistake: relying on the sitemap alone. Google calls submitting a sitemap “merely a hint” (Build and submit a sitemap).

Step 6: Clean the Sitemap So It Lists Only Pages You Want Indexed

Edit your sitemap so it contains only canonical, indexable URLs that return HTTP 200, with accurate lastmod dates. A sitemap full of redirects, duplicates and noindexed pages asks Google to spend crawling on URLs you do not want.

Process: remove redirected, 404, noindex and non-canonical URLs. Use fully qualified absolute URLs. Set lastmod only to the date of the last significant change: Google says it uses the lastmod value “if it's consistently and verifiably (for example by comparing to the last modification of the page) accurate” and that it ignores priority and changefreq (Google sitemap documentation). Resubmit the sitemap in the Sitemaps report if you made big changes; Google's Sitemaps report help says resubmission is worthwhile for big changes and that otherwise Google recrawls sitemaps on its own schedule.

Expected result: sitemap status “Success”. How to verify: filter the Page indexing report by that sitemap and watch the share of affected submitted URLs over the next weeks. Common mistake: setting every lastmod to today's date on each deploy. Google's Gary Illyes wrote that if the dates do not match reality, “eventually we're not going to believe you anymore” (Google Search Central blog, June 2023).

Step 7: Request Indexing for a Few Priority URLs, Then Monitor

Request indexing only for the small number of URLs that matter most, after Steps 2 to 6. In the URL Inspection tool, inspect the URL and click “Request indexing”.

Process and limits: Google's URL Inspection help says “there is a daily limit to how many index requests you can submit”, that indexing “typically takes only a day or so, but can take much longer in some cases”, and that a request “does not guarantee that the page will appear in the Google Index”. Google does not publish the size of the daily limit, so we do not quote one. You cannot request indexing for a page the live test finds non-indexable. For many pages, Google's advice is to submit a sitemap instead (Ask Google to recrawl).

Expected result: the request is accepted into the queue. How to verify: re-inspect after several days; the result should eventually show a last crawl date. Common mistake: requesting the same URL again and again. Google says repeat requests “won't get it crawled any faster.” Do not use the Indexing API as a workaround either: Google says it “can only be used to crawl pages with either JobPosting or BroadcastEvent embedded in a VideoObject” (Indexing API quickstart).

How to Verify It Worked

Look for these observable changes, in roughly this order:

• A last crawl date appears. Google says the date is empty for “Discovered” URLs; once a URL is crawled, URL Inspection shows when.
• The URL changes status. It moves to indexed, or to “Crawled – currently not indexed”. The second is progress on crawling but means Google has not chosen to index the page yet; improving or consolidating the content is the next lever.
• URL Inspection shows “URL is on Google”. Google defines this verdict as eligible to appear in results, not guaranteed to.
• The count falls in the Page indexing report, especially under “All submitted pages”.
• Server logs show verified Googlebot requests for previously uncrawled URLs.

If you fixed a site-wide cause, you can click “Validate fix” on the issue's details page in the Page indexing report. Google says validation “typically takes up to about two weeks, but in some cases can take much longer”, and warns not to click it again “until validation has succeeded or failed” (Page indexing report help). For the timing Google engineers have described for crawling and indexing changes, see how long Google takes to show a fix.

How to Choose a Fix for Your Situation

Common Problems and Fixes

What Not to Do

• Do not resubmit the same URLs repeatedly. Consequence: you use up the daily limit for no gain. Correction: request each priority URL once, then wait.
• Do not put every URL in the sitemap. Consequence: Google spends crawling on URLs you do not want. Correction: list only canonical, indexable URLs.
• Do not fake lastmod. Consequence: Google may stop trusting your dates. Correction: change it only for significant edits.
• Do not use robots.txt or the removal tool for duplicates. Consequence: Google says not to use robots.txt for canonicalization, and that the URL removal tool “hides all versions of a URL from Search”. Correction: use redirects or rel="canonical".
• Do not use the Indexing API for ordinary pages. Consequence: it is documented only for job postings and livestream pages. Correction: use the sitemap and internal links.
• Do not throttle or challenge Googlebot to save bandwidth. Consequence: 429s and errors lower Google's crawl capacity limit. Correction: if you must reduce load, cut wasted URLs instead.

Frequently Asked Questions

Sources and Methodology

This guide is built from Google's official documentation, read on October 6, 2026. We did not test these steps on a live site for this guide, and we did not measure how long URLs take to leave this status; any timing quoted is Google's own. The two-hour estimate for the checks is ours. Google does not publish the size of the URL Inspection daily request limit, so none is given. Search Console labels and menus can change; where Google's documentation did not confirm an exact label, we describe the control instead.

1. official Google Search Console Help, Page indexing report. Definitions of “Discovered” and “Crawled – currently not indexed”, sitemap filter, validation. Read October 6, 2026.
2. official Google Search Console Help, URL Inspection tool. Request indexing, daily limit, live test, verdicts. Read October 6, 2026.
3. official Google Search Central, Ask Google to recrawl your URLs. Quota, timing, permissions. Read October 6, 2026.
4. official Google Search Central, Optimize your crawl budget. Crawl capacity, crawl demand, best practices. Read October 6, 2026.
5. official Google Search Console Help, Crawl Stats report. Read October 6, 2026.
6. official Google Search Central, How to specify a canonical URL. Read October 6, 2026.
7. official Google Search Central, Build and submit a sitemap. Read October 6, 2026.
8. official Google Search Console Help, Sitemaps report. Read October 6, 2026.
9. official Google Search Central, Link best practices for Google. Read October 6, 2026.
10. official Google Search Central, In-depth guide to how Google Search works. Read October 6, 2026.
11. official Google Search Central, Indexing API quickstart. Read October 6, 2026.
12. official Gary Illyes, Google Search Central Blog, Sitemaps ping endpoint is going away, June 26, 2023. Guidance on lastmod. Read October 6, 2026.