Skip to content
TurboIndex

Discovered - Currently Not Indexed: How to Fix It

Discovered - currently not indexed means Google knows your URL but has not crawled it yet. See why crawling gets postponed and how to move pages up the queue.

August 27, 20267 min read

"Discovered - currently not indexed" means Google knows the URL exists but has not fetched it yet. The page has not been judged, because Google has not looked at it. Google's documentation explains that typically it wanted to crawl the URL but expected this to overload the site, so it postponed the crawl. In practice the status comes down to priority: Google has a queue for your site, and these URLs are near the back.

The fix is to give Google reasons to move them forward and to remove whatever is slowing the queue down.

How to recognise it

Inspect one of the affected URLs in Search Console. Under Page indexing you will see:

  • Discovery: the sitemaps and referring pages where Google found the URL (sometimes empty).
  • Crawl > Last crawl: "N/A". This is the telltale sign. Google has never fetched the page.

Because there was no crawl, anything that depends on page content is not the cause. Your title tag, word count, schema markup and canonical tag are irrelevant to this status, since Google has not seen them. That saves you a lot of pointless editing.

Why Google postpones the crawl

Google decides how much to crawl a site using two things it describes in its crawl budget documentation: the crawl capacity limit (how much fetching your server can take without problems) and crawl demand (how much Google wants the URLs, based on popularity, staleness and perceived value). "Discovered" URLs are the ones that lose on one or both.

Low crawl demand

  • No or few internal links. A URL found only in the sitemap has nothing vouching for it. This is the single most common cause on small and medium sites.
  • The URL pattern has a poor track record. If Google crawled 500 of your tag pages and indexed almost none, it has little appetite for the next 5,000.
  • New site, no reputation. Google crawls unfamiliar hosts cautiously. A new domain that publishes 10,000 pages on day one will see most of them parked here.
  • URL inventory bloat. Faceted navigation, sort parameters, session IDs, calendar archives and internal search pages multiply URLs. Real pages wait behind them.

Limited crawl capacity

  • Slow responses. When average response time climbs, Google lowers the crawl rate.
  • Server errors. A rising share of 5xx or 429 responses, or timeouts, makes Googlebot back off.
  • Shared or throttled hosting and aggressive bot protection that rate limits Googlebot.

Check the Crawl stats report

Go to Settings > Crawl stats > Open report. This is the best evidence you have.

What to look at Healthy Warning sign
Total crawl requests Stable or rising with site growth Sudden drop, or flat while you add pages
Average response time Low and steady Climbing, or spikes that line up with crawl drops
Host status No issues in the past 90 days Problems with robots.txt fetch, DNS or server connectivity
By response Mostly OK (200) Noticeable share of 5xx, 404 or redirects
By purpose A mix of discovery and refresh Almost all refresh, meaning Google is rechecking old URLs and not fetching new ones
By file type and example URLs Mostly HTML pages you care about Crawl spent on parameters, feeds, JSON endpoints

If response time and errors look fine, your problem is demand, not capacity. That is the usual situation for sites under a few tens of thousands of URLs. Google itself says crawl budget is mostly a concern for very large or very frequently updated sites, so on a small site, stop blaming the server and look at links and quality.

Fixes that move the needle

For each important "discovered" URL, ask where a crawler would find it by following links from the homepage.

  • Add links from relevant, already indexed pages in the body content, not only in a footer list.
  • Make sure hub pages (categories, topic indexes) link to every child page with plain <a href> links. Infinite scroll and "load more" buttons without real paginated URLs hide everything after the first batch.
  • Add "related" or "latest" modules that surface new pages from high traffic pages.
  • Keep depth low. Pages five or more clicks from the homepage get crawled late.

You can see exactly which links a page exposes to a crawler with the page link extractor. The approach is described in internal linking for indexing.

2. Cut the junk from Google's queue

Every low value URL Google knows about competes with the good ones.

  • Block crawl traps in robots.txt: internal search, endless filter combinations, sort orders.
