Discovered, currently not indexed: causes and fixes

"Discovered, currently not indexed" is a Search Console status for URLs Google knows exist but has not crawled yet. Google found them through a link or a sitemap, planned a visit and pushed it back, either because it expected the crawl to strain your server or because it did not rate the URLs as worth fetching soon. A few recently published URLs in this state are normal. Thousands of them point to a slow or erroring server, weak internal links, or a pile of filter and parameter URLs eating the crawl, and those are what you fix.

What does discovered, currently not indexed mean?

It means Googlebot has the URL on its list and has never fetched it. The status is a row in the "Why pages aren't indexed" table under Indexing > Pages in Search Console. Click it to see up to 1,000 example URLs.

Google's help sums it up as "The page was found by Google, but not crawled yet." It adds that Google typically wanted to crawl the URL, expected that to overload the site and rescheduled, which is why the last crawl date is empty.

Google's crawl budget guide adds the other half. Crawling is capped by how much load your server takes and by how much Google wants your URLs, which depends on their number, popularity and staleness. On a small site with a fast server, capacity is an unlikely culprit, which leaves demand.

If your whole site is missing from Google rather than a set of URLs, start with why your website is not showing up on Google instead.

Discovered vs crawled, currently not indexed

The difference is whether Googlebot fetched the page. "Crawled, currently not indexed" means Google downloaded and evaluated the page, then left it out of the index for now. "Discovered" means it never got that far.

So rewriting a discovered page changes nothing Google has seen. Crawled pages are the opposite case. Google read them and passed, so resubmitting does nothing until the page itself changes.

How to fix discovered, currently not indexed

Work out which problem you have before you change anything. Go in this order, since each step rules out a cause for the next.

1. Count and group the stuck URLs.
2. Check server health in the Crawl stats report.
3. Check that internal links and sitemaps reach the pages you want.
4. Remove or block low-value URL patterns.
5. Request indexing for the few pages that matter most.

Start with scale. Open the status in the Page indexing report, export the example URLs and sort them by path.

A handful of URLs published in the last few weeks need patience. Google's recrawl docs say crawling takes days to weeks and promise nothing firmer. Confirm each one is linked and in your sitemap, then leave it.

Thousands of URLs, a count that grows every week, or pages stuck for months are a different problem. Google's crawl budget guide is written for very large sites and for sites with a large share of their URLs in this status. A store's 1,000 example URLs might group like this:

/shoes/?color=red&size=9&sort=price-asc   612 URLs
/events/calendar/2031-04/                 203 URLs
/search?q=running+shoes                   141 URLs
/products/trail-runner-x2                  44 URLs

If most of the sample is filter, search or calendar URLs, go to the low-value step. If it is mostly real products or articles, start with the server.

Is your server limiting crawl budget?

Check capacity first when real pages are stuck, since Google's own explanation for this status is server overload. Google raises a site's crawl capacity while responses stay fast and stable, and lowers it when they slow down or return 5xx errors or 429 rate limits.

Open Settings > Crawl stats in Search Console. It works only for root-level properties. Look at four things.

• Host status, which shows failures fetching robots.txt, resolving DNS or connecting to your server.
• Average response time. If it climbs as crawl requests climb, the server struggles under load.
• The breakdown by response. A steady share of 5xx or 429 tells Google to back off.
• The breakdown by purpose. If nearly every request is a refresh and almost none are discovery, new URLs are waiting behind pages Google already has.

If URL Inspection reports "Hostload exceeded" for a stuck URL, Google's guide treats that as the case where your server is the limit.

The usual causes are shared hosting that slows when bots arrive, a CDN or firewall rule that answers crawlers with 429 or a challenge page, and filter pages that each run an uncached database query. Cache HTML at the edge, answer unchanged pages with 304 Not Modified and add server resources if the business case is there. Google's guide names exactly two ways to get more crawl budget, more serving capacity and better content. Neither is a setting.

Do internal links and sitemaps reach these pages?

