Discovered currently not indexed: what it means and how to fix it

You published the page, submitted the sitemap, and Google still acts like it does not exist. The status in Search Console reads "discovered currently not indexed," and there is no error to fix and no button that forces the issue.

That status is not a penalty. It means Googlebot found the URL and decided not to spend crawl resources on it yet. This guide covers what causes discovered currently not indexed, how to tell it apart from "crawled currently not indexed," and the steps that actually move pages into the index.

What discovered currently not indexed means#

Discovered currently not indexed means Google knows your URL exists but has not crawled it yet, so it cannot be indexed or shown in search results.

Googlebot found the URL through your sitemap, an internal link, or an external link, and added it to the crawl queue. It then chose to wait. The page has not been fetched, rendered, or evaluated. Nothing on the page is the direct trigger, because Google has not looked at the content yet. The signal is about your site's overall crawl priority, not that one page.

This is the part most people miss. A page sitting in "Discovered" is a budgeting decision Google made about your whole domain, applied to one URL.

Discovered vs crawled currently not indexed#

The two statuses sound the same and mean different things. The difference tells you where in the pipeline the page stalled, which tells you what to fix.

• Discovered currently not indexed: Google knows the URL but has not fetched it. Usually crawl budget, weak internal links, or server load. First move: raise crawl priority through internal links and sitemap hygiene.
• Crawled currently not indexed: Googlebot fetched the page and chose not to index it. Usually content quality, duplication, or thin pages. First move: improve or consolidate the page itself.

If the page was never crawled, the content is not the problem yet. If it was crawled and dropped, the content is the problem. Treat them as two separate jobs.

Why discovered currently not indexed happens#

Google rarely tells you the exact reason per URL, but the causes cluster into a short list.

• Crawl budget. On large sites, Google caps how much it fetches per visit. Thousands of low-value URLs in the queue push your new pages back.
• Weak internal linking. A page with no internal links, or only one buried deep in the structure, reads as low priority. Orphan pages sit in "Discovered" for months.
• Server capacity. If your server is slow or returns errors under load, Google throttles crawling to avoid hurting your site. John Mueller has pointed to server capacity and overall site quality as two common reasons for this status.
• Sitemap-only URLs. A URL that exists only in the sitemap, with no internal link pointing to it, gives Google a reference but no reason to prioritize it.
• Overall site quality. If a large share of your site is thin or duplicated, Google gets cautious about crawling more of it. The new page inherits the domain's reputation.

For the URL-level signals behind these, Google's documentation on crawl budget is the primary source.

How to fix it, step by step#

Work through these in order. The early steps cost nothing and rule out the common cases.

1. Inspect the URL. Run it through the URL Inspection tool in Search Console. Confirm the page is reachable, returns 200, and is not blocked. This is your ground truth.
2. Check crawlability. Make sure the page is not blocked in robots.txt and has no stray noindex. Header-level directives are easy to miss, so check the response headers too, not just the HTML. The HTTP status tool and robots.txt validator cover both.
3. Add internal links. Link to the page from relevant, already-indexed pages that have some authority. This is the single most reliable lever for "Discovered" pages, because it raises the page's priority in the queue.
4. Clean the sitemap. Make sure the page is in the sitemap, the sitemap is valid, and it is not padded with dead or non-canonical URLs that waste crawl budget. Run it through the sitemap validator.
5. Request indexing. In URL Inspection, use "Request indexing." This works for a handful of pages, not thousands. It is a nudge, not a fix for a structural crawl problem.
6. Reduce crawl waste. On large sites, cut the number of low-value URLs Google has to wade through: parameter duplicates, faceted URLs, thin pages. Fewer junk URLs means more budget for the pages you care about.

Steps 3 and 6 are where large sites actually win. Requesting indexing is the step people reach for first and it is the weakest one.

A real report: 88% of pages out of the index#

Here is what this looks like at scale. I audited vagparts.kyiv.ua, a Ukrainian VAG car-parts e-commerce site, and the Page indexing report told the whole story in one screen.

Of all known pages, 1.17K were indexed and 8.26K were not, across nine reasons. That is roughly 88% of known URLs sitting outside the index. Two statuses carried most of the weight: 970 URLs in "discovered currently not indexed" and 2.93K in "crawled currently not indexed," both first detected back in 2022 and still open years later.

This is the classic large e-commerce pattern. A parts catalog generates thousands of near-identical URLs: filter combinations, sort orders, sparse category pages, product variants with almost the same content. Google discovers them through the sitemap and internal navigation, queues them, then declines to spend budget crawling and indexing pages it expects to be low value. The "Crawled" bucket being three times larger than the "Discovered" bucket says Googlebot did fetch a lot of these URLs and decided most were not worth keeping.

The numbers drifted down over the audit window on their own, which is normal: these reports fluctuate as Google re-evaluates the queue. The structural issue stays until the crawl waste is reduced. For a catalog this size, the fix is not requesting indexing on 8,000 URLs. It is cutting the duplicate and thin URLs so the budget flows to the pages that should rank. A site migration is one of the moments this gets worse before it gets better, which I covered in the WooCommerce domain migration write-up.

How to check index status at scale#

Search Console shows you the buckets, but checking individual URLs one by one through URL Inspection does not scale past a few pages. For a quick read on whether a specific page is in the index, a site: query against the exact URL is faster, and the Google index checker builds that query for you. Use it as a fast directional check, then fall back to URL Inspection for the authoritative answer on any single page you are troubleshooting.

Frequently asked questions#

Is discovered currently not indexed an error?#

No. It is a status, not an error or a penalty. Google found the URL and has not crawled it yet. There is nothing broken on the page to fix; the signal is about crawl priority for your site.

How long does it take to get indexed?#

It varies. New pages on a healthy site often index within a few days to two weeks. On large or low-authority sites, pages can sit in "Discovered" for months until crawl priority improves through internal links or reduced crawl waste.

Does requesting indexing fix it?#

For a few pages, it can help. For thousands of pages, it does not. Request indexing is a manual nudge for individual URLs. If a structural crawl-budget problem is the cause, you have to fix the structure.

What is the difference between discovered and crawled currently not indexed?#

"Discovered" means Google has not fetched the page yet, so the cause is usually crawl priority. "Crawled" means Google fetched it and chose not to index it, so the cause is usually content quality or duplication.

What to do next#

Start by sorting your affected URLs into the two buckets, because they are two different jobs. The "Discovered" pages need crawl priority: internal links from indexed pages, a clean sitemap, and less crawl waste competing for budget. The "Crawled" pages need a content decision: improve them, consolidate them, or let them go.

On a small site, a few internal links and a sitemap check usually clear it within a couple of crawl cycles. On a large catalog, the real work is structural, and the lever is reducing the count of low-value URLs rather than asking Google to index each one. Check the report again in two weeks and watch which bucket the numbers move out of. That tells you whether your fix matched the cause.