“Discovered, currently not indexed” means Google knows a URL exists, usually from a sitemap or a link, but has not crawled it yet. Google typically rescheduled the crawl to avoid overloading your server. On a small site, it often clears by itself. On a larger one, fix crawl waste, internal links and server speed.
Server and page speed shape how much Google is willing to fetch, and most sites have room to improve: the 2024 Web Almanac found 43% of websites had good Core Web Vitals on mobile once INP replaced FID, down from 48% under the old FID measure.
What the status actually says
The Page indexing report lists this status among the reasons a URL is not in the index. Google’s Page indexing report help page describes it as a page that was found by Google but not crawled yet. Typically, Google wanted to crawl the URL but expected this to overload the site, so it rescheduled the crawl.
Notice what is missing from that sentence: any judgement about your content. Google has not seen the page, so it cannot have decided it is thin, duplicated or unhelpful. That is the key difference from the sister status, which I explain in crawled, currently not indexed. With crawled, Google read the page and passed. With discovered, Google has not read it at all.
It follows that the fix is about getting Google to the page, not improving the page’s text. Although, as you will see, the quality of the pages around it affects how willing Google is to come.
Why Google postpones a crawl
Google’s guide to managing crawl budget for large sites breaks the idea into two parts that I find useful when diagnosing this status.
| Concept | What it means | What influences it |
|---|---|---|
| Crawl capacity limit | The most Google will fetch without straining your server, limiting the total time your server spends holding connections open for Google | Server speed and error rates. Faster, healthier responses raise the limit; slowdowns and errors lower it. |
| Crawl demand | How much Google wants to crawl your URLs | Perceived inventory (including duplicate or unwanted URLs), how popular the pages are, and how stale the content is |
A queue of discovered but uncrawled URLs appears when demand outruns capacity, or when Google has been given far more URLs than it considers worth fetching. The first is a hosting problem. The second is an inventory problem, and it is more common than people expect.
Not sure if this is hurting your site?
Get the fixes that matter most, in priority order.
Do you need to worry? A size check
Google says crawl budget management is aimed at large sites with 1 million or more unique pages whose content changes about once a week, medium or larger sites with 10,000 or more unique pages that change daily, and sites with many URLs marked as discovered, currently not indexed. It also says smaller sites whose pages get indexed the same day generally do not need to optimise for it.
That gives a practical rule:
- A handful of URLs on a small site. Most likely recently published pages in the queue. Make sure they are linked from somewhere sensible and check again later.
- A growing pile on a small site. A sign that something is generating junk URLs, or that the server is slow or erroring. Investigate.
- Thousands of URLs on a large site. This is the situation the crawl budget guidance is written for. Work through the full list below.
Wait or act? A decision table
| What you see | Likely meaning | Action |
|---|---|---|
| Pages published in the last few days or weeks | Normal queue time | Confirm internal links exist; revisit in a couple of weeks |
| Important pages stuck for months | Low priority signals or too much competing inventory | Add internal links, trim junk URLs, check server speed |
| Thousands of parameter or filter URLs | Wasted crawl on near-infinite combinations | Reduce them at source; block crawling where appropriate |
| Status appears alongside server errors or timeouts | Capacity limit has been lowered | Fix hosting and errors first |
| URLs you never wanted indexed | Not a problem | Remove them from sitemaps and internal links; ignore the rest |
A fix workflow, in the order I would do it
- Export the affected URLs and sort them into groups. Look at folders and patterns: product pages, filtered listings, old blog posts, parameters. The pattern usually points to the cause within minutes.
- Remove what should not be there. Faceted navigation, session IDs, internal search pages and duplicate versions inflate the inventory Google sees. Google’s guidance is to consolidate duplicate content and to use robots.txt, not
noindex, to stop crawling of pages you do not want fetched, because a noindex tag only works after Google has crawled the page. - Clean the sitemap. It should contain only canonical, indexable URLs that return a 200 status. Google also recommends keeping sitemaps updated and using the last-modified tag for pages that have genuinely changed. A sitemap full of redirects and dead URLs teaches Google to trust it less.
- Return the right status codes. Removed pages should return 404 or 410, and pages that look empty but return 200 should be fixed. Google lists soft 404 errors as a source of crawl waste; see my guide to soft 404 errors for how to find them.
- Improve server response. Faster responses lift the crawl capacity limit. Look at hosting, caching, heavy plugins and slow database queries. If you see timeouts or 5xx errors in your server logs, fix those before anything else.
- Link to the important URLs. A page with strong internal links from popular pages is crawled more readily than one buried five clicks deep. The internal links section of the Search Console links report shows which of your pages have few or no internal links.
- Inspect a sample. Use the URL Inspection tool on a few affected URLs to see how Google discovered them and when, if ever, it last crawled them.
Why requesting indexing is rarely the answer
It is tempting to paste URLs into the inspection tool and press the request button. For a few new, important pages, that is reasonable. As an approach for hundreds of URLs it fails for two reasons. Requests have a daily limit per property, and more importantly, they do not change the underlying reasons Google deprioritised the URLs. If the inventory is bloated or the server is struggling, the queue refills.
I treat a manual request as a nudge for one or two high-value pages, never a fix.
An illustrative example
Imagine a Karachi electronics store whose category pages allow filtering by brand, price, colour and rating, so the site can generate tens of thousands of URL combinations. The sitemap lists the real products, but the filter links are crawlable, so Google discovers far more URLs than the shop has products. Many sit in the discovered queue. The sensible fix is to stop the filter combinations from being crawled, keep the sitemap to real product and category pages, and make sure each product is linked from its category. This is an invented scenario to illustrate the reasoning, not a client result.
The wider lesson sits in my index bloat guide: the cleaner the set of URLs you offer, the more attention each of them gets.
How to tell whether it is working
Watch three things over several weeks. First, whether the count in this status falls or stops growing. Second, whether your priority pages are leaving the status and appearing in the report as indexed. Third, whether your server errors and response times improve. Do not expect an instant change; Google reschedules according to its own estimate of your server’s health and your site’s value, and that estimate updates slowly.
When a fix involves several groups of URLs, you can ask Google to validate it from the report. Google says validation typically takes up to about two weeks, though it can take much longer. Group your changes first, then validate once.
To see how these indexing statuses fit into a wider review, my overview of the Search Console coverage report explains each one, and what a professional SEO audit includes shows where crawl and indexing checks sit alongside everything else.
Questions people ask about discovered, currently not indexed
Is it a problem if a new page shows this status?
Not by itself. New pages commonly spend time in the queue. If an important page is still there after several weeks, check that it is linked internally, that the server is responding quickly and that it is not buried among a pile of low-value URLs.
Does this mean my content is bad?
Not necessarily. Google has not crawled the page, so it has not assessed the content. The status is about scheduling and priority. That said, a site with lots of thin or duplicate pages gives Google less reason to hurry, so content quality still affects how quickly pages are fetched.
Should I use noindex on pages in this status?
Only if you truly never want them indexed. Noindex works after a page is crawled, so it does not reduce crawling of URLs Google has not yet fetched. To stop crawling, use robots.txt or, better, stop linking to those URLs.
Can a slow server cause this?
Yes. Google’s description of the status says the crawl was rescheduled to avoid overloading the site, and its crawl budget guidance says server speed and errors affect the crawl capacity limit. Faster, more stable responses allow more crawling.
If your report shows a large and growing queue and you are not sure whether it is the server, the sitemap or the site structure, I can check it as part of my SEO audit services. Ask for a free audit and I will tell you what I find.
More in this series (SEO measurement and Search Console): start with What a Professional SEO Audit Includes (and Red Flags), then explore:
Request received
Thank you! Saad will contact you within the next 24 hours.
Keep an eye on your phone and inbox.