Every page you want indexed should be linked from pages Google already crawls and listed in a clean sitemap. A URL found only in a sitemap, or behind page 48 of an archive, looks unimportant. Link new pages from places Googlebot visits often, such as the home page, category pages and current hub articles, with plain <a href> links in the HTML. Our orphan page finder crawls up to 150 pages from your home page, compares them with your sitemap and lists sitemap pages nothing links to and pages four or more clicks deep.

Keep the sitemap to URLs you want indexed, each returning 200, canonical to itself, without noindex and with an accurate lastmod. Google's Page indexing help suggests a sitemap of only your most important pages when you want a fix picked up sooner. A sitemap that lists 40,000 filter URLs next to 300 products asks Google to crawl the wrong 40,000. Our guide to checking your sitemap covers the errors that matter.

Cut faceted filters, parameters and other low-value URLs

If most stuck URLs follow a pattern you never wanted in search, stop exposing that pattern to crawlers instead of trying to get it crawled.

Google's faceted navigation guide explains why. A crawler cannot tell a filter URL is useless until it fetches it, and every fetch spent there is one not spent on new pages. When you do not need filtered URLs in search, Google suggests disallowing the filter parameters in robots.txt:

User-agent: *
Disallow: /*?*color=
Disallow: /*?*size=
Disallow: /*?*sort=
Disallow: /search?

First make sure no page you want indexed depends on those parameters, and test a few real paths in the robots.txt tester. Blocked URLs move to "Blocked by robots.txt", which is where you want them.

Two common fixes do not save crawling. Google's crawl budget guide says a noindex page still gets requested and then dropped. A canonical tag sits inside the page, so Google has to fetch each variant to read it. Canonicals are still right for duplicates you want consolidated, which our post on duplicate without user-selected canonical covers. For removed pages, return 404 or 410. Google calls a 404 a strong signal not to crawl that URL again.

Check the export for internal search results, session and tracking parameters in internal links, calendars that page forward forever and tag archives with one post each. Fix the template that emits them, not only robots.txt.

Does Request indexing help?

It helps for a few important URLs and does nothing for a backlog of thousands. It works one URL at a time in URL Inspection, and Google's docs say individual submissions have a quota, asking again for the same URL does not speed it up, and a request does not guarantee indexing at all. For large numbers of URLs, Google points you to a sitemap.

Worth a request:

• The home page of a new site, which Google's help names as the first thing to request.
• A new product or launch page you need found this week.
• A page you just fixed, once a live test shows it loads and is indexable.

Not worth it:

• Hundreds of URLs submitted one by one. The quota runs out and the cause stays.
• Filter, parameter or archive URLs you would rather Google ignored.
• Crawled, currently not indexed pages, where Google says resubmitting is unnecessary.

Skip plugins and services that push ordinary pages through Google's Indexing API to force a crawl. Google limits that API to pages with JobPosting or BroadcastEvent markup and says it may revoke access for abuse.

Check whether a stuck page can be indexed

Before you request indexing, confirm the page will be indexable once Googlebot fetches it. Our Indexing & Canonical Checker runs those checks on one URL. It reports the HTTP status and any redirect loop, the robots.txt rule that applies to Googlebot, a noindex in meta robots or the X-Robots-Tag header, and the canonical in the HTML and Link header. It fetches the canonical target and flags one that errors, redirects, carries noindex or points on to another URL. It also reads the snippet controls Google and Bing apply, such as nosnippet, max-snippet and Bing's noarchive. Each finding names the tag or header to change, and a run costs 8 credits.

Run it on a few URLs from each pattern in your export. A stray noindex or a canonical pointing elsewhere is worth fixing before Google gets there. A clean result means the block is upstream, in capacity, links or URL volume. If your server answers the check with a 429 or a bot challenge, the report says so.

The checker reads one URL's signals as your server returns them. It cannot see Google's crawl queue, predict when Googlebot will visit or confirm that a URL is indexed, so use URL Inspection for that. It does not render JavaScript, and it is not a sitemap or full robots.txt audit.