“Discovered – currently not indexed” is one of the most frustrating labels in Google Search Console because it describes a result without showing the full sequence that produced it.
A small first-party experiment from AskedAbout suggests that, in at least some cases, the bottleneck may be simpler than publishers assume: Google knows the URL exists, but Googlebot has not actually fetched the page yet.
The publisher tracked one new article for 11.3 days after publication. During that period, its Search Console state repeatedly showed either “Discovered, currently not indexed” or “URL is unknown to Google,” while the site’s server ledger recorded no Googlebot request to the page.
Then Googlebot arrived once.
Within 13.7 hours of that first recorded fetch, the next URL Inspection reading showed the page as submitted and indexed.
The September 6 AskedAbout test also monitored a 14-post hub. At the measurement cutoff, the only two URLs Googlebot had fetched were the only two indexed. The 12 pages with no recorded Googlebot fetch were all still outside the index.
That is a compelling site-level pattern. It is not a new definition of “Discovered – currently not indexed,” and it certainly does not establish 11.3 days as a normal Google crawl delay.
Google can crawl a page and still decline to index it. But the experiment demonstrates why server logs can be essential when diagnosing this Search Console status: before debating content quality, canonicalization or index selection, it helps to know whether Googlebot has actually seen the page.
The focal page waited 11.3 days for one Googlebot request
The article at the center of the experiment was published on August 25 at 14:04 UTC.
AskedAbout says the URL entered its submitted sitemap during the same publishing run. It was also sent through IndexNow and, from August 28 onward, linked from the site’s /news index.
The publisher deliberately did not use Search Console’s Request Indexing button for the page.
From August 28 through September 5, it took daily URL Inspection readings. Five reported “Discovered, not indexed” and four reported “URL is unknown to Google.” None showed a last crawl time.
The server ledger agreed on the important point: there were no Googlebot requests to the URL during those reads.
On September 5 at 20:05:43 UTC, Googlebot Smartphone finally requested the page. Search Console’s eventual lastCrawlTime matched the server record to the same second.
That first observed Google fetch occurred 11.3 days after publication.
The page was observed as indexed less than 14 hours after the fetch
The next URL Inspection reading was taken on September 6.
It showed the page as indexed.
The gap between Googlebot’s 20:05:43 UTC fetch and the publisher’s later indexed reading was 13.7 hours.
That does not mean Google required exactly 13.7 hours to process the page. The index state could have changed at any point between the fetch and the next inspection.
AskedAbout correctly treats 13.7 hours as an upper bound on the observed fetch-to-index transition.
The actual processing time could have been considerably shorter.
For this URL, the long wait occurred before the first Googlebot visit, while the observed transition after fetching was relatively fast.
Twelve other hub posts had never been fetched — and none was indexed
The single-page timeline becomes more interesting when placed beside the publisher’s pre-defined 14-URL hub cohort.
At the September 6 reading, two of those 14 posts had recorded Googlebot requests since August 28. Both were indexed.
The other 12 had no Googlebot rows in the server ledger. None was indexed.
Those 12 pages were not invisible to the wider web. AskedAbout counted 110 requests from other crawlers across them, including AI-company crawlers and SEO-tool bots.
Googlebot was the missing crawler.
Within this tiny cohort, “fetched by Google” and “indexed by Google” aligned perfectly at the cutoff: two fetched and indexed, 12 unfetched and excluded.
That is an association in one site sample, not evidence that a successful Googlebot fetch guarantees indexing.
Google’s own documentation supports the sequence, but not the guarantee
Google describes Search as a multi-stage system.
Its documentation on how Search works explains that Google first discovers URLs, then may crawl them, and subsequently processes eligible fetched content for possible inclusion in its index.
Discovery and crawling are therefore distinct events.
A URL can be known to Google without Googlebot having downloaded its content.
Google also explicitly says Googlebot does not crawl every page it discovers. Its crawler algorithm decides which sites to visit, how often to visit them and how many pages to fetch.
Most importantly, Google does not promise that a crawled page will be indexed. Its technical requirements say that even pages meeting the minimum requirements are not guaranteed inclusion.
The AskedAbout result fits that architecture. It does not change it.
“Discovered” should not be read as “Google has evaluated the full page”
This is where Search Console terminology can mislead non-technical users.
When Google reports a URL as discovered, it can mean the system knows the address through a sitemap, link or other discovery mechanism. That does not necessarily mean Googlebot has fetched the page body and evaluated the content.
A publisher seeing “Discovered – currently not indexed” may immediately start rewriting the article, adding more words or changing structured data.
Those actions may be irrelevant if Googlebot has not yet requested the page.
The first diagnostic question should be more basic: has Google fetched this URL?
Search Console’s URL Inspection data can help, but server access logs provide a direct record of requests reaching the site.
Google explicitly recommends logs when diagnosing missing crawls
Google’s crawl troubleshooting documentation distinguishes crawling from indexing and recommends checking site logs when important URLs do not appear to have been crawled.
That distinction is operationally important.
If Googlebot has never requested a URL, the investigation should focus on discovery and crawl access: internal links, sitemaps, robots directives, server availability and Google’s crawl prioritization.
If Googlebot has successfully fetched the URL but the page remains unindexed, the investigation moves downstream. Canonicalization, duplication, content value and other indexing decisions become more relevant.
Without knowing which stage failed, publishers can spend time optimizing the wrong problem.
The Search Console state itself flickered before the crawl
One unusual detail in AskedAbout’s daily readings is that the page did not remain continuously labeled “Discovered, currently not indexed.”
It alternated between that state and “URL is unknown to Google.”
AskedAbout recorded five discovered/not-indexed readings and four unknown-to-Google readings before the first Googlebot fetch.
There was no observed Googlebot request between those state changes.
This is another reason not to interpret Search Console coverage labels as a perfect event-by-event chronology of Google’s internal systems.
The status is useful diagnostic information, but it is a snapshot of what the inspection system reports, not a complete crawl ledger.
For the experiment, the server evidence was more stable: Googlebot had not fetched the page until September 5.
The sitemap exposed the URL repeatedly without forcing a crawl
The page was not missing from the site’s sitemap.
AskedAbout says Googlebot fetched its sitemap 34 times across 14 days while the focal page waited for its first crawl.
The URL had been present in that submitted sitemap from its publishing hour.
This is a useful reminder about what sitemaps do.
They help Google discover and prioritize URLs. They do not function as a command requiring Googlebot to fetch every submitted page immediately.
Google’s own crawling FAQ says a sitemap can help Google learn about a site but does not guarantee indexing.
The 11.3-day wait in this experiment illustrates that distinction unusually clearly.
Internal links did not produce an immediate fetch either
The publisher also linked the focal URL from its /news index beginning August 28 and exposed it through previous/next navigation.
Googlebot fetched the news index three times after that date, according to AskedAbout, without immediately following through to all 14 linked posts.
Twelve remained unfetched at the September 6 cutoff.
Again, this does not mean internal links are ineffective.
Google says it discovers new URLs primarily by extracting links from pages it already knows, and crawlable internal linking remains fundamental SEO infrastructure.
The experiment simply shows that discovery signals do not create an immediate-fetch entitlement.
Google still decides when and how much to crawl.
IndexNow was irrelevant to Google
The focal page was also pinged through IndexNow on publication.
That detail can easily create confusion because the name sounds like a universal indexing submission system.
Google does not participate in IndexNow.
The protocol is used by participating search engines such as Bing, Yandex and Seznam. It does not notify Googlebot to fetch a URL.
AskedAbout’s logs actually show Yandex reaching the page around publication, while Googlebot did not arrive until more than 11 days later.
The IndexNow submission therefore provides no evidence about Google’s discovery or crawl decision.
Nothing in the experiment identifies what triggered the Googlebot visit
It is tempting to search the timeline for a trigger.
Googlebot fetched the sitemap about 3.2 hours before it finally requested the focal page. But Google had already fetched the sitemap many times while the URL waited.
There was no manual Request Indexing action, no reported page edit and no new link immediately preceding the fetch.
Googlebot also crawled already-indexed posts during the same day.
The responsible conclusion is therefore that the experiment does not know why Google selected the page at that moment.
A sitemap fetch preceding a page fetch is not enough to establish causation.
Eleven days is not a Google indexing standard
The headline number is memorable, but it is the easiest part of the experiment to misuse.
One page waited 11.3 days for its first observed Googlebot request.
That does not mean “Discovered – currently not indexed” normally lasts 11 days. It does not establish a crawl SLA for small websites, and it does not mean a page should be considered broken on day 12.
Google says crawling and indexing depend on many factors and that it cannot predict or guarantee exactly when a URL will be crawled or indexed.
Its troubleshooting guidance notes that, for most sites, new pages can take several days to be noticed and that same-day crawling generally should not be expected outside time-sensitive environments.
Some pages will be crawled much faster than AskedAbout’s example. Others may wait longer or never be crawled at all.
A first crawl still does not guarantee indexation
The strongest possible misreading of this study would be: “If Googlebot visits, Google will index the page.”
Google explicitly says otherwise.
A successful fetch only gives Google the material it needs to process the page. Google can then decide that another URL is canonical, that the content duplicates something already indexed, that the page lacks sufficient value or that it should not be served for other reasons.
AskedAbout’s two-for-two relationship between fetched and indexed pages is interesting because of the timing. The sample is far too small to estimate a general post-crawl indexing rate.
For many SEO investigations, the important benefit is simply knowing whether the problem occurs before or after the fetch.
Zero impressions after indexation do not invalidate the timeline
The focal page had zero Search Console impressions, clicks and recorded queries through September 6.
That is unsurprising because it had been observed as indexed for less than a day when the publisher took the measurement.
Indexation only makes a page eligible to appear. It does not guarantee ranking or impressions.
The experiment therefore says nothing yet about whether the page will attract search traffic.
It measures the transition from publication to first Googlebot fetch to observed index inclusion.
Ranking is a later stage.
The practical diagnostic is simple: check the fetch before rewriting the page
For site owners dealing with “Discovered – currently not indexed,” the study suggests a useful order of operations.
First verify that the page is technically accessible, returns a successful response, is not blocked by robots rules and contains indexable content. Then check whether Googlebot has actually fetched the URL, using URL Inspection and server logs where available.
If there is no fetch, concentrate on crawl discovery and prioritization: sitemap freshness, crawlable internal links, server health and whether the site is producing more low-value URLs than Google appears willing to crawl.
If there is a successful fetch but no indexation, investigate indexing-specific causes rather than continuing to treat the problem as discovery.
This workflow does not guarantee a solution. It makes the diagnosis more precise.
“Discovered, not indexed” may describe a queue, not a verdict
AskedAbout’s focal page spent 11.3 days outside the index with no recorded Googlebot fetch. Once Googlebot finally visited, the page was observed as indexed within 13.7 hours.
In the same 14-post cohort, the only two pages Google had fetched were the only two indexed. Twelve unfetched pages remained excluded.
For this small site at this point in time, waiting for Googlebot appears to have been the dominant bottleneck.
That does not make the Search Console label a universal synonym for “not crawled.” Google can fetch pages and still reject them from the index, and Google’s systems expose more complexity than one status label can capture.
But it changes the question publishers should ask.
“Discovered – currently not indexed” does not necessarily mean Google has read the page and decided it is not good enough.
Sometimes, as this experiment illustrates, Googlebot may simply not have visited yet.