Discovered – currently not indexed is a status in the Page indexing report of Google Search Console meaning that Google knows the URL exists but has not crawled it yet, so the page cannot be indexed or shown in search results. In indexing, it marks the stage between discovery, usually through a link or an XML sitemap, and the first actual fetch of the page by Googlebot.
The status is a scheduling outcome, not an error. Google has decided to postpone the crawl, typically because fetching more URLs from the site at that moment seemed unnecessary or likely to strain the server. A few such URLs are normal; a large and growing share signals a problem with crawl demand, site quality or URL volume.
Why Google discovers a URL but does not crawl it
Search engines separate discovery, crawling and indexing. Discovery adds a URL to a list of known addresses. Crawling fetches its content. Indexing analyzes the content and decides whether to store it for retrieval. A URL with this status has passed only the first step, which is why the last crawl date appears as not available in URL inspection.
Google balances two factors when scheduling crawls. Crawl capacity reflects how many requests the server can handle without slowing down. Crawl demand reflects how valuable and fresh Google expects the URLs to be. When demand for a group of URLs is low or capacity is constrained, they wait in the queue.
The following table maps the most common root causes to the evidence that usually reveals them.
| Cause | Mechanism | Typical evidence |
|---|---|---|
| Low perceived value | Similar pages on the site were judged weak | Many affected URLs share one template |
| Excessive URL volume | Faceted filters or parameters create endless variants | Huge counts of near-duplicate URLs |
| Server limits | Slow responses or errors reduce crawl capacity | High response times in crawl stats |
| Weak internal linking | Pages linked only from deep or rare locations | Orphan or near-orphan pages |
| New site or section | Little history to estimate demand | Status clears gradually over weeks |
How it differs from related indexing statuses
This status is often confused with its neighbor Crawled – currently not indexed. The difference matters because the two point to different stages of the pipeline and therefore to different fixes.
| Status | Crawled | Main meaning |
|---|---|---|
| Discovered – currently not indexed | No | Crawl postponed by Google |
| Crawled – currently not indexed | Yes | Content fetched but not selected for the index |
| Excluded by noindex tag | Yes | Site explicitly asked not to index |
| Blocked by robots.txt | No | Site disallowed crawling |
| Duplicate without user-selected canonical | Yes | Another URL chosen as canonical |
Unlike a block by robots.txt or a noindex directive, nothing on the site prohibits crawling. The decision rests entirely with the search engine, which is why the remedy is to raise the value and accessibility of the URLs rather than remove a technical barrier.
Diagnosing the status at scale
Diagnosis starts with grouping the affected URLs by directory, template or parameter pattern from the report export. A status that affects one product filter or a tag archive tells a different story than one spread evenly across the site.
Next, compare the pattern with the Crawl stats report and server logs. Rising response times, frequent 5xx errors or host availability problems point to capacity limits. Healthy server metrics combined with millions of parameter URLs point to index bloat and wasted crawl demand. Checking whether affected URLs appear in the sitemap and receive internal links completes the picture.
It also helps to track the trend rather than the snapshot. A count that rises after a launch and then falls steadily is a healthy sign of a crawl queue being worked through. A count that keeps growing month after month, while the number of indexed pages stays flat, indicates that the site is producing URLs faster than Google considers them worth fetching.
Sampling is often more informative than bulk statistics. Inspecting twenty or thirty representative URLs by hand, and asking whether each one deserves to rank on its own, quickly shows whether the backlog consists of valuable pages that are hard to reach or of variants that should never have been exposed to crawlers.
Fixing a large number of affected URLs
The most effective fixes reduce noise and raise the importance of the pages that deserve indexing. Requesting indexing manually in the URL Inspection tool helps for a handful of key pages but is limited by a daily quota and does not address the cause.
| Situation | Remedy | Expected effect |
|---|---|---|
| Endless filter and parameter URLs | Restrict crawling of low-value variants | Crawl demand focuses on real pages |
| Thin or duplicate pages in bulk | Consolidate, improve or remove them | Higher perceived site quality |
| Important pages deep in the site | Add prominent internal links | Stronger importance signals |
| Slow or unstable server | Improve response time and capacity | Higher crawl capacity |
| Sitemap lists every URL indiscriminately | List only canonical, indexable pages | Clearer priorities for the crawler |
Changes take effect over weeks rather than days, because Google must recrawl the site, observe the improvement and recalibrate its expectations.
Priorities matter when resources are limited. Fixing crawl waste first usually pays off fastest, because every request Google no longer spends on useless variants becomes available for the pages that genuinely need indexing.
Misreadings and mistakes to avoid
Because the status sounds alarming, it often triggers counterproductive reactions. The following mistakes are the most frequent.
- Treating every listed URL as a problem: many are redirect targets, old parameters or low-value pages that should never be indexed.
- Mass indexing requests: submitting hundreds of URLs through inspection does not scale and ignores the underlying cause.
- Blocking with robots.txt to clean the report: this can stop Google from seeing canonical or noindex signals on those pages.
- Adding more URLs to fix coverage: generating extra tag or location pages usually deepens the backlog instead of clearing it.
Put simply
This status means Google has seen the address of a page but has not visited it yet. Imagine a reviewer with a long reading list. The reviewer knows a book exists but keeps postponing it, because other books seem more interesting or because the library is too busy.
Until Google actually visits the page, it cannot appear in search results. The cure is to make the page clearly worth visiting and easy to reach, and to remove clutter that crowds the list.
In practice
A travel booking site launches 40,000 new hotel pages and, a month later, sees most of them listed as discovered but not indexed. Crawl stats show healthy response times, but the logs reveal that Googlebot spends most requests on sorting and date parameters that create millions of URL variants.
The team blocks crawling of the sort and date parameters, removes them from internal links, keeps only canonical hotel URLs in the sitemap and links the most popular hotels from city pages. Over the following six to eight weeks, the number of affected hotel pages falls steadily, and the newly indexed pages begin to receive organic traffic for hotel-name searches.