Quick answer
Discovered, currently not indexed means Google has found a URL, often through a sitemap or link, but hasn't crawled it yet. It isn't a penalty. Causes include crawl scheduling, weak internal links, slow servers and a flood of low-value URLs. Fix site health and discoverability, and prune waste.
Key takeaways
- The status means Google knows the URL exists but hasn't fetched it. Nothing has been judged yet, so this is a crawling story, not a quality verdict.
- Google's Search Console help says it likely planned to crawl the page and delayed the visit to avoid overloading your site, which is why no last crawl date appears.
- For most small sites, a handful of discovered URLs is normal and fixes itself. Large numbers of them point to crawl waste, slow servers or weak internal linking.
- Google's crawl budget guide says it applies mainly to very large or fast-changing sites, and it names this status as a sign that the guide may be relevant.
- The fixes are about making important URLs easy and attractive to crawl, and removing the clutter that competes for attention.
What does "Discovered, currently not indexed" actually tell you?
It tells you one thing, and it's worth being precise about it. Google knows a URL exists. It hasn't visited it. That's the whole message.
Because there's been no visit, there's been no judgement either. Google hasn't read the page, weighed its quality, compared it with other pages or decided anything about it. The status sits earlier in the process than its more famous cousin, "Crawled, currently not indexed," and it points to a different set of causes.
How does Google describe it?
Google's Search Console documentation for the page indexing report says the page was found by Google but not crawled yet. It adds that Google likely planned to crawl the page but delayed the visit to avoid overloading the site, and that because of this the report shows no last crawl date.
That second sentence is the key. It frames the delay as a courtesy to your server rather than a verdict on your page. Whether that's the whole story for your site is what the rest of this guide helps you work out.
Where to find the status
In Search Console, open Indexing, then Pages, scroll to "Why pages aren't indexed" and click "Discovered - currently not indexed". You'll see a sample of URLs and a trend chart.
How is it different from the crawled version?
The two statuses are often mixed up. The case where Google has fetched the page and decided not to include it is crawled, currently not indexed. Discovered is the stage before that: the URL is known, and the fetch hasn't happened.
| Status | Has Google fetched the page? | What it mostly reflects | First thing to check |
|---|---|---|---|
| Discovered, currently not indexed | No | Crawl scheduling, capacity, URL priority | Server health, internal links, URL clutter |
| Crawled, currently not indexed | Yes | Page value and signals | Content quality, duplication, canonicals |
Why the order matters
If Google hasn't crawled a page, no amount of content polishing will change the outcome until it does. Start at the crawl.
Why does Google find a URL and then wait?
Google doesn't crawl everything immediately. It's making constant decisions about what to fetch, when and how often, and every decision is a trade-off. Those trade-offs explain most of what you see in this report.
It helps to know the two forces at work, because Google describes them directly.
What are crawl capacity and crawl demand?
Google's crawl budget documentation, last updated on 22 July 2026, describes crawl budget as the set of URLs Google can and wants to crawl, shaped by two factors. The first is the crawl capacity limit: how much crawling your server can handle without being overloaded. It rises when a site responds quickly and consistently, and falls when responses are slow, when 5xx errors appear or when the server signals overload.
The second is crawl demand: how much Google wants to crawl your site. That depends on size, how often content changes, perceived quality and relevance. Duplicate or unimportant URLs waste crawl time, while popular and fresh content attracts more attention.
What this means in plain English
Google asks two questions. Can this server cope with more requests? And is it worth asking for more? If the answer to either is no, URLs wait in the queue.
Why does the queue grow on some sites?
Several things can fill it. A site that generates huge numbers of URLs through filters, parameters or calendars gives Google more to discover than it wants to crawl. A slow or unstable server lowers capacity. Weak internal linking means important URLs look unimportant. And a general lack of perceived value reduces demand across the board.
Often it's a mix. A shop with thousands of filter combinations on shared hosting that struggles under load is a classic case: lots of URLs, little capacity, little reason to crawl most of them.
A simple mental model
Imagine a visitor with limited time and a long list of addresses. They'll go to the most important and most reliable ones first. Everything else waits.
Does crawl budget apply to your site?
Many guides on this topic treat crawl budget as a universal concern. Google doesn't. Its own documentation draws a firm line, and it's worth reading before you invest effort.
Knowing which side of the line you're on saves a lot of wasted work.
What does Google say about who needs to worry?
The crawl budget guide says it's an advanced guide aimed at large sites with a million or more unique pages that change about weekly, medium or larger sites with ten thousand or more pages that change daily, and sites where many URLs are classified in Search Console as "Discovered - currently not indexed." It describes the numbers as a rough estimate, not exact thresholds.
For smaller or slower-changing sites, the guidance is simpler: keep your sitemap up to date and check the page indexing report. That's it. If you run a typical business site with a few hundred pages, crawl budget in the technical sense is probably not your problem.
So why do small sites see this status?
Usually because of weak linking, new pages that haven't been picked up yet, or a sudden burst of low-value URLs created by a plugin or template. These are fixable without any crawl budget theory.
How do you tell which camp you're in?
Count your real, indexable pages. Compare that with the number of URLs Google reports as discovered. If you have 400 pages you care about and 30,000 discovered URLs, the gap is the story: something is generating URLs you didn't intend. If you have 400 pages and 12 discovered, you're looking at normal scheduling lag.
A crawl of your own site, plus a look at server logs if you can get them, will show what Google is actually requesting. How the stages fit together is explained under crawling versus indexing.
Quick sizing check
Export the discovered list, group URLs by pattern and compare each group with what you want indexed. The groups with the most URLs and the least value are your first targets.
What are the most common causes?
Most cases fall into a handful of patterns. Once you recognise them, diagnosis gets faster.
Think of these as hypotheses to test, not conclusions.
Is the site generating too many low-value URLs?
This is the big one for shops and large sites. Faceted navigation can produce millions of filter combinations. Internal search pages, calendar archives, session identifiers, tracking parameters and sort orders each create new URLs that look different to Google but offer little that's new.
Google's guidance says duplicate or unimportant URLs waste crawl time. If a large share of what Google has discovered is junk, the good URLs wait behind it. Deciding what deserves a place is the heart of faceted navigation and filter indexing.
The tell-tale pattern
Long URLs with several parameters, repeating path segments or odd combinations, all in your discovered list. That's usually a crawl trap or an unmanaged filter system.
Is the server slow or unreliable?
Google adjusts its crawling to what your server can cope with. Slow responses, timeouts, 5xx errors and rate-limiting signals all reduce the crawl capacity limit. A site that struggles under load tells Google to back off, and backed-off crawling means more URLs waiting.
Check your server response times and error rates, and look at the crawl stats report in Search Console for patterns such as spikes in average response time. If you see them, performance and hosting work will help more than any SEO tweak.
Hostload warnings
Google's guidance mentions that if the URL inspection tool reports "Hostload exceeded," capacity may be your bottleneck, and adding server resources can help.
Are internal links weak or missing?
A URL that's only listed in a sitemap, with no internal links, looks unimportant. Google may discover it and see no reason to hurry. New pages buried deep in the site, linked from a single archive, face the same problem.
Strengthen the signal by linking to the page from relevant, well-linked pages, from category or hub pages and, if it matters, from navigation. This is often the cheapest fix on the list. Clear website architecture and internal links make the choice obvious.
Orphan pages
Pages with no internal links at all are the extreme case. A crawl comparing your sitemap with the pages found by following links will reveal them.
Is the sitemap telling Google the wrong things?
A sitemap stuffed with redirecting URLs, noindexed pages, error pages or duplicates dilutes the useful signal. It also wastes crawl time on URLs that can't help you. Google's guidance says to keep sitemaps current and to include accurate last-modified dates for updated content.
Review the sitemap with fresh eyes. Does every URL in it return a 200 status, resolve to itself and deserve indexing? If not, clean it up.
The lastmod habit
Only update the last-modified date when a page really changes. Inflating dates teaches Google to ignore them.
How do you diagnose it step by step?
A methodical routine beats guesswork. Work from the big picture to individual URLs, and write down what you find.
Allow an afternoon for the first pass.
What do you check at site level?
Start with the page indexing report. How many URLs are in the discovered status? Is the number growing, flat or falling? When did it change? Compare against known events: a redesign, a new plugin, a feature launch, a server move. Sudden jumps usually have a cause you can name.
Then check crawl stats in Search Console's settings. Look at total crawl requests, average response time and the breakdown by response code, purpose and file type. Rising response times or falling crawl requests are clues. Next, export the discovered list and group by URL pattern.
The grouping spreadsheet
Columns: pattern, count, should it be indexed, why or why not, action. An hour of this often explains most of the list.
What do you check at URL level?
Pick a few representative URLs from each important group. Use the URL inspection tool to see what Google knows: the discovery source, last crawl status, whether crawling is allowed and the selected canonical. Fetch the URL yourself and confirm it returns a normal 200 response, loads fast and isn't blocked.
Then look at how the URL is reached. How many internal links point to it? From which pages? Is it in the sitemap? If it's only in the sitemap and nowhere else, you've probably found part of the cause.
What the inspection tool can't tell you
It won't say why Google chose not to crawl yet. You infer that from the pattern across many URLs.
What do you check on the server?
If you can get server logs, look at what Googlebot actually requests. Which URLs does it hit most often? Which does it ignore? Does it spend lots of requests on parameters or redirects? Logs show behaviour that no report fully reveals.
Also check hosting limits, caching, rate limiting and any security tool that might be blocking or throttling crawlers. A firewall rule that slows Googlebot can quietly create a backlog.
Don't block Googlebot by accident
Security and bot-protection tools sometimes challenge or throttle crawlers. Make sure legitimate Google crawling is allowed.
What fixes actually work?
Fixes fall into three groups: reduce clutter, improve capacity and strengthen signals. Do them in that order if you're unsure.
None are magic, and all take time to show up.
How do you reduce the clutter?
Consolidate duplicates so crawling concentrates on unique pages. For URLs that should never be crawled, such as endless filter combinations or internal search results, Google's guidance recommends blocking them with robots.txt rather than noindex, because Google still has to request a noindexed page before dropping it. For pages that are permanently gone, return a 404 or 410 status. Fix soft 404s, which keep consuming crawl time.
Also tidy redirects. Long chains waste requests, so point old URLs straight to their final destinations. Remove broken internal links. The less junk in the system, the more attention the good URLs get.
A caution about blocking
Blocking in robots.txt stops crawling. It doesn't remove already-indexed pages and it stops Google seeing noindex tags. Choose the tool that matches the goal, and remember the pitfalls of pages blocked by robots.txt.
How do you improve capacity?
Make the server faster and more reliable. Improve response times, use caching, reduce heavy database queries, and make sure hosting can handle crawl traffic alongside visitors. Google's guidance mentions supporting 304 Not Modified responses, so that unchanged pages don't need to be re-downloaded in full.
If you're on cheap shared hosting and running a large site, an upgrade may be the single most effective change. It isn't glamorous, but a server that copes calmly invites more crawling.
Check after a hosting change
After any server move, confirm status codes, redirects and robots.txt are intact. Migrations are a common source of sudden crawl problems.
How do you strengthen signals for important URLs?
Link to them. From the homepage if they matter that much, from category pages, from related articles and from navigation where appropriate. Keep them in a clean, accurate sitemap. Make sure they load quickly and return clean responses. Give them reasons to be crawled sooner: fresh, useful content and links from pages that already get crawled often.
For genuinely urgent pages, the URL inspection tool's request indexing function can nudge things along. Use it sparingly, for pages that matter, and don't expect it to fix a systemic problem.
Patience is part of the fix
Google reassesses crawl behaviour gradually. After changes, give it a few weeks before judging.
What about large sites and crawl budget in the full sense?
If you run a big site, the topic gets more technical. This is where Google's detailed guidance applies, and where careful engineering pays off.
Even then, the principles are the same. They just matter at scale.
Which large-site tactics are worth it?
Control URL generation at the source, so that the system doesn't create junk in the first place. Use consistent canonicalisation. Keep sitemaps segmented and current, with accurate last-modified dates, so Google can find fresh content efficiently. Monitor server logs regularly. Prioritise internal linking to commercially important sections. Remove or consolidate thin and duplicate sections.
Large ecommerce sites often benefit from deciding, section by section, which filter combinations have real search demand and deserve to be crawlable. The rest can be kept out of the crawl path.
A useful discipline
Treat every new URL pattern as a decision. Who needs it, will searchers look for it and what's the cost of Google crawling it?
How do you monitor over time?
Track discovered and indexed counts by section, crawl requests per day, average response time and the share of crawl going to important URLs. Set alerts for sudden changes. Review after every release that touches templates, navigation or filters.
A dashboard with a handful of lines is enough. The aim is to spot a new crawl trap in days, not months. For a large site, a technical SEO consultant can cover crawl analysis and developer briefs.
Document what you learn
Keep a note of each crawl-related decision and its result. Over time it becomes a useful guide to how Google treats your site.
When should you not worry?
Not every discovered URL deserves attention. Chasing them all is a classic way to burn time.
Some are exactly where you want them.
Which discovered URLs can you leave alone?
Parameter variants that you've deliberately kept out of the crawl path. Old URLs that are redirected or removed and are slowly dropping out of Google's memory. Pagination and archive pages you don't need in the index. Test or staging URLs that slipped into discovery, provided they're properly protected. And a small, stable number of URLs that remain discovered for months without affecting anything important.
If an unimportant URL stays in this status, nothing is broken. The report isn't a to-do list. It's a diagnostic. Focus on the pages that earn or could earn business.
The relevance test
Ask: if this URL appeared in search results tomorrow, would it help a customer or the business? If not, it can stay where it is.
When is it a real problem?
When important pages, such as key service pages, product categories or high-value articles, sit in the discovered status for weeks. When the number grows steadily without explanation. When new content never seems to get crawled. When the status coincides with a fall in traffic. Any of those justifies a proper investigation.
At that point, treat it like any other technical problem: find the cause, fix it, record the change and measure the result. For help with a stubborn case, an independent SEO audit can separate site-level causes from page-level ones.
A short action plan
Export and group the URLs, identify what should be indexed, remove clutter, fix server and linking issues, clean the sitemap, request indexing for a few priority pages and recheck after a few weeks.
What does a typical case look like in practice?
Theory only goes so far, so here's a composite. It's hypothetical, built from patterns that crop up again and again, and it isn't a report on any named business.
Read it for the reasoning, not the details.
The shop with 40,000 URLs and 900 products
A small online shop notices that new products take weeks to appear in search. Search Console shows around forty thousand URLs in the discovered status and only a couple of thousand indexed. The owner assumes Google is ignoring the site and starts rewriting product descriptions.
A crawl tells a different story. The shop has nine hundred real products. The rest of the URLs come from filter combinations for colour, size, price band and sort order, all linked from every category page. Each combination is technically a separate URL. Google found them, queued them and is working through them slowly, while the new products wait.
What fixed it
The shop's developer stopped the filters generating crawlable links for low-value combinations, blocked the worst offenders from crawling, tightened canonical tags and cleaned the sitemap down to real products and categories. New product pages were linked from the homepage and the relevant category for their first weeks. Over the following weeks the discovered count fell and new products started appearing in the index much faster. Nothing about the copy had to change.
The consultancy site with three stuck pages
A professional services firm publishes a new service page. After a month it's still discovered, not indexed. The site is small, fast and healthy, so crawl budget isn't the issue. The problem turns out to be that the page is only linked from the sitemap and from a footer link added late. No relevant page points to it.
What fixed it
The team linked the page from two related service pages, the main services menu and a recent article, using clear anchor text. They also requested indexing for that one URL. It was crawled within days. The lesson: small sites rarely have crawl budget problems, but they often have internal linking problems that look identical in the report.
How do you tell whether your fixes worked?
Fixing is half the job. The other half is proving it, because crawl changes happen slowly and quietly, and it's easy to fool yourself.
Set up simple measurements before you change anything.
Which metrics should you track?
The number of URLs in the discovered status, split by pattern. The number of important URLs indexed. The average time between publishing a page and seeing it crawled. Crawl requests per day and average response time from the crawl stats report. And the share of crawl requests going to URLs you actually want indexed, if you have logs.
Record each figure before the change, note the date of the change, and check again after two, four and eight weeks. A rolling record beats a memory.
What success looks like
The discovered count for unwanted patterns falls or stabilises. New important pages get crawled faster. Response times improve. And, over time, more of your valuable URLs move into the index.
What if nothing changes?
Check that your changes actually shipped and are live. Check that you haven't introduced a conflicting signal, such as a robots.txt rule blocking the very section you wanted crawled. Then review whether the cause you assumed was the real one. It's common to find that two causes were overlapping, and fixing one revealed the other.
If you've done the sensible things and important pages still sit in the discovered status after a couple of months, consider a deeper look at server logs and quality signals. At that point, an independent technical review can save a great deal of guesswork.
A final reminder
Discovered, currently not indexed is information, not an accusation. Treat it as a hint about where Google's attention is going and use it to steer that attention toward what matters.
How can you get new content crawled faster?
If you publish regularly, the practical question is how quickly Google gets round to your new pages. You can't command it, but you can make it easier.
Think of it as laying a clear path from places Google already visits often to the thing you've just published.
What helps a new page get noticed?
Link to it from pages that are crawled frequently: the homepage, key category pages, popular articles. Add it to your sitemap with an accurate last-modified date as soon as it goes live. Make sure it returns a clean 200 response, loads quickly and isn't blocked by robots.txt or a stray noindex tag. Use a clear, descriptive URL and title so the page is easy to understand on first contact.
For high-priority pages, use the URL inspection tool to request indexing once the page is live and linked. It's a nudge, not a guarantee. Google's own documentation is careful to say that submitting a sitemap or requesting a crawl doesn't guarantee a page will be crawled or indexed.
The first-week routine
Publish. Link from two or three strong pages. Check the sitemap. Inspect the URL. Then leave it alone for a week, and look at Search Console again.
Does publishing more often help?
Sometimes. Sites that update regularly with useful content tend to be crawled more often, because Google's crawl demand reflects how frequently content changes and how valuable it seems. But publishing lots of thin pages usually backfires, since it grows the pile of low-value URLs and dilutes attention.
A steady rhythm of genuinely useful pages beats bursts of filler. If you can only produce one strong page a week, that's a better signal than five weak ones.
Quality is a crawl signal too
Google's guidance links crawl demand to perceived quality. Pages that earn links, engagement and mentions are likely to be revisited sooner. That's one more reason to focus on pages worth reading.
What about very new websites?
New sites start with no history, few links and no reason for Google to trust their crawl requests. Expect a slow start. Early on, make it easy: a tidy structure, a clean sitemap, a few genuine links from other sites, and a small number of strong pages rather than a sprawling launch.
It can take weeks for a new site's pages to be crawled at a sensible pace. That doesn't mean something is wrong. It means Google is still learning about you. Be patient, keep the site healthy and build from there.
A realistic expectation to set with your team
Tell colleagues that "published" and "crawled" aren't the same moment. A new page may take days or weeks to be fetched, and longer to settle in the results. Building that gap into your launch calendar avoids needless panic, and it stops people asking for indexing requests on every single page. When something is urgent, plan for it: publish earlier, link it well and check the page indexing report rather than guessing.
Frequently asked questions
Is "Discovered, currently not indexed" bad for SEO?
Not necessarily. It means Google knows about the URL but hasn't crawled it yet. A few such URLs are normal. If important pages stay in this state for weeks, or if thousands pile up, it suggests crawl scheduling, server capacity, internal linking or URL clutter problems worth investigating.
How long do URLs stay in the discovered status?
It varies from hours to months. Google decides when to crawl based on your server's capacity, how much it wants to crawl your site, and how important it considers each URL. Well-linked, useful pages on a healthy site tend to move on quickly. Low-value URLs may sit there indefinitely.
Should I request indexing for discovered URLs?
You can request indexing for a few genuinely important pages, but it won't fix a systemic cause. If many URLs are stuck, work on internal links, server speed, sitemap quality and URL clutter instead. Repeated manual requests mostly create busywork without changing Google's crawl priorities.
Does this status mean my server is too slow?
It can. Google's crawl guidance says crawl capacity depends on how quickly and reliably your server responds, and that errors or slowdowns reduce crawling. If discovered URLs are widespread and server response times are poor, hosting or performance work may help. Check crawl stats and server logs.
Do small websites need to worry about crawl budget?
Usually not. Google's guidance says the full crawl budget guide is aimed at very large sites or those that change often, and that smaller sites mainly need to keep sitemaps current and check the page indexing report. For small sites, the cause is more often weak linking or low-value URLs.