TechEarl

Discovered vs Crawled - Currently Not Indexed in Search Console

What 'Discovered - currently not indexed' and 'Crawled - currently not indexed' actually mean in Google Search Console, why they are usually normal, and why spamming Request Indexing does nothing.

Ishan Karunaratne⏱️ 9 min readUpdated
Share thisCopied
What 'Discovered' and 'Crawled - currently not indexed' mean in Search Console, why they are usually normal, and why requesting indexing repeatedly does nothing.

Two of the most-misread statuses in Google Search Console's Page Indexing report are "Discovered - currently not indexed" and "Crawled - currently not indexed". They sound like errors. They drive people to click Request Indexing fifty times, buy "instant indexing" services, and worry about a penalty. In most cases they are none of those things. They are Google telling you, in its own quiet way, that it knows about a URL and is not, for now, indexing it (in one case because it has not crawled the URL yet, in the other because it crawled it and held off).

The difference between the two is one word: crawled. "Discovered" means Google has found the URL but has not fetched it yet. "Crawled" means Google fetched it and chose not to index it. That single distinction changes what (if anything) you should do, and this article walks through what each means, what Google itself says about them, and which of the popular "fixes" actually move the needle versus just burning your afternoon.

What each status actually means

Google's Page Indexing report documentation defines them precisely.

Discovered - currently not indexed:

The page was found by Google, but not crawled yet. Typically, Google wanted to crawl the URL but this was expected to overload the site; therefore Google rescheduled the crawl.

Crawled - currently not indexed:

The page was crawled by Google but not indexed. It may or may not be indexed in the future; no need to resubmit this URL for crawling.

Google Search Console Page Indexing report showing two rows, 'Discovered - currently not indexed' and 'Crawled - currently not indexed', each with a URL count, under the 'Why pages aren't indexed' section
Both statuses live under 'Why pages aren't indexed' in the Page Indexing report. Neither is an error row; they are reasons, and Google's own note on Crawled says 'no need to resubmit'.

Put plainly:

  • Discovered is a crawling decision. Google has the URL in its queue but has not spent the crawl on it, often because fetching more right now risks overloading your server, or because it has not judged the URL worth the trip yet.
  • Crawled is an indexing decision. Google already spent the crawl, looked at the page, and decided it does not currently merit a spot in the index, usually a signal about the page's (or the site's) quality and uniqueness.

That is why the right response differs. For Discovered, you sometimes have a crawl-health or internal-linking problem to fix. For Crawled, no amount of re-submitting matters, because crawling is not the blocker; the indexing judgment is.

What Google actually says about them

John Mueller of Google has addressed these statuses many times, and the throughline is consistent: not indexing every page is normal, and where a page you care about is affected, the lever is usually the whole site's quality and structure rather than that one URL.

On a URL stuck in "Crawled - currently not indexed" (Twitter, 2021):

it's normal that we don't index all pages on all websites. It's not an issue with 'that page', it's more site-wide.

On how long "Discovered - currently not indexed" can persist (Google Search Central office hours, February 2022):

That can be forever. It's something where we just don't crawl and index all pages.

And on what actually changes it (Twitter, November 2021):

It basically means you need to convince Google that it's worthwhile to index more.

The uncomfortable but useful summary: these are not bugs to file or buttons to press. They are mostly about whether Google sees enough value to index more of your site, and for large sites, partly a limit on how hard Google can crawl you without knocking the server over. Mueller has also cautioned that "Crawled - currently not indexed" is not a precise low-quality flag, so treat it as a nudge to look at the wider site, not a verdict on the one URL.

The misinformation, and what is actually true

Search results for these statuses are full of confident, wrong advice. Here is what does not work and why.

  • "Click Request Indexing until it sticks." It will not. Google's own recrawl documentation states that "requesting a recrawl multiple times for the same URL won't get it crawled any faster," and that a crawl request "does not guarantee that inclusion in search results will happen instantly or even at all." For "Crawled - currently not indexed" specifically, the status's own definition says "no need to resubmit this URL for crawling." Re-requesting a crawled-not-indexed URL is asking Google to re-do the exact step that already produced this result.
  • "Pay an instant-indexing service." These submit URLs Google already knows about. By definition a Discovered or Crawled URL is already in Google's system; discovery is not the bottleneck. A third-party submitter cannot manufacture the quality signal that indexing actually turns on.
  • "It's a penalty." It is not. These statuses are not manual actions, they do not appear in the Manual Actions report, and Mueller's repeated framing is that not indexing everything is "completely normal for any website." Treat them as a coverage outcome, not punishment.
  • "Ping it through IndexNow or resubmit the sitemap and it'll index." A sitemap or IndexNow ping helps discovery, getting Google to learn a URL exists. For "Crawled - currently not indexed" discovery is already done, so a ping addresses nothing. (And Google does not consume IndexNow at all; that protocol feeds Bing, Yandex, and other participating engines, not Google.) For "Discovered" a current sitemap can help discovery and signal a recrawl, but it will not override a quality or crawl-capacity judgment.
  • "It's a Search Console bug." The statuses are documented and intentional. Reporting in GSC can lag reality by days, but the statuses themselves are by design, not glitches.

