SEO Strategy
Same 28 Days, Two Pulls, Two Different Webs
Same warehouse, same portfolio, 25 of 28 days shared, and one extract says Claude-User made 10,924 requests while the next says 1,149. Nothing on the web moved that much in three days. The counting did.
If you publish AI crawler trend numbers off a rollup table, re-pull the same window before anyone quotes you on it. Ours did not survive the second pull.
Last Friday this site published a research brief carrying a measured claim: several AI crawlers had expanded their portfolio-wide request volume by roughly an order of magnitude over 28 days. It went into the research ledger at level `demonstrated`, the top of our four-level ladder.
Three days later the Digital Karma Data Warehouse produced a fresh extract covering almost exactly the same 28 days. Amazonbot had lost 56 percent of its requests. Claude-User had lost 89 percent. GPTBot had gained 134 percent. Google-Agent, which the week before accounted for 9,473 requests across five properties, had no rows at all.
Nothing on the open web moved that much in three days. Our measurement did.
What follows is what broke, how I know it was the counting and not the bots, and what we are changing. Last week's claim stays published, because deleting a wrong number is how you lose the ability to notice you were wrong.
What Last Week's Brief Actually Claimed
The numbers from the 2026-09-08 extract are still public, written into the ledger at `https://www.realseolife.com/data/research/ledger.json` under the entry id `ai-crawler-vendor-expansion-2026-08`. So you do not have to take my word for what last week said. You can read it.
The interesting part of that brief was never the volume. It was the spread. A bot at nine thousand requests across five properties and a bot at nine thousand across a hundred and thirty are doing two different jobs, and the property count is what tells you which. That framing still holds. The counts underneath it are the problem.
The Same 28 Days, Pulled Three Days Later
The snapshot behind this week's brief was generated 2026-09-11 at 23:40 UTC. Its recent 28-day window ends three days after the previous one, so the two windows share 25 of 28 days. Call it 89 percent of the same calendar, on the same servers, counted by the same warehouse.
Some of it holds up. OAI-SearchBot went 14,816 to 15,071, up 1.7 percent across 129 then 130 properties, which is what a stable series looks like across a three-day shift. Applebot-Extended went 5,746 to 4,586, down 20 percent, still on exactly 4 properties. Bytespider went 32,882 to 29,599, down 10 percent. All arguable.
Then it stops being arguable. ClaudeBot went 40,249 to 29,438, down 27 percent. cohere-ai went 12,811 to 8,142, down 36 percent, property count 16 to 7. Amazonbot went 74,311 to 32,799, down 56 percent, while touching the identical 127 properties in both pulls. GrokBot went 11,590 to 4,652, down 60 percent, 71 properties to 15. Claude-User went 10,924 to 1,149, down 89 percent, 74 to 24. GPTBot went the other way, 29,202 to 68,391, up 134 percent.
And Google-Agent, 9,473 requests across 5 properties last week, does not appear in the new extract at all. Not at zero. Absent. The new file does list AI2Bot at 1 request in the prior window and 0 in the recent one, so the fingerprint list is not truncated by volume. If Google-Agent had rows, they would be there.
Three days. Same warehouse. Same portfolio. You cannot get from one of those tables to the other with real crawler behaviour.
The Part That Reproduced, Which Is the Whole Tell
Here is where I expected to write that the warehouse was broken, and did not get to.
Both extracts also carry weekly Google Search Console numbers for this site. Last week's entry recorded RealSEOLife.com weekly impressions at 144, 273, 75, 40, 47 through mid-August, then 1,936, then 2,561, then 2,296 after an eight-article publishing burst, at average positions 57.0, 54.8, 55.4.
This week's extract, same weeks: 72, 273, 75, 40, 47, then 1,936, then 2,561, then 2,669. Average positions 56.97, 54.79, 55.63.
Six of eight weekly impression values are identical to the digit. The week beginning 2026-08-31 rose from 2,296 to 2,669, up 16 percent, exactly what the warehouse's own caveat predicts: GSC lags two to three days, so the most recent week in any pull is partial and fills in later. The only other value that moved is the 2026-07-18 week, a two-day stub at the edge of the window, which halved from 144 to 72.
So the GSC series reproduced, in the specific way its documented lag says it should. The crawler rollup did not, and did not move in any direction lag can explain, because server logs do not arrive late. They arrive as the request happens.
That narrows things a lot. This is not a warehouse that lost its mind. It is one rollup behaving unlike every other series sitting next to it.
What the New Snapshot Looks Like From the Inside
Next I checked whether the new extract is at least self-consistent, because a file that disagrees with itself is a worse problem.
It is consistent. Summing every fingerprint's recent 28-day requests gives 243,670, and the four full weeks in the same file from 2026-08-17 onward total 225,578, with the 28-day window reaching two days back into the week beginning 2026-08-10. All seven named properties reconcile the same way. The arithmetic holds.
What does show up inside the new file is a pattern worth naming. Claude-SearchBot goes 19,051 in the prior window to 1,820 in the recent one, on 1 property. AgentTrust goes 18,978 to 381. DatasetSEO-AI-Observatory goes 1,249 to 0. Google-Extended goes 714 to 0.
When a bot slows down, its request count falls and its property count roughly holds. When a fingerprint stops being recognised, volume and property count collapse together, and the traffic reappears elsewhere or vanishes into whatever bucket catches unmatched user agents. Claude-User falling from 74 properties to 24, GrokBot from 71 to 15, cohere-ai from 16 to 7, and Google-Agent disappearing outright all have that second shape.
The Cost Is Not the Wrong Number. It Is Everything Built on It.
A wrong count on its own is cheap. You fix it and move on.
The expensive part is that last week we opened `agentic-fetcher-target-selection-hypothesis`, which argues that agentic fetchers get pointed at a small selected set of properties by something other than general crawlability. Its motivating evidence was narrow-footprint bots like Google-Agent on 5 properties and Applebot-Extended on 4, set against Amazonbot and OAI-SearchBot on 127 and 129. One side of that contrast just evaporated. Same for `crawler-mode-split-hypothesis`, which rested on ClaudeBot staying flat while Claude-User multiplied nearly twelvefold. In the new pull Claude-User sits at 1,149 recent against 1,514 prior. Down, not up.
Neither is dead. Both might still be true. But they are now theories with no receipts under them, so they stay at level three and do not get cited as though numbers backed them. That is the whole reason the ledger separates levels. A week like this then costs two unsupported theories instead of a year of confident writing built on a rollup nobody re-read.
Better to find it in week two than week fifty.
The Fix Is a Snapshot ID, Not a Delete Key
Nothing here gets removed. Last week's entry stays in the ledger at the level it was published, with this week's finding filed beside it and pointing at it. Quietly rewriting the number would leave a record that looks clean and has lost the only useful thing in it, which is a worked example of a measured claim failing to reproduce.
What changes is the extract. Give every snapshot a stable identifier and keep the file, so two pulls three days apart stay diffable forever. Half of this article only exists because last week's numbers happened to get written into a public ledger.
Carry the unclassified bucket. The rollup currently reports requests by declared fingerprint and nothing else. Report total AI-plausible requests next to the sum of the named ones and a reclassification shows up as traffic moving between columns, instead of arriving disguised as a vendor surge.
Version the fingerprint dictionary and stamp that version on the extract. A rollup whose classification rules can change without leaving a mark is not a time series. It is today's rules applied to old data.
And re-pull before publishing. If a fingerprint moves more than about 10 percent on windows overlapping 89 percent, it does not go in the brief as a finding.
None of that is exotic. All of it is what you skip while the dashboard has been right so far.
Why This Is Not Only Our Problem
Every AI visibility product on the market is doing some version of what we did. Match a user agent against a hand-maintained dictionary, roll it up by day, draw a trend line. That dictionary changes as vendors ship and retire agents, and almost none of these tools tell you which version of it drew your chart. Fine for "is anything reading my site at all." Poor for "did Anthropic's crawling of my site fall 89 percent," which is the question people are building plans on.
Two papers posted this week come at the same problem from the other end. Q2D-Web, arXiv 2026-09-08, pairs a 190 million document corpus with 70,000 agent-reformulated search queries in ten languages, on the grounds that agentic pipelines serve machine-written rewrites "whose distribution differs from human search behavior." SearchAtlas, 2026-09-09, turns agent search trajectories into graphs of how evidence reaches the answer, and finds fragmented answer support and unverified parametric knowledge entering responses. We have reproduced neither, so both sit at level two. But they agree on something. The fetch is the easiest thing to count and the least informative. The query your page has to match is not the one a human typed. Being retrieved is not being used.
Google supplied the third reminder on 2026-09-11. John Mueller said on Bluesky that the June gap now showing in everyone's Search Console page indexing report is permanent: "This is likely from the time in June where the data was delayed ... there just isn't any data for that period." Google does not back-fill indexing data. Reported the same day by Search Engine Roundtable and Search Engine Land.
Your analytics vendor's history is not history. It is a report, and reports have holes, revisions and dictionaries of their own.
We Architect the Receipts, So the Receipts Have to Be Re-Readable
The working line around here is that there is debate around ambiguity but no debating receipts. This week sharpened it. A receipt you cannot re-read is not a receipt. It is a screenshot of a number that was true under conditions you did not write down.
So the ledger gains one measured entry saying our crawler rollup does not reproduce across extracts, three external findings we have not verified ourselves, and exactly one new hypothesis: that the instability sits in fingerprint classification rather than request capture, falsifiable by reporting the unclassified bucket next to the named ones and watching where the traffic goes. One, not three, because three are already open and a ledger that only accumulates open questions is failing at its job.
Last week's numbers stay published. This week's correction sits beside them. In ninety days that pairing is worth more than either alone.
It is not bad to be wrong if it leads to being right. It is bad to be wrong quietly.
See Where These Ideas Get Tested
The case studies and experiments are where the ideas in these articles get tested on live sites.