Discovered – Currently Not Indexed: What Week One Actually Looks Like on Nine New Static Tool Sites

2026-10-04

Search Console labels and behavior change over time. Every figure here is a snapshot from late September / early October 2026 — verify against current Google documentation before acting on it.

Roughly 1,300 people a month search some form of “discovered currently not indexed” (Semrush, October 2026 snapshot), and almost every result they land on is a generic explainer. This post is the other kind: real numbers. I run nine small static tool sites — eight of them are listed on my /tools page — and the newest one, a 662-page word-list site called WordRoost, went live on September 28, 2026. Six days in, here is what the indexing states actually look like: the homepage got indexed before the sitemap was even submitted, every inner page still reads “URL is unknown to Google”, and the dreaded “Discovered – currently not indexed” has not appeared at all. The checks that told me anything useful were exactly three.

The three states are three different problems

Google’s own Search Console help page says it plainly. “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.” And right above it: “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.” (support.google.com/webmasters/answer/7440203)

Read those twice, because they are not the same problem. Discovered-but-not-indexed is a scheduling story — Google knows the page exists and simply has not fetched it yet. Crawled-but-not-indexed is a judgment story — Google fetched the page and declined to keep it. “URL is unknown to Google” is a third thing again: Google has not even seen the URL. Treating these as one blob called “indexing issues” sends you fixing the wrong thing with total confidence.

My data agrees with the official reading. On the new site, the state I actually live in is “unknown to Google” — a queue problem, not a quality problem. The day a page flips to “Discovered – currently not indexed”, my first check will not be content. It will be internal links, because a page Google discovers but keeps postponing is usually a page Google considers low-priority — and priority is what links signal.

Week one, real numbers from a 662-page static site

Two details carry most of the information. First, the homepage was indexed before the sitemap went in — its referring URLs in Search Console include a link from my own blog’s tools page, so plain discovery through links worked. Second, on day 6 the inner pages are still “unknown to Google” even though the sitemap has been processed with zero errors. That combination — sitemap read, homepage in, everything else unknown — is what a healthy week one looks like for a small new site. It is a queue, and the queue is long.

A sibling site three weeks further along shows the transition. Of seven pages I sampled there, three are indexed (an about page and two calculator pages, first crawled September 17) and one matrix page is still unknown. The states move unevenly across page types, and they move slowly.

Only three checks have discriminating power in week one

I wrote the inspection checklist before any data existed, on launch day, precisely so I would not improvise criteria after seeing numbers. In week one, three checks earn their place:

1. Sitemap processed with zero errors. This proves the submission channel works. If it errors here, nothing else matters yet.
2. The homepage is indexed. This proves discovery and crawling work — and if it got in via a plain text link before the sitemap, internal linking is doing its job.
3. URL Inspection returns states, not errors. This proves the API channel works and gives you the state distribution to watch over time.

Everything else — impressions, average position, click-through rate — is zero or noise in week one. My standing rule: under 20 impressions in a window, I write down “insufficient sample” and touch nothing.

The failure mode is fixing things when there is nothing to fix

The most dangerous moment in week one is seeing zero data and concluding something must be done. Chasing “indexing fixes” with no signal means guessing, and guesses cost real work: rewriting pages that were never the problem, resubmitting URLs Google already has, publishing content to impress a crawler that has not arrived.

Two traps nearly got me before the data did. The analytics script I use defaults to a rolling window whose upper bound is always three days in the past — on launch day, that window silently excluded launch day, and two runs on different dates were not comparable. Fixed by pinning explicit start and end dates. And a full 662-page URL inspection on day 0 would have returned 662 identical “unknown” results: zero discriminating power, real quota spent. I deferred the full batch to week two, when the results can actually rank pages against each other.

What I am watching next

Week two brings the first full-batch inspection of all 662 URLs. The distribution — how many flip from unknown to discovered, how many from discovered to indexed — is the first real signal. If “Discovered – currently not indexed” shows up at scale, the response is boring: strengthen internal links to those page types, confirm the site is not accidentally slowing crawlers down, and wait. If “Crawled – currently not indexed” shows up, that is the quality signal, and it gets two weeks of observation before any attribution. Boring is the point. Indexing a new small site is a queue, and the job in week one is to make sure you are in it — then let it move.

This article was created with the help of AI. AI was not used to write the content; it assisted only with translation and grammar checks.

This article was created with the help of AI