Googlebot re-fetched 16 of the 46 URLs Google shows on page one for us in the last 7 days. The 30 it skipped carry 74% of our page-one impressions, and the three biggest got 0 fetches

Method, stated before the numbers

Three first-party reads, joined by path. The first is the crawler ledger described in last week's allocation post: the site's edge middleware forwards every bot-shaped User-Agent to a Convex table with the path and a timestamp, and a fixed token table names the fetcher by substring. Googlebot here means rows whose token is exactly `Googlebot`, trusted on the User-Agent; the spoof-path scanner shape is excluded and counted (0 rows this week). The dump covers the trailing 7 days, 2026-08-23 14:06 to 2026-08-30 13:39 UTC (6.98 days): 2,224 rows, 78 of them our own healthcheck probes, excluded, leaving 2,146 net requests. A request is one HTTP request; nothing is de-duplicated by IP.

The second read is Search Console's `searchAnalytics.query` for the domain property, search type web, `dataState: all`, dimensions `[page]` and `[page, query]`, over the last 28 complete days (2026-07-31 to 2026-08-28). A page-one URL is one whose average position over that window is 10.0 or better. There are 46 of them, with 840 impressions and 11 clicks between them (CTR 1.31%). Google discloses at least one query for only 10 of the 46.

The third read is the publish date of every live `/news` post, taken from the site's own registry, so posts can be bucketed by age. The join is a plain path match. 'Re-fetched' means at least one Googlebot request for that exact path inside the ledger window. The script and the three input files are committed beside the artifact; every number below is checked by 12 self-checks that fail the build if the partitions do not sum.

The join: 16 of 46, and the wrong 16

Googlebot's 240 requests went to 58 distinct paths. 119 of them (50%) were `/robots.txt` (91), `/sitemap.xml` (20) and the homepage (8). 58 requests reached 31 distinct `/news` posts, and a handful went to the `/compare` and `/guide` pages. Of the 113 URLs Search Console returned any impression for, 44 got at least one Googlebot request in the week.

Restrict that to the 46 page-one URLs and it comes out at 16 re-fetched, 30 not. The 16 hold 218 of the 840 page-one impressions and 4 of the 11 clicks. The 30 hold 622 impressions (74%) and 7 clicks. The sorting is what bothers me. The three URLs Google shows most often, at 181, 108 and 87 impressions, sit at positions 7.3, 8.2 and 6.6, and got zero Googlebot requests in 7 days. Together they are 376 impressions, 45% of everything on page one, with 0 clicks between them.

Publish dates are the day each post shipped. The full 46-row table with every Googlebot count and last-fetch stamp is in the artifact linked under Limits.

Age is not the explanation, and the newest posts are worse off

I expected Googlebot to spend its requests on new URLs and leave the settled ones alone. The ledger says otherwise on both ends. Of the 14 posts published inside the window, 0 got a Googlebot request. The 17 posts aged 8 to 14 days did best, 10 of 17 fetched. Then the rate falls with age but never reaches the new posts' zero.

So the pattern is a middle band. Posts get their first Googlebot visit somewhere in their second week (our 08-19 fetch-speed cut had Googlebot reaching 3 of 6 new posts at 11 to 34 hours and the other 3 not at all inside that read), the visits continue for a couple of weeks, and then the page is left alone whether or not it is earning impressions. The 181-impression post is 22 days old and its URL Inspection `lastCrawlTime` is 2026-08-12, eighteen days before this cut.

Why this matters for a title change

On 2026-08-23 I changed the `<title>` of that 181-impression post from a 150-character line that truncated before its answer to an 82-character one that opens with the number. The metric was Search Console clicks over 14 days, 0 to at least 2. Seven days on, the ledger shows 0 Googlebot requests for the path (12 from ChatGPT-User, 3 from OAI-SearchBot, 2 from bingbot, 1 each from ClaudeBot and Amazonbot, 2 unnamed). Google is still ranking the old title, because it has not read the new one. The test has not started. It cannot fail or pass until the ledger shows a Googlebot row on that path, and I am keeping the 08-23 title in place rather than spending a second change on a page Google is not reading. The clock starts at the first fetch.

