"Discovered – currently not indexed": causes and fixes

"Discovered – currently not indexed" means Google knows the URL exists, usually from a sitemap or a link, but hasn't crawled it yet. Google's own explanation is that crawling was postponed, often because it expected the site to be overloaded. In practice the common causes are a slow or erroring server, too many low-value URLs competing for crawl time, weak internal linking and a new site Google doesn't crawl often yet.

What does "Discovered – currently not indexed" mean?

The URL is known but unvisited. Search Console shows "Last crawl: N/A" for these pages in URL Inspection, which confirms Googlebot never fetched them. Since Google hasn't seen the content, this status says nothing about quality. It's a crawling problem, not a content problem.

That's the key difference from "Crawled – currently not indexed", where Google did fetch the page and decided against it.

Why does Google postpone crawling?

Googlebot decides how much to crawl on each site based on two things: how much your server can take without slowing down, and how much Google wants to crawl your content. When either one is low, URLs wait.

Your server looks like it can't keep up

If responses get slow or you return 5xx errors and timeouts, Googlebot reduces its crawl rate to avoid hurting the site. Fewer requests per day means new URLs wait longer. Shared hosting, heavy pages and aggressive bot protection that challenges Googlebot are the usual suspects.

Too many URLs compete for crawl time

Faceted navigation, sort parameters, session IDs, tag pages and endless calendars can generate far more URLs than you have real pages. Google discovers them, queues them and spends its time on duplicates while your new article waits.

The page doesn't look important

A URL that appears only in the sitemap, or is linked once from a page five clicks deep, gets low priority. Internal links are how you tell Google what matters on your site.

The site is new or rarely crawled

A fresh domain with few links has a small crawl budget by default. Publishing thousands of pages on day one means most of them will sit in the queue for a while.

Google's view of the site as a whole

If much of what Google already crawled on your site turned out to be thin or duplicate, it has less reason to rush for more. This is where the two statuses connect: a lot of "Crawled – not indexed" can lead to a lot of "Discovered – not indexed".

How to fix it, step by step

1. Check server health. Open Settings → Crawl stats in Search Console. Look at average response time, the share of 5xx responses and whether "host status" shows problems. Fix slow responses and errors before anything else.
2. Make sure Googlebot isn't being blocked or challenged by a firewall, a CDN rule or rate limiting. A bot check that real Googlebot can't pass looks like an outage to Google.
3. Cut URL bloat. Find parameter and filter URLs in the crawl stats and the "Discovered" list itself. Block worthless patterns in robots.txt, remove links to them and keep them out of the sitemap.
4. Clean the sitemap. Keep only canonical, indexable URLs that return 200. Remove redirects, 404s and noindexed pages. Use honest lastmod dates.
5. Link to the waiting pages. Add links from your homepage, category hubs and related articles. Fix orphan pages that exist only in the sitemap.
6. Publish at a pace the site can support. On a new domain, a steady flow of good pages gets crawled more reliably than a single dump of thousands.
7. Request a crawl for the important URLs. Use URL Inspection for a few key pages and bulk submission for the rest.

Does submitting the URLs help here?

This is the status where a crawl request makes the most sense. Google hasn't seen the page, so there's no previous verdict to overturn. Pushing the URL forward in the queue is exactly what's missing.

Two caveats. First, it won't fix the underlying cause: if your server is struggling or the site is full of junk URLs, new pages will keep piling up. Second, only send pages that can actually be indexed. @IndexForgeBot checks every link first and drops 404s, redirects, noindex pages, robots.txt blocks and URLs with a canonical pointing elsewhere, so you're not paying to queue pages that would be rejected anyway.

How to see what's eating your crawl time

The Crawl stats report (Settings → Crawl stats) is the most useful screen for this status, and few people open it. Four breakdowns matter:

Click into each group to see example URLs. Patterns jump out quickly: thousands of ?sort= variants, an old section that 404s, a calendar that generates a page for every day until 2099. Each pattern you shut off frees crawl time for the pages you actually want indexed.

If you have access to server logs, filter them by Googlebot's user agent (and verify the IPs) for an even more precise picture of which URLs get visits and which never do.

How many "Discovered" URLs are normal?

Some are always there. Google rarely crawls every URL it finds, and big sites always have a backlog. What matters is the trend and what's in the list.

• If the list is mostly parameter URLs and junk, the fix is cleanup, and your real pages may be fine.
• If the list is full of your new articles or products, crawl priority is the issue.
• If the number grows every week while indexed pages stay flat, Google is finding URLs faster than it wants to crawl them.

How long until the pages move?

Once server problems are fixed and bloat is reduced, crawl activity can pick up within days to a few weeks. You'll see it first in the Crawl stats report as more requests per day, then in URL Inspection as a "Last crawl" date appearing on the waiting pages, and finally in the indexing report, which lags behind both.

Checklist

• Average response time is low and stable in Crawl stats
• Few or no 5xx errors and timeouts
• Googlebot isn't blocked or challenged by the firewall or CDN
• Parameter and filter URLs are kept out of the crawl
• Sitemap contains only canonical, indexable 200 URLs
• Every waiting page is linked from indexed pages
• Crawl requested for the pages that matter most

Common questions

Should I remove "Discovered" URLs from the sitemap?

Only the ones you don't want indexed. If a URL is canonical, indexable and useful, keep it in the sitemap and work on crawl priority instead. Removing good URLs just hides the problem.

Can a CDN or "under attack" mode cause this?

Yes. If the protection challenges or slows Googlebot, Google sees an unreliable host and crawls less. Allow verified search engine bots and watch the Crawl stats report after any change.