Every brief I send, a short written reading of one company's website that goes out unasked, carries the same promise. Thirty days later I run the same scanner on the same site again and send back what changed, whether or not anyone answered. Between 19 August and 3 September that promise came due for 210 sites, first measured between 18 July and 6 August, and this is the first time the rescans are read as one set.
What was measured
The scanner is isitagentready.com, which grades a site from Level 0 to Level 5, run against the same host with the same default profile as the first time, twice per site, and a pair that disagrees is run again until the reading settles or is recorded as unstable. A site counts as moved when its level changed. A check that started passing while the level held is recorded in the file but not counted here, because the level is what the recipient was told in July and what the rescan message reports.
- 210 sites rescanned. 201 gave a reading that can be compared with the first one.
- Nine could not be compared. Two hosts answered the scanner with 403 and one answered 500, and two of those three had done the same in July, so they never had a first reading either. Four runs did not settle into a reading, one of them because a single header check stalled four times out of four. Two were not rescanned at all, because the record had no address to send the result to.
- 197 of the 201 read the same level as in July. Three moved up and one moved down, 2,0 percent.
- Seven of the 210 had replied to the brief by the time of this count, 3,3 percent.
The four that moved
Three went up. A site whose sitemap answered 404 in July answers 200 now, and reads Level 1 instead of Level 0. A site whose robots.txt redirected to itself and whose sitemap returned 500 has both working, Level 0 to Level 1. A site that now declares Content Signals in its robots.txt reads Level 2 instead of Level 1. One went down: its sitemap answered in July and answers 404 now, Level 1 to Level 0, confirmed with a request outside the scanner so that a scanner artefact is ruled out.
None of the three that moved up had replied to the brief. So the brief cannot claim them, and I am not going to. The likelier explanation is ordinary maintenance, a CMS update or a plugin that started generating a sitemap, and that is worth writing down because a rescan series is the exact place where a consultant is tempted to count every improvement as an effect.
The scanner moved too
During the series the scanner added a check named ard to its API group. The twelve sites measured in the first days of September were read against a larger check set than in July without their sites changing. A rescan therefore compares the denominator first and the passes second, and the message the recipient gets names the checks rather than a percentage, because a percentage over a moving denominator says nothing.
What this says and what it does not
The sample is my own prospecting list, sites I chose to write to, not a random draw. So 2,0 percent is a fact about these 210 sites and not a rate for the web. Zero movement in thirty days is also the expected result when nobody has decided to act. The fixes are small, a sitemap line, a robots.txt group, a header, but they need a person who owns the website to schedule them, and one unsolicited email rarely does that inside a month.
What the series does show is narrower and still useful. The promise has been kept for these 210 sites. The scanner is stable enough to compare across a month for 201 of them, and where it is not, the reason can be named, on the host side for most of the nine and in my own records for the two that had no address. And the one site that went down is a reminder that agent readiness is not a state a site reaches once: a sitemap that disappears in an update takes the level with it, and nobody notices until something reads the site as a machine.
292 promises are still open, the next of them due on 9 September. When the set is larger the same reading will be repeated.
Frequently asked
What does the 30 day rescan promise mean?
Every brief turva.dev sends says that the same scanner will be run on the same site thirty days later and the result sent back, whether or not the recipient answered. The rescan message names the checks that changed rather than a percentage, because the scanner's check set can change in between.
Did the briefs change anything in thirty days?
Four of 201 comparable sites changed level, three up and one down, and none of the three that moved up had replied to the brief, so the change cannot be attributed to it. Ordinary maintenance is the likelier cause.
Why could nine sites not be compared?
Two hosts answered the scanner with 403 and one with 500, four runs did not settle into a reading, and two were not rescanned because the record had no address to send the result to. A rescan compares two readings, and where one of them is missing there is nothing to compare.
Corrected 2026-09-04. The version served for the first seven hours said the first measurements began on 13 July, described the nine unreadable sites less precisely, and claimed the promise "can be kept at this volume". The earliest first measurement was 18 July, the nine are now broken down as measured, and the claim is limited to these 210 sites. The counts did not change.
Related
- Website agent readiness, measured on 567 company sites
- Sitemaps, robots.txt and agent access
- Why agent-readiness should be measured, not asserted
Originally published at https://turva.dev/blog/thirty-days-after-the-brief
Top comments (3)
The denominator discipline is the part I'd underline — "a percentage over a moving denominator says nothing" is the same rule my own tooling learned this month. My property graph records the build HEAD it was constructed against, and freshness checks compare against the current HEAD before any verdict is trusted; the analog of your added "ard" check was a parser that gained a grammar mid-series — sites wouldn't have changed, but the reading would have.
Two things your series implies that I haven't seen stated in agent-readiness writing: first, the rescan promise turns your briefs from marketing into a measurement instrument — unsolicited briefs are usually noise, yours generate a longitudinal dataset with a named denominator. Second, the one site that moved down is the strongest argument for your whole service: readiness degrades silently, and the only sensor pointed at it is a scheduled rescan. That is exactly the absent-answer-wearing-a-pass — a site that was Level 1 in July and Level 0 today still serves the July report to anyone who asks.
One methodological suggestion for the next 292: consider recording the scanner version (or check-set hash) alongside each reading, so every historical comparison carries its own denominator — the same discipline as pinning a lockfile before a drift check.
Implemented. The check set is now derived from the scanner's own raw output rather than typed by hand, PASS plus FAIL as the denominator, stored with every reading together with a hash of it. Backfilling the last batch gave the surprise: eleven targets, one day, one profile, denominators of 16, 15 and 21 and three distinct hashes. The set moves between targets inside one run, not only between runs a month apart, so it had to be per reading. Your second point, that readiness degrades silently, is the one I have not answered.
The silent-decay answer might be the rescan promise itself — not as a fix, but as the only sensor pointed at decay. A sitemap that disappears doesn't notify anyone; the site still serves the July report. If the next 292 rescans keep catching silent downgrades, the case writes itself: agent readiness is a metric with a half-life, and the rescan schedule is the only instrument that measures it.