Publishing velocity is easy to measure. Discovery is harder.
A small first-party study from AskedAbout offers an unusually stark illustration of the gap. The site had published 30 news posts between August 26 and September 8. Across the Search Console period examined, those 30 URLs generated zero Google impressions and zero clicks. During a separate 40.7-hour visitor window, they also generated zero real reads.
Every measured read went somewhere older.
The September 8 AskedAbout analysis counted nine reads by seven person IDs, all landing on three news articles published roughly three to four weeks earlier. Two arrivals came from Google, two were attributed to ChatGPT and five carried no referrer.
The sample is tiny, the traffic level is tiny and the data comes from one publisher measuring its own site. It cannot tell us how long Google normally takes to crawl new content.
But it exposes a sequencing problem that content teams can easily ignore: before a page can rank, it has to become discoverable to the search system, be fetched, be processed and make it into the index. Publishing another article does not skip those stages.
Thirty new posts produced nothing in the measured window
AskedAbout’s content registry contained 136 posts. Thirty of them — 22% of the total — had been published from August 26 onward.
Those 30 recent posts had no Search Console impressions and no clicks between August 26 and September 8. They also received no qualifying reads during the site’s September 7–8 visitor measurement window.
The 106 older posts collectively generated 800 Google impressions and eight clicks during the Search Console period.
The nine measured reads were concentrated on only three older articles. Six landed on an August 17 post, two on an August 8 post and one on an August 11 post.
That concentration makes the dataset especially unsuitable for broad traffic conclusions. Nine reads are not enough to establish a general relationship between content age and readership.
The more useful question is why the newest URLs had no opportunity to participate.
Zero impressions do not automatically prove a page is not indexed
This distinction is critical.
A URL with zero Google impressions is not necessarily absent from Google’s index. An indexed page can simply fail to appear in any measured search result during the period.
Search Console performance data and indexation status answer different questions.
The AskedAbout study goes beyond impression data by combining Search Console with URL Inspection and server-side crawler observations. That additional evidence is what makes the crawl problem interesting.
However, the article does not publish an individual URL Inspection verdict proving that all 30 recent posts were unindexed. Its strongest direct crawl evidence covers smaller subsets of those URLs.
The safe conclusion is therefore that the newest content showed no search visibility while inspected recent pages displayed a severe Google discovery and fetching bottleneck — not that zero impressions alone proves all 30 URLs were outside the index.
The seven newest inspected posts had zero Googlebot requests
AskedAbout individually examined seven posts published between September 5 and September 8.
Four were reported as “Unknown to Google” in URL Inspection and three as “Discovered – currently not indexed.” None was indexed at the time of the measurement.
The publisher’s crawler ledger also recorded zero Googlebot requests to those seven URLs since publication.
Other crawlers had reached the same pages. AskedAbout counted 73 crawler requests from non-Google sources across those seven URLs, demonstrating that the pages were technically accessible to at least some automated systems.
For that subset, the bottleneck is much clearer: Google had either not discovered the URL sufficiently to fetch it or had discovered it without proceeding to a crawl that produced indexation.
A page Googlebot has not downloaded cannot have its content processed into Google’s searchable index through the normal crawling pipeline.
A separate 14-URL sample showed the same friction
The publisher had also pre-registered a 14-URL indexation sample on August 28.
At the September 8 reading, only three of those 14 URLs were indexed. Eight were listed as discovered but not indexed and three were unknown to Google.
The crawler ledger contained only five Googlebot rows across those 14 URLs during seven days.
AskedAbout correctly labels that particular pre-registered result inconclusive against its own predefined threshold. Three URLs had made it into the index, so this was not a case where Google categorically refused to index the site’s new content.
Instead, the data shows uneven and slow progression through discovery, crawling and indexing on a small website.
Google itself separates crawling, indexing and serving
The pattern fits Google’s documented architecture without requiring a new indexing theory.
Google’s guide to how Search works describes three broad stages: crawling, indexing and serving search results.
First, Google has to discover that a URL exists and decide to crawl it. After fetching the page, Google analyzes its content and may store information about the canonical page in its index. Only then can the system select indexed material to serve for relevant searches.
Not every page completes every stage.
Google explicitly says it does not guarantee that it will crawl, index or serve a page even when that page complies with Search Essentials. It also says Googlebot does not crawl every URL it discovers.
This means “published” and “searchable” are not synonyms.
Discovery is not the same as a fetch
The Search Console status “Discovered – currently not indexed” is particularly relevant to the AskedAbout sample.
Discovery means Google knows the URL exists. It does not mean Googlebot has downloaded the page’s current content and added it to the index.
Google can learn about a URL through internal links, external links or a sitemap and still postpone fetching it.
That is why publishing workflows need to distinguish between several checkpoints: the URL exists, Google knows the URL, Googlebot has fetched it, Google has processed it, the canonical page is indexed and the page is actually being served for queries.
A Search Console impression sits near the end of that chain.
If the bottleneck is near the beginning, rewriting title tags or publishing three more articles does not directly solve it.
Google says most sites should not expect same-day crawling
Small publishers sometimes interpret a page that remains uncrawled for 24 hours as a technical failure.
Google’s own documentation sets a less aggressive expectation.
Its crawl troubleshooting guide says new pages on most sites take several days at minimum to be noticed and that publishers generally should not expect same-day crawling unless they operate a time-sensitive site such as a news property.
Google’s recrawl documentation similarly says crawling can take anywhere from a few days to a few weeks.
That range alone shows why the AskedAbout result cannot establish a universal “three-week rule.”
Large authoritative news sites can have new URLs discovered extremely quickly. Small or new sites with limited crawl demand can wait considerably longer. Site architecture, links, server behavior, content value and Google’s own crawl prioritization can all affect the process.
The study does not prove that article age caused the traffic
AskedAbout’s nine reads all landed on older posts, but age should not be treated as the causal variable.
The older articles had something the newest pages lacked: established routes into discovery and visibility.
At least some were indexed and ranking. One had generated the majority of the site’s Google clicks in the period. Another received two ChatGPT-referred arrivals.
The fact that those pages were three or four weeks old may simply reflect the time required for this particular site to get some URLs discovered, crawled, indexed, ranked or cited.
The experiment cannot tell us that waiting 21 days makes a page successful. Most pages on the web do not become successful merely by aging.
The useful variable is progress through the distribution pipeline, not the calendar.
Even the nine-read figure needs caution
The audience measurement is deliberately transparent, but it remains tiny.
AskedAbout began with 51 sessions containing a page view during the 40.7-hour window and excluded its own capture probes and an internal identity, leaving 12 qualifying arrivals. Nine met the publisher’s definition of a read.
Those nine reads came from seven person IDs because two people returned in second sessions.
The publisher also notes that the two ChatGPT-attributed arrivals occurred three seconds apart on the same IPv6 network, first through Mobile Safari and then Chrome on iOS. It counts them as two sessions and two person IDs under its instrument but acknowledges they could represent one human opening a link in two browser contexts.
Five of the nine reads had no referrer, so their acquisition source cannot be known from the analytics data.
This is useful instrumented evidence from a real site, not a statistically representative audience study.
Publishing frequency cannot compensate for a discovery bottleneck
The strategic implication is broader than the sample.
A content operation can measure productivity in posts per week and still have a distribution problem. If Google is not reaching the URLs, increasing production expands the queue without necessarily expanding search visibility.
This is especially relevant as AI makes content production cheaper.
Teams can now produce far more articles than they could several years ago. But Google’s crawl and indexing systems are not obligated to process every page simply because a CMS published it.
That changes the economics of high-volume content. The marginal cost of creating another article may be falling while the marginal probability that an undifferentiated page gets crawled, indexed and surfaced remains constrained.
Output is not distribution.
Sitemaps help discovery, but they do not create an indexing entitlement
One obvious response to slow discovery is a sitemap.
Google recommends sitemaps as a way to tell it about important new and updated URLs, particularly for new sites, larger sites and sites with content that may otherwise be difficult to discover.
But Google’s sitemap documentation is explicit that a sitemap does not guarantee every listed URL will be crawled or indexed.
Submitting the same sitemap repeatedly is also not a shortcut.
The sitemap is a discovery signal. Google still decides what to fetch and what ultimately belongs in its index.
Request Indexing is useful for diagnostics, not a publishing API
Search Console’s URL Inspection tool can request indexing for a small number of URLs.
That can be valuable when an important new page is not being picked up or when a page has materially changed.
Google warns, however, that requesting a crawl does not guarantee inclusion and that repeatedly requesting recrawls for the same URL will not make Googlebot arrive faster.
This matters operationally. A team publishing dozens of articles should not build a workflow that depends on manually pressing Request Indexing for every URL as though it were a guaranteed submission mechanism.
If discovery consistently fails across a section of the site, the better question is why Googlebot is not prioritizing that inventory.
Internal links are part of the discovery system
Google can discover new URLs by following links from pages it already knows.
That makes internal architecture an indexing concern, not merely a ranking concern.
A new article linked prominently from a frequently crawled homepage, category hub or relevant established article gives Googlebot another route to discover it. An orphan page that exists only in a sitemap has fewer natural discovery paths.
Google’s crawling guidance recommends standard crawlable links and says publishers should ensure important pages can be reached through site navigation.
For small sites struggling to get new URLs fetched, improving the route from established indexed pages to new content may be more useful than increasing the publishing schedule.
Server logs can answer a question Search Console performance cannot
One of the strongest methodological choices in the AskedAbout study is its use of a crawler ledger.
Search Console performance data can tell a publisher whether a page received impressions and clicks. URL Inspection can provide an index status for a specific URL. Server logs can answer another foundational question: did Googlebot actually request the page?
Google itself recommends examining server logs when diagnosing URLs that appear not to be crawled.
This can separate a crawl problem from an indexing problem.
If Googlebot never requested the URL, the investigation should focus on discovery, crawlability, internal linking, sitemap signals, server availability and crawl prioritization. If Googlebot fetched the page repeatedly but it remains excluded, the investigation moves further downstream toward canonicalization, duplication, content value and indexing decisions.
Those are different problems and require different fixes.
Zero impressions should trigger diagnosis before more production
A content team seeing a batch of recent URLs with zero impressions should resist two opposite conclusions.
The first is “Google hates our site.” The second is “we just need to publish more.”
Neither follows from the metric.
The practical sequence is to inspect representative URLs, check whether Google knows them, verify whether Googlebot has fetched them, confirm that crawling and indexing are not blocked, review canonical signals, check internal links and sitemaps, and then evaluate whether the content itself provides enough unique value to justify indexation.
Google’s technical requirements are only a minimum. A publicly accessible HTTP 200 page with indexable text can be eligible for indexing without being guaranteed a place in the index.
That is a critical distinction for AI-era publishing operations capable of generating hundreds of technically valid pages.
The lesson is not “publish less” — it is “measure the pipeline”
AskedAbout’s dataset is too small to justify a general recommendation about publishing cadence.
There are sites where frequent publication is entirely appropriate. Breaking-news publishers, active research organizations, ecommerce platforms and large editorial operations can legitimately create large volumes of valuable new URLs.
The lesson is that publication count should not be the final KPI.
Teams should know how many new URLs are discovered, how quickly important pages are fetched, what share becomes indexed, how long indexation takes, which pages begin earning impressions and whether those impressions lead to qualified readers.
Without those measurements, a growing article count can create the appearance of SEO progress while the searchable inventory barely changes.
Google cannot rank content it has not meaningfully processed
The AskedAbout study does not establish a universal indexing delay. It does not prove that every one of its 30 new articles was unindexed, and nine reads from seven tracked identities are nowhere near enough to describe user behavior across the web.
What it captures unusually well is the dependency chain behind organic visibility.
The site kept publishing. Its newest content produced no measured Google visibility. On the recent URLs it inspected most closely, Google had not fetched the pages at all: four were unknown and three were discovered but not indexed, with zero Googlebot requests in the crawler ledger.
Meanwhile, the few real readers it did receive landed on older pages that had already made further progress through the discovery ecosystem.
That is not evidence that old content inherently wins.
It is a reminder that content production and content distribution are different systems.
Publishing more can increase the number of opportunities a site creates. But until Google discovers, fetches, processes and indexes those opportunities, the publishing counter can rise while search visibility stays at zero.