Yesterday I published a post about 11 of my 13 pages sitting below Discovered - currently not indexed and ended it by saying I had resubmitted my sitemaps and did not know the outcome. This is the outcome, plus the first entry in a log I am going to keep every day.
Short version, measured on a domain that is two days old:
| Rung | Morning | Evening |
|---|---|---|
URL is unknown to Google |
0 | 0 |
Discovered - currently not indexed |
15 | 9 |
Crawled - currently not indexed |
0 | 0 |
| Indexed | 0 | 7 |
I wrote most of this post against the morning column. The evening column arrived while I was editing it, which is the single most useful thing in here and I nearly missed it — more on that below.
The guides answer a question with one number. It has at least two parts
Before writing this I opened the four pages ranking for *how long for google to index my site* on 2026-08-16 — Conductor, StoryChief, MonsterInsights and CrawlWP — and read them.
| Source | The number given | Own measured data? | Splits the states? |
|---|---|---|---|
| Conductor | 3–4 weeks under 500 pages | No | No |
| StoryChief | Hours to weeks; ~1 week per John Mueller; 83% within a week | No | No |
| MonsterInsights | 1–4 weeks for brand-new sites | No | No |
| CrawlWP | 18 days average for new sites, from 200 pages across 8 sites | Yes | Phases named, no per-state data |
CrawlWP is the only one carrying its own numbers and it is the most useful of the four. But all four answer with a single duration covering the whole journey, and none reports where a URL actually sits along the way.
That matters because the journey has rungs and they behave nothing alike. Google’s Search Console reports each one separately — URL is unknown to Google, Discovered - currently not indexed, Crawled - currently not indexed, indexed — and the fixes for them are different. “Three to four weeks” is a sum. If you are staring at Search Console wondering whether something is broken, the sum cannot tell you, because the same sum is produced by a site stuck on rung one and a site stuck on rung three.
So I stopped reporting a total and started reporting the ladder.
Rung one took hours, not weeks
The timeline, all from my own logs on this site:
| When (UTC) | What | Result |
|---|---|---|
| 2026-08-15 11:36 | Google’s last sitemap fetch before I noticed | submitted: 7 |
| 2026-08-15 16:20 | I resubmitted sitemap_index.xml twice |
still submitted: 7 |
| 2026-08-15 16:52 | I submitted the child sitemaps directly | submitted: 16 twelve seconds later |
| 2026-08-15, morning | 13 posts inspected | 11 unknown, 2 Discovered |
| 2026-08-15, evening | 15 posts inspected | 0 unknown, 15 Discovered |
| 2026-08-16, first run | 15 posts inspected again | 15 Discovered, 0 indexed |
| 2026-08-16, second run | 16 posts inspected | 9 Discovered, 7 indexed |
Everything below Discovered cleared inside a single day, and the thing that moved it was submitting the child sitemaps rather than the index that points at them. I wrote up why the parent submission looks identical and moves a different number yesterday.
So on this site, discovery — the part every guide implies is the slow bit for a new domain, the part usually answered with “get backlinks so Google has a reason to come” — took hours and cost one API call. External links to this site: still one.
Rung one was not the wait. Rung two is the wait.
I want to be careful about what that generalises to. My site is 15 posts. Discovery scales with how many URLs Google has to find and how it finds them; a 5,000-page site with no sitemap is a different problem from mine. What I can say is that on a small new site with a working sitemap, the unknown→Discovered step was not measured in weeks, and I have not seen that step reported separately anywhere.
Rung two cleared between two runs of the same script
Discovered - currently not indexed means Google has the URL and has not fetched the page yet. It is a queue position, not a verdict on the page.
This morning all 15 posts were sitting in it. I wrote the paragraph above in the present tense — *none has advanced* — published the post, and then ran the same script again a few minutes later out of habit. Seven were indexed.
Which seven:
| Indexed | Still Discovered |
|---|---|
| wordpress-site-language | gates-not-rules |
| wordpress-delete-all-posts | queries-not-rank |
| wordpress-change-domain-checks | fixing-the-bug-is-half-the-job |
| wordpress-application-passwords | og-image-not-showing |
| search-console-verification-failed | og-image-size-1200×630-vs-16×9 |
| forty-queries-zero-gaps | keyword-cannibalization-measurement |
| zero-discover-90-days | google-indexing-api-permission-denied |
| discovered-currently-not-indexed-new-site | |
| this post, published an hour ago |
It is not publish order — gates-not-rules was the first post on the site and is still waiting, while four posts published after it are through. I am not going to invent a theory from one reading about which seven and why. Two things I can say: the split is not chronological, and rung two on this site was hours, not the weeks the guides quote for the journey as a whole.
And this is the part that costs people data. Both readings happened on 2026-08-16. If I had logged one number for the day, one of them would have been wrong — and my logger keyed its records by date, so the second run silently overwrote the first. I only still have the morning column because I had it open in front of me. A day is not the unit here; a run is.
So this is two rows of a table, taken hours apart, and I will add rows daily.
Every number above is a best-of-three
The readings in this post are not single calls. Yesterday I found the URL Inspection API disagreeing with itself on the same URL seconds apart, so each of the 15 posts is inspected three times per run and I keep the most advanced answer.
Three probes across 15 posts is 45 calls against a 2,000-per-day quota. The insurance is free, and it changes the result: the same set read once gave me a lower count than reading it three times.
Which is the part worth carrying away. Every wrong number I have produced on this site has been too low, never too high — and a number that is too low looks like a finding rather than an error.
Search Console and site: do not agree, and both are right
Two ways of asking the same question gave me different answers on the same day.
| Method | Morning | Evening |
|---|---|---|
| URL Inspection API | 0 indexed of 15 | 7 indexed of 16 |
Google site:firsthandlog.com |
1 result — the homepage | 3 results — homepage + 2 posts |
In the morning there was no contradiction: those 15 inspections cover 15 post URLs and do not include the homepage, so Google had the homepage and none of the posts.
In the evening there is one, and I cannot resolve it. The API reports seven posts indexed. site: shows two. They are not the same instrument — site: is a serving-side sample and has never promised to enumerate an index — but I am not going to pick whichever number I prefer. Seven and two, taken minutes apart, both from Google.
The detail I did not expect, from the morning check: searching an exact sentence from inside a post returned the homepage, not the post. Google was holding the excerpt text that appears in the homepage listing. So the words were in the index while the page they came from was not, and a naive “is my content on Google” check comes back positive for the wrong reason.
By evening that had changed — exact-phrase searches started returning the post URLs themselves. One of them returned the *wrong* post: the exact title of one article surfaced a different article that links to it, and not the article itself, which the API says is indexed.
If you are checking a young site, site: tells you whether Google has *anything*. It will not tell you whether it has the page you care about, and it will not agree with the API.
Bing accepted the same 16 URLs the same evening
For contrast I ran the other engine on the same day. Bing’s Webmaster API verified the site and took a batch of 16 URLs; the submission quota went from 100 to 84, which is how I confirmed it landed — the response body alone would not have told me.
Two things I will note and not overclaim. Bing accepting URLs is not Bing indexing them. And the legacy endpoint I used for the batch is scheduled for retirement on 2026-08-31, per the notice in Bing Webmaster Tools — after which the quota field I used to verify the submission goes away with it, which is a problem, because that field was the verification.
None of this moves the number at the top of the page. Google does not participate in IndexNow, so the fast path exists for every engine except the one I am waiting on.
What one day cannot tell you
The honest limits.
No trend. Everything above is three readings across two days. The shape of the curve is exactly what I do not have yet, and it is the only thing that would make this post an answer rather than a data point. The gap between my second and third reading is also the reason I distrust any single one of them.
Nothing about the other nine. Seven are indexed and nine are not, and I have no evidence about why that line fell where it did. Publish order does not explain it, and that is as far as the data goes.
No causation on rung one. The 15 posts became Discovered after I submitted the child sitemaps, and they also simply got older. Both explanations fit. The referring-URL evidence — my sitemap is the only inbound path that exists — is what tips it for me, but that is an argument, not an experiment.
Nothing about content quality. Rung two is where content is supposed to start mattering. I have no evidence yet either way, and I am not going to borrow someone else’s checklist and present it as a finding.
One site, one niche, 15 posts. Whatever curve I end up with describes this domain.
The check, if you are in the same spot
1. Inspect a URL three times and keep the most advanced result. Once is a sample
2. Read which rung you are on before applying any fix — the standard advice is written for rung two and three and does nothing on rung one
3. If your sitemap is a nested index, submit the children; the parent returns 204 and moves a different number
4. Do not read site: as an answer about a specific page on a young site
5. Log the reading with a timestamp, not a date. Mine moved from 0 to 7 inside one day, and a date-keyed log overwrites the earlier number with the later one
6. Write it down even when it is zero. You cannot go back and measure day one later
Tomorrow’s rows go under today’s.