The daily trend in both Search Console exports covers August 8 through September 4. Average position sits between 14 and 20 for almost the entire window — the single worst day is 23.4, on August 29, of all days. Then September 1 through 4 comes in at 7.8, 7.8, 9.4, and 8.4. The average position roughly halved in four days. I went looking for what happened around that boundary instead of assuming I already knew.
What was actually happening in that window
I pulled the real go-live timestamps for every article from node_field_data rather than trust my own memory of the schedule. Twelve articles went live between August 30 and September 6: two on the 30th, two on the 31st, two on September 1st, two on the 2nd, two on the 3rd, two on the 4th. That's not a guess about pace — it's the exact created timestamp Scheduler wrote to each node, cross-checked against the fact none of them carry a publish_on value, meaning they went live at the moment shown, not on some later schedule.
So the timing lines up: the position trend starts improving right as a steady stream of new articles starts landing. That's a real correlation between two things I can independently verify — the DB timestamps and the Search Console numbers weren't produced by the same process and don't share a source of error.
Why a real correlation still isn't an explanation
Average position, the way Search Console reports it, is an impression-weighted average across every query-page pairing that surfaced that day. Two completely different mechanisms produce the exact same drop in that number, and the two exports I have can't distinguish between them.
One: existing pages started ranking better, for reasons connected to the new content — internal links from the new articles, a general site-freshness signal, whatever crawl activity a burst of publishing triggers. Two: the new pages themselves entered the impression pool at decent starting positions and did nothing to any existing page's ranking at all, just diluted the daily average by adding more good numbers to the mix. A brand-new page can rank reasonably for a low-competition long-tail query almost immediately, especially for phrasing specific enough that almost nothing else targets it — which describes most of the titles that went live that week. "A Two-Character Regex Fix That Was Quietly Defeating Its Own Preload Tags" and "The First Version of llms.txt Was Just robots.txt With a Different Filename" aren't competing against an established field of results the way a query like "drupal tutorial" would be; there may be a handful of other pages on the entire internet phrased anywhere close to that specifically, which is exactly the condition under which a page can debut at a good position without anything about the site's overall authority having changed at all.
Both produce the same chart. Only one of them means the older articles are doing better than they were three weeks ago.
What I can't do with two data points
I have two snapshots, eight days apart, of the same rolling 28-day window. That's enough to notice the shift and rule out coincidence at the level of "did I imagine this," not enough to separate the two explanations above. The new articles are still inside their first two weeks in both exports — if the improved average reflects pages ranking better on their own merits, it should still hold, or keep improving, once those articles stop being new and start being judged without a freshness boost. If it's a mix-shift artifact, the average should drift back toward the August range as the publishing pace slows or as older pages' impressions start dominating the window again.
There's a third possibility worth naming honestly: both effects are real at once, in some unknown proportion, and no amount of staring at a two-point trend line will separate them without the page-level breakdown Search Console can actually provide. Guessing the split between "genuinely better" and "diluted by volume" from two aggregate numbers would be exactly the kind of confident-sounding claim that doesn't survive a third data point.
Neither of those is something today's data can answer. It's something a third export in another week or two either confirms or contradicts, and I'd rather leave the question open here than write the more satisfying version of this where the fix I'd like to be true turns out to be the only one I checked for.