User-agent: *
Disallow: /search
Disallow: /*?sort=
Disallow: /*&sort=
Disallow: /*?filter=
  • Stop linking to parameter URLs where you can, and keep them out of the sitemap.
  • Return 404 or 410 for pages that are gone for good. Google's crawl budget guidance notes that soft 404 pages keep getting crawled and waste budget.
  • Remove long redirect chains.

Test rules before deploying them with the robots.txt tester, because a wrong wildcard can block the pages you are trying to rescue.

3. Clean up the sitemap

A sitemap full of redirects, 404s, noindexed pages and duplicates teaches Google that your sitemap is unreliable. Keep it to canonical, indexable, 200-status URLs with honest <lastmod> values. Splitting a large sitemap by section (products, categories, blog) also lets you filter the Page indexing report per sitemap and see which section is stuck. See sitemap index files for large sites.

4. Make the server faster for Googlebot

  • Cache HTML for anonymous requests at the CDN or application level.
  • Fix slow database queries on the templates Googlebot hits most.
  • Make sure your WAF or bot manager verifies and allows real Googlebot. Google publishes its crawler IP ranges and supports reverse DNS verification for this purpose.
  • Do not answer load problems with long-running 503 or 429 responses. Google's documentation says these reduce crawl rate, and URLs that keep returning them for an extended period can be dropped from the index.

5. Raise the quality of what is already crawled

This one is indirect but real. If a big share of the pages Google has already crawled ended up as Crawled - currently not indexed, Google has little reason to fetch more of the same. Improving or pruning that set is often what finally releases the "discovered" backlog.

6. Request indexing for the few that matter most

Use URL Inspection > Request indexing for priority pages. It is a manual tool with a daily quota, fine for ten URLs and useless for ten thousand. Treat it as a way to get key pages crawled while the structural fixes take effect.

What not to do

  • Do not rewrite the content. Google has not read it.
  • Do not resubmit the sitemap daily. Google already knows the URLs. Discovery is not your problem.
  • Do not change the URLs hoping to re-enter the queue. You create redirects and start again from a worse position.
  • Do not add noindex to the stuck pages "temporarily". If Google does crawl them, you will have told it to drop them.
  • Do not publish faster than you get indexed. If 3,000 of 5,000 pages are waiting, adding 5,000 more makes the queue longer, not shorter.

What to expect after fixing

Crawl scheduling reacts slowly. After linking and cleanup work, watch these over four to eight weeks:

  1. Crawl stats: total requests trending up, and "discovery" taking a larger share of crawl purpose.
  2. Page indexing report: the "Discovered" count falling. Some of those URLs will move to "Crawled - currently not indexed" first. That is progress, since Google is now fetching them, and it tells you the next thing to work on.
  3. URL Inspection on samples: a real date under "Last crawl".

For big sites, tracking a sample by hand is tedious. TurboIndex pulls the index status of every sitemap URL through the URL Inspection API (Google allows 2,000 inspections per property per day) so you can see how many URLs leave the "discovered" state each week, and the indexing time calculator gives a realistic idea of how long a full pass takes at Google's quotas.

Small site, new site: the honest answer

If your site has 50 pages, launched last month and most of it is "Discovered - currently not indexed", you most likely do not have a crawl budget problem. You have a new site that Google does not yet have much reason to visit. Verify there are no blockers, submit the sitemap, link the pages together, get a few genuine external links, request indexing for the key pages, and give it a few weeks. If nothing has moved after that, work through why is my page not indexed.

Frequently asked questions

What does Discovered - currently not indexed mean?
Google has found the URL, usually through a sitemap or a link, but has not crawled it yet. Google's help page says that typically it wanted to crawl the URL but this was expected to overload the site, so the crawl was rescheduled. That is why the last crawl date is empty in the report.
How long does Discovered - currently not indexed last?
It varies from days to many months. On small, healthy sites the status often clears within a few weeks as Google works through the queue. On large sites with many low value URLs, pages can wait indefinitely until internal linking, server performance or overall site quality improves.
Does this status mean my content is low quality?
Not directly, because Google has not fetched the page and cannot have judged it. It can however reflect how Google rates the site overall or the URL pattern. If earlier pages of the same type were crawled and rejected, Google has less reason to hurry to crawl more of them.
Can I force Google to crawl a discovered URL?
You can ask. Request indexing in the URL Inspection tool puts a URL in a priority queue, subject to a daily quota, and it often works for single pages. It does not scale to thousands of URLs, and it does not address why Google was reluctant to crawl them in the first place.

Keep reading