That is the general point. A page-one CTR programme on a small site is limited by re-fetch, not by copywriting. If Googlebot re-reads a third of your page-one URLs in a week and skips the largest ones, then two thirds of any title work you do is invisible for at least a week and possibly a month. The IndexNow pings we send on publish reach Bing (bingbot: 121 requests, 48 paths this week) and do nothing for Google. The 10 of 11 URLs that went in within 27 hours of a Search Console 'Request indexing' click on 08-25 show the button works on fresh URLs; whether it triggers a re-read of an already-indexed one is a separate question I have not tested.

Week 2 of the allocation, next to week 1

The same allocation cut as last week, on this week's dump. The two windows overlap by three days (08-23 to 08-26), so treat this as a rolling read, not two independent weeks. Named fetchers took 1,532 of the 2,146 net requests; 614 came from bots the token table does not name (PetalBot 170, SemrushBot 114, AhrefsBot 98 lead that group).

Two movements are worth a sentence. ClaudeBot nearly doubled its requests and put two thirds of them into robots.txt and the sitemap; it is polling plumbing, not reading pages. Googlebot's plumbing share fell from 56% to 46% and its /news-post requests went from 39 to 58, so it read more of the site this week than last, and still none of the three biggest page-one URLs. ChatGPT-User is unchanged at three quarters homepage, 274 requests, which is the shape we described last week and, per this week's separate cut of AI referrals, includes the fixed-viewport sessions we now hold out of our own referral count.

Pre-committed re-read, 2026-09-13

Same script, same three inputs, run on 2026-09-13 with the ledger window 09-06 to 09-13 and the Search Console window ending 09-11. Three readings, written before the data exists.

1. 1Re-fetch share. The claim is that Googlebot re-fetches under half of our page-one URLs in any given week. Falsified if 24 or more of the page-one set (whatever its size on 09-13) show at least one Googlebot request in the 7 days.
2. 2Impression coverage. The claim is that the URLs Googlebot skips carry the majority of page-one impressions. Falsified if the not-re-fetched share is 50% or lower.
3. 3The retitle. The 08-23 title change on the 181-impression post is scored only from the first Googlebot request on that path. If the ledger shows one by 09-13, the 14-day click window (0 to at least 2 clicks) starts at that stamp and is read 14 days later. If it shows none, the finding is that a 22-day-old page-one URL went 32 days without a Googlebot read (lastCrawlTime 08-12 to 09-13), and the title experiment is recorded as never run.

Limits

• The ledger sees requests that reach the edge middleware. Cached responses and any fetch that never hits the app are not logged, so Googlebot counts are a floor.
• Googlebot is named by User-Agent, not by reverse DNS. A UA-spoofed request would count as Googlebot; this week's dump had 0 rows in the known spoof-path shape, but the check is a shape, not verification.
• Search Console's 28-day window and the ledger's 7-day window do not align. A URL can rank all month and be re-fetched only in the 21 days the ledger does not cover. That is why the re-read is dated and uses the same offsets.
• 'Page one' is average position over 28 days. A URL at 10.0 exactly is in; a URL that was on page one for a fortnight and then fell out may be excluded.
• Week 1 and week 2 overlap by three days. The allocation comparison is a rolling read.
• Artifact: `content/news/googlebot-pageone-refetch-cut-2026-08-30.json` (12 of 12 self-checks), built by `content/news/googlebot_pageone_refetch_cut.mjs` from `crawler-rows-slim-2026-08-23-to-30.json`, `gsc-page-rows-2026-08-30.json` and `news-slug-dates-2026-08-30.json`, all in the repository. The week-2 allocation artifact is `crawler-allocation-cut-2026-08-30.json` (9 of 9).