Discovered vs crawled, currently not indexed is the pair of Search Console statuses people mix up most, and mixing them up is expensive, because the two need opposite fixes. One says Google has never looked at the page. The other says Google looked and was not impressed. Editing the page helps in the second case and does nothing at all in the first.
Both statuses live in the Page indexing report under “Why pages aren’t indexed”, and Google defines them in one line each.
What is the difference between discovered and crawled, currently not indexed?
Google’s own wording, from the Page indexing report help doc:
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. This is why the last crawl date is empty on the report.”
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.”
Read those twice and the whole difference falls out. Discovered is about Google’s queue. Crawled is about Google’s opinion. A page in Discovered has never been fetched, so nothing on the page can be the cause, and nothing you change on the page can be the cure until it gets fetched. A page in Crawled has been read, and Google decided the result was not worth a slot in the index.
How do I know if Google has actually crawled my page?
Open URL Inspection and read the Last crawl field. Google documents it plainly: “The last time this page was crawled by Google, in your local time. All information shown in this tool is derived from this last crawled version.”
Empty means Discovered. A date means Crawled. That single field settles the argument faster than any report row, and it is the check almost no article on this topic mentions.
Two more fields are worth reading in the same pass. The live test reports a crawl purpose of Discovery or Refresh, which tells you whether Google still treats the URL as new or as a known page it re-fetched and rejected. And Settings, then Crawl stats, gives you host status and average response time. Google’s documentation says “Host status describes whether or not Google encountered availability issues when trying to crawl your site” and that “Ideally your host status should be Green.”
That last one matters more than it looks. A pile of Discovered URLs with a green host status and quick responses is not a server problem. It is a demand problem, and the fix moves from your hosting bill to your internal linking. If the report and the inspection tool seem to disagree with each other, the report and the live test are answering different questions.
Why did Google discover my page but never crawl it?
Because crawling is rationed, and Google says how. The crawl budget documentation splits it into two halves: a crawl capacity limit, “also known as hostload”, which is about your server, and crawl demand, which is about how much Google wants the pages.
Three quotes carry most of the answer:
- “Every site starts with the same default, conservative crawl capacity limit.”
- “Taking crawl capacity and crawl demand together, Google defines a site’s crawl budget as the set of URLs that Google can and wants to crawl.”
- “Even if the crawl capacity limit isn’t reached, if crawl demand is low, Google will crawl your site less.”
The third line is the one that ends most crawl budget arguments. You can have a fast server, a green host status, and still sit in Discovered, because Google can crawl more and does not want to.
Worth knowing before you go hunting for crawl budget you do not have: Google says the doc is aimed at “Large sites (1 million+ unique pages) with content that changes moderately often (once a week)” and “Medium or larger sites (10,000+ unique pages) with very rapidly changing content (daily)”, while adding that “The numbers given here are a rough estimate to help you classify your site. These are not exact thresholds.” It also names a third group directly: “Sites with a large portion of their total URLs classified by Search Console as Discovered - currently not indexed”. So a 400-page site with a large Discovered pile does qualify, just not for the reason most people assume. The full fix list is in the guide to Discovered, currently not indexed.
The other half of the answer is usually self-inflicted. A catalogue with filters, sort parameters and paginated archives generates enormous numbers of crawlable URLs that compete with the pages you care about, which is exactly the problem faceted navigation creates.
Why would Google crawl a page and then not index it?
Because it read the page and did not think the result added anything. Google is not obliged to explain which part failed, and it does not.
In audits the recurring causes are dull rather than mysterious: the page answers a query that another page on the same site already answers, so the two split the case for indexing; the page is a thin variant of a template, one of a hundred near-identical location or product URLs; or it is orphaned, linked from a sitemap and nothing else, which tells Google the site itself does not rate it. The guide to Crawled, currently not indexed works through each of those.
The fix is editorial and it is uncomfortable, because the honest version is often to delete or merge rather than to add. If two pages are competing for the same slot, giving Google a third is not the answer.
Should I use Request Indexing for discovered or for crawled?
For neither, as a strategy. Google’s own line on Crawled is “no need to resubmit this URL for crawling”, and that is worth taking literally.
This is the trap I see most often in audit handovers. Someone submits a few hundred Discovered URLs by hand, a chunk of them index within days, everyone concludes the problem is solved, and weeks later they slide back out. Nothing was fixed. The submission bought a fetch, the underlying reason Google was not choosing to crawl or index those pages was still there, and the temporary recovery masked it long enough for the real work to get cancelled. Whether request indexing works has the longer version.
Manual submission is a scalpel. It is for a handful of genuinely important URLs after the structural fix has landed, so Google sees the new state sooner. It is not a fix, and at roughly a dozen a day it was never going to be one.
Can a page go from discovered to crawled and still not get indexed?
Yes, and this is the part every ranking article on this topic gets wrong by treating the two statuses as separate destinations. They are stages of one pipeline. Google says it directly in the crawl budget doc: “For Google Search, not every page that is crawled will necessarily be indexed.”
So when a batch of URLs moves from Discovered into Crawled, do not report that as a win. You have moved from a queue problem to a quality problem. The number that matters is how many reach Indexed, and the fix you need has just changed underneath you.
What I check first
On a new property I do not start with the report at all. I pull the URLs, classify each one by exact status, and only then decide what kind of job it is, because a property that is 80 percent Discovered and one that is 80 percent Crawled need completely different months of work.
The two accounts that taught me this are both on the site. The skincare brand with seven country storefronts lands almost entirely in Discovered at every new launch, because a fresh domain has no history and Google fetches it cautiously, and the fix there has never once been a content edit. The baby products store in the 118-day indexing job was the opposite shape: 1,006 URLs submitted over 118 days against 409 URLs that actually mattered, where the work was cutting what Google was spending the crawl on. If you want the whole map, every Search Console indexing status lists them with what each one is really telling you.
One last piece of patience. Google says of validation that it “typically takes up to about two weeks, but in some cases can take much longer, so please be patient.” Fix the right thing, then let it run. Refixing on day three because the number has not moved is how sites end up with three conflicting fixes and no idea which one is working.
One more case worth knowing. When core pages that have nothing to do with a generated set also sit on Crawled, currently not indexed, the judgement is site level rather than page level. That is the situation John Mueller described in September 2026, and I walked through it in is programmatic SEO bad.
Sources
- Google Search Console Help, Page indexing report, for the verbatim definitions of both statuses, the note that the last crawl date is empty for Discovered, and the validation timeframe, checked 4 September 2026
- Google Search Central, crawl budget management for large sites, for crawl capacity limit and hostload, the default conservative limit, the definition of crawl budget, the low-demand line, the site-size qualifiers and the note that not every crawled page is indexed, checked 4 September 2026
- Google Search Console Help, URL Inspection tool, for the Last crawl field definition, checked 4 September 2026
- Google Search Console Help, Crawl stats report, for host status and the green target, checked 4 September 2026
- First-hand: the skincare brand and baby products store case studies on this site, for the two property shapes described in the last section