On the morning of August 8, my website was perfect. Built, tested, verified against a checklist of 49 URLs. Nobody could reach it.
For two hours, www.bartknijnenberg.com answered every visitor with a TLS handshake error. Not because the migration failed. Because a certificate had not been issued yet, and no agent in my 18-agent team could do anything about it.
This is the story of that day. It is the most honest picture I can give you of what an AI team in production actually looks like: most of the work done before I woke up, and the last mile blocked by something only a human with a DNS panel could touch.
Why the site had to go
My old homepage was built on a CMS with the real content injected through code blocks. Visually fine. For an AI crawler: 531 characters of readable text.
Five hundred thirty-one. That is not a website, that is a business card with a slow loading time. ChatGPT, Perplexity and Google's AI answers read the raw HTML, and my raw HTML said almost nothing. Meanwhile the CMS pages that did render server-side needed 987 KB of HTML to show 1,337 characters of visible text.
I sell marketing built on being findable. My own site was invisible to the fastest-growing kind of search. That gap had to close.
What was staged before the switch
The migration did not start on migration day. It started nights earlier, in the team's usual shift between 22:30 and 07:00.
The agents built a static version of the site: plain HTML from one copy source, no framework, no external requests. Pages that could not move yet (pricing, contact, the blog at that point) would keep running on the CMS behind a rewrite proxy, so every URL stays alive and pages can move over one by one. And they wrote a verification script that walks all 49 URLs and checks status codes, redirects and content markers.
That last part matters more than the build. A migration without a checklist is a hope. A migration with `verify-live.py` is a claim you can test.
Then the certificate stopped everything
The DNS switch was mine to make. I pointed the domain at the new host that morning, watched the apex redirect come up, and waited for www to follow.
It did not. The TLS certificate for www stayed stuck in issuance for roughly two hours. Every request got a handshake error: the apex happily redirected visitors with a 301 straight into a wall. The site was down, and the dashboard said everything was fine.
Here is the uncomfortable part. The whole system, 18 specialists and all their review gates, sat there fully operational while the site was unreachable. The agents could build, verify and analyze. They could not click a hosting dashboard, and they should not be able to.
The site was down, and the dashboard said everything was fine.
The fix was one command
One line in a terminal: npx vercel certs issue www.bartknijnenberg.com
That was it. Manual certificate issuance, a few seconds of waiting, and www answered over HTTPS with a 200. HTTP started redirecting to HTTPS with a 308, exactly as designed. Two hours of outage, one line of fix.
I keep this incident on the site's own team page, with the date. Not out of masochism. A system that only reports its successes is a system you cannot trust, and I would not buy marketing infrastructure from someone whose status page has never seen red.
The measurement afterwards
The verification script ran the moment the certificate landed: 49 of 49 URLs green. The own domain indexable, the hosting mirror on noindex, every redirect in the right direction.
Then the numbers that justified the whole project. The homepage went from 531 readable characters in the old injected setup, to 2,616 in the first static version, to 5,528 live that day with the rewritten copy. For an AI crawler, my site got roughly ten times more to read. The CMS proxy pages, at 987 KB for 1,337 visible characters, are now the shrinking exception instead of the rule.
Two weeks later, Bing had gone from zero pages of this domain in its index to 40. Correlation is not causation. But crawlers do not index what they cannot read.
Who did what, honestly
The agents: the entire static build, the copy migration, the verification script, the before-and-after measurements, and the analysis that made the case for migrating at all.
Me: the DNS switch, the certificate command, and the go on deployment. Every publish step in this system is deliberately human. That is not a limitation I tolerate, it is the design. The approval step is the format, not the footnote.
If you are evaluating AI teams, this split is the question to ask. Not "is it autonomous?" but "where exactly does its autonomy end, and who is standing there when it does?"
What changes next migration
One line moved up the checklist: issue the certificate before switching the DNS, not after. The two-hour outage existed because issuance only started once traffic arrived, and nothing in the plan had made that step explicit.
That is the actual rhythm of running an AI marketing team: the system gets a little harder to break every time something breaks. The nightly log of what the team does, including the failures, is public at /tonight, and the FAQ answers the questions people ask me most about the setup. How the whole system came to be is a longer story, and it is written down in the Autonomous Growth System article.
The site you are reading this on is the one that came out of that day. Every page you can reach is a page an AI crawler can read. And the certificate gets issued first now.