What actually moves a page into the index

When you genuinely want a not-indexed page indexed (a real article, not a parameter URL), the levers are unglamorous and slow:

  1. Make the page genuinely worth indexing. Thin, near-duplicate, or low-value pages are a common reason for "Crawled - currently not indexed". Add depth, originality, and a reason the page deserves to exist that another page on your site (or the web) does not already serve. Mueller's "it's more site-wide" means a pile of weak pages drags down the strong ones, so pruning or improving the weak set helps the whole site. On a JavaScript-heavy site, also check that the content actually renders without JS, since content Google cannot see server-side is a frequent, specific cause of "Crawled - currently not indexed".
  2. Strengthen internal linking to the page. A URL with no internal links pointing at it, reachable only from the sitemap, is a common "Discovered - currently not indexed" candidate. Link to it from relevant, already-indexed pages so Google can place it in context. As Mueller put it, Google has to "pull in the rest of the site to better understand its potential context."
  3. Fix crawl health, especially on large sites. If "Discovered" dominates, the bottleneck is often your server: Google rescheduled the crawl to avoid overloading you. Check Search Console's Crawl Stats for response-time spikes that line up with drops in crawl requests, keep your XML sitemap clean (only 200-status canonical URLs, nothing noindexed or redirected), and clear out junk URLs so faster responses free capacity for the pages you care about.
  4. Be patient. Mueller has said the status "can be forever," and that when quality improves, "over time we will crawl and index more." Recognizing a site-wide improvement takes Google weeks to months. There is no fast path, and anyone selling one is selling the re-submit button you already have.

When these statuses are the correct outcome

Here is the part that flips the whole frame: a lot of what sits in these statuses should be there, and trying to "fix" it is the actual mistake. Auto-generated URLs you never wanted indexed in the first place, tracking-parameter URLs, faceted-navigation combinations, and plugin beacons land in one of the "not indexed" reasons: a noindex'd URL under "Excluded by 'noindex' tag", a canonicalized one under "Alternate page with proper canonical tag", and others under "Crawled - currently not indexed". Whichever reason it is, that is Google correctly declining to index a contentless or duplicate URL.

Two common WordPress examples are worth naming, because their forum threads are full of people trying to force-fix a non-problem:

  • wordfence_lh URLs from the Wordfence Live Traffic beacon, which serve an empty noindex response and show up under "Excluded by 'noindex' tag" (or "Crawled - currently not indexed"), exactly as they should.
  • replytocom URLs from WordPress comment reply links, which are already nofollow and canonicalized back to the post, so they consolidate under "Alternate page with proper canonical tag".

For URLs like these, landing in a "not indexed" reason is success, not failure. The fix is to stop generating them at the source (or simply leave them), not to drag them into the index. Spend your indexing energy on the pages you actually want ranked, and let the noise sit in the "not indexed" reasons where it belongs.

Sources

Authoritative references this article was fact-checked against.

TagsGoogle Search ConsoleSEOIndexingCrawl BudgetWordPress SEOPage IndexingDiscoveredCrawled

Found this useful? Pass it on.

Copied

Ishan Karunaratne

Software Systems Architect · Senior Software Engineer · Engineering Leadership

Software systems architect and senior software engineer with more than two decades designing, building, and running production software, Linux systems, and DevOps infrastructure, and lately working AI into the stack. Now a CTO, though what I write here is drawn from the full arc of that work, across architecture, engineering, and operations, not any single job.

Keep reading

Related posts

find walks the live filesystem every time; locate and plocate query a prebuilt updatedb database. Compare freshness, speed, permission-awareness, and filtering, plus the mlocate vs plocate split and the macOS mdfind alternative.

find vs locate vs mlocate: Which File Search Tool to Use

find walks the live filesystem every time it runs: always current, sometimes slow. locate queries a prebuilt database: instant, but stale until the next updatedb. This breaks down the locate family (mlocate, plocate, slocate), the macOS situation, and exactly when to reach for each one.

grep is universal and searches everything you point it at; ripgrep (rg) is the fast Rust default that skips .gitignore'd and binary files; ag is the older fast-grep now superseded. Compare speed, defaults, and regex engines.

grep vs ripgrep vs ag: Which Search Tool to Use

grep is on every system and searches exactly what you point it at. ripgrep (rg) is the fast Rust-based default for code search: it skips .gitignore'd, hidden, and binary files unless told otherwise. ag (the_silver_searcher) was the older fast-grep, now largely superseded by ripgrep. This breaks down speed, defaults, regex engines, and exactly when to reach for each one.