My own site is my proof of work

2026-09-26

GitHub counts 544 commits in nine of my repositories for September, and the month still has four days to go. My website alone shipped 54 releases between 6 and 26 September, seven of them today. I sell audits of how ready a website is for AI agents, and my own site is the one piece of proof I can hand a buyer. Its code is public, so anyone can read every line and every release in its history.

Why does my own site change this often?

The rules I measure other sites against change every month, and a buyer can hold my site up against them on any day. If my site falls behind those rules, it shows the opposite of what I sell. Two working rules follow from that. A security finding is fixed on the day it comes in. A tool update goes in on the day it is out, together with the repairs it forces.

What does the same day look like?

On 10 September Dependabot flagged the sharp image library in both of my Cloudflare Workers, and npm audit reported three high findings among the development dependencies. The fix ran through three packages in a row: the newer wrangler needs a newer miniflare, and that one needs the fixed sharp. After the update npm audit reported zero findings, development dependencies included.

On 11 September CodeQL raised three alerts in markdown-parity-check, my open source tool that compares a page's HTML with its Markdown version. The fix went out in a release that also pinned the tool's GitHub Actions to full commit hashes and turned on Dependabot for them. Dependabot opened its first two pull requests at once, and both went into the next release that same day.

What does the site face every week?

Between 10 and 23 August the Cloudflare firewall in front of my site blocked 259 requests a day on average. Between 14 and 17 September the average was 802 a day, a pace of more than 5 000 a week. In Cloudflare's view of AI crawler traffic, the most requested refused paths hunt for secrets, such as variants of /.env and /api/keys.json, and my site has never served either.

On 18 September I widened the rule that blocks those probes. I also started blocking two networks by their network number, after one of them sent almost 4 000 requests in a single day, and I read both rules back from Cloudflare in the same session. In the seven days to 26 September, all of them after that change, Cloudflare's AI Crawl Control counted about 7 000 requests from AI crawlers and about 4 000 unsuccessful ones among them, 1 133,75 percent more unsuccessful requests than in the seven days before.

The earlier hardenings followed the same rule. My API keys and signing keys moved out of plaintext files into an encrypted vault, and scripts fetch them at run time. The rate limit my site advertised is enforced at the edge. The published OpenPGP key carries a post-quantum ML-DSA-65 key next to the Ed25519 one, and Dependabot watches the GitHub Actions of both Workers' repositories as well as their packages.

I do all of this alone. Think what the same pace asks of a company with dozens of sites, several teams and a change process for every fix.

What does it cost when a change breaks my own tools?

On 10 September I found that 14 of the last 18 Dependabot runs in my MCP server's repository had failed. The run's own annotation said only "The updater encountered one or more errors". The cause sat on an error page that only the repository owner can open. An override in package.json pinned the same package that was also a direct dependency, so Dependabot could raise neither. The repair was one line.

Today the broken tool was my own. I ran my parity check on my home page and it reported 38 errors. Across the site 63 of 71 checkable pages passed, with 142 errors and 46 warnings. The differences came from my own earlier releases. Card layouts, button rows, renamed FAQ headings and a second copy of every wide table for narrow screens had each made the HTML say something its Markdown version did not.

I set one rule for the repair: keep going until every page is right, or delete the tool. Nothing could be hidden from the page, and the checker could not be loosened to let a real difference through. It took three releases. The first reached 67 of 71 pages and 105 errors, the second 70 of 71 with 33 errors and 37 warnings, and the third 71 of 71 with no errors and no warnings. One of my own assumptions failed on the way. I expected the checker to be misreading my card lists, and it was not: a card built only of spans inside one link really is one paragraph once the CSS is gone.

Where are most sites?

Most of them sit on the floor. Between 28 June and 3 September 2026 I measured 567 company sites with the isitagentready scanner. Of those, 485 sites, 85,5 percent, read Level 1 of 5, which is what an ordinary CMS site reaches without anyone trying. Seventy-four read Level 0. Seven read Level 2, and one read Level 5. I know these numbers too well, because measuring a site before I write to its owner is how my outreach works.

What do I see that I cannot get across?

I work with AI agents every day. Claude Code writes the changes behind those 544 commits under rules I wrote: a session reads the rules, makes the change, runs the gates and hands me the result to review. I know what they can do because I watch it release after release. In one of my projects an agent signed a real transfer on a test network after five rounds of review.

Then I look at the 567 sites. An agent that reads one of them today gets what an ordinary CMS gives it, and little of what the scanner looks for above Level 1. When I describe the distance between what agents already do and what those sites give them, people do not believe me. That is the hardest part of this work for me. It is also why every number in this post is one you can check yourself: the commits are on GitHub, the parity check runs on my site for anyone, and the scanner is public.

Related

• HTML and Markdown can disagree
• Website agent readiness, measured on 567 company sites
• Five rounds before the agent signed anything
• What agent memory in local files gets me