Ten years off, five hours back on
This site has been running — if “running” is the right word for something I hadn’t touched in a decade — since 2007. The WordPress install had been chugging along on the same shared hosting account, accruing plugin updates I’d ignored and PHP deprecation warnings I’d snoozed past. I nearly shut it down in 2018. Again in 2021. Once more in 2024, when I logged into the dashboard for the first time in about eighteen months and physically recoiled at my own design. Each time, Google Analytics talked me out of it. Some of those old articles — a CentOS PHP setup guide, a couple of posts about niche PHP errors that apparently a handful of other people in the world also ran into — still pull visitors in from search. The site was earning its keep just enough to feel wrong to kill.
But WordPress, at some point, stopped earning its keep. If you can code — or drive AI effectively, which amounts to the same thing — running your personal blog on a PHP CMS with a plugin ecosystem and an admin dashboard and a database is a lot of ceremony for what is, at its core, a folder of text files. So I rebuilt the site from scratch, in Astro, in under five working hours. Here is what that looked like.
Why WordPress had to go
The slow accumulation is what gets you. No single thing was catastrophic. It was the plugin update count climbing from three to seven to fourteen the longer I left it. The PHP compatibility warning that had been sitting in the dashboard for eight months because I kept adding it to a mental backlog I never actually cleared. The theme that hadn’t been updated in three years and probably never would be. The general sense that opening the admin meant taking on a bit of work I hadn’t planned to do.
WordPress earns its keep if you’re not a developer. The plugin ecosystem is genuinely impressive, the editor has become something people actually want to use, and for a small business or a non-technical blogger it remains a reasonable choice — although the hosted site builders, Squarespace and its peers, have closed that gap considerably over the past few years. For someone who can open a terminal and write a component, though, WordPress is a lot of machinery for a personal site that is, fundamentally, a list of articles.
Why Astro
The decision wasn’t really “Astro is the best static site generator.” It was more specific than that: I want to write Markdown in a folder and ship HTML. No database. No PHP runtime. No admin login to keep secure. No plugin ecosystem to maintain. Just files and a build step.
That narrows the field considerably. I looked at Hugo — fast, no dependencies, but the templating syntax feels like it was designed to frustrate. Eleventy — good, genuinely flexible, but the configuration-as-JavaScript approach means a lot of boilerplate before you have anything. Astro hit the sweet spot: content collections with a proper Zod schema, first-class Markdown support with co-located images, a component model for the bits where I do want to write JSX, and a build process that outputs static HTML with nothing left running at runtime.
It also doesn’t feel like JavaScript, which matters more than it probably should. I spent most of two decades writing PHP, and the modern JavaScript ecosystem — bundlers, build configs, framework conventions you need to learn before you can write hello-world — still feels slightly like a foreign country. An Astro component reads closer to writing PHP than to writing React: frontmatter at the top, HTML underneath, the build process largely out of the way.
Styling is Tailwind v4, which has shifted to a CSS-first config model — no tailwind.config.js, the design tokens live in the stylesheet itself. A year ago I’d have been sceptical; in practice it’s considerably cleaner.
The whole thing deploys to Cloudflare Pages from a GitHub push, builds in about forty seconds, and is served as flat HTML. The Lighthouse scores are very satisfying. I will not pretend that isn’t part of the appeal.
What I did vs what Claude did
This is the bit that I imagine most people came for, so let me be specific about it.
I had a clear plan before any code was written. The architecture decisions — Astro for the framework, Tailwind v4 for styling, Cloudflare Pages for hosting — were mine. The content model for the posts, the URL preservation contract (every old WordPress URL had to keep working, including retired categories like my-plugins and reviews), the migration strategy for 120 archived articles — all set out before Claude wrote a line. That ordering matters more than people think. What Claude bought me was research time: documentation I didn’t have to read at 11pm, syntax I didn’t have to memorise, and typing I didn’t have to do.
The migration is the clearest example. 120 WordPress posts, exported as XML, needed to land as Markdown files in per-post folders with frontmatter validated against a Zod schema and the retired categories mapped to their new equivalents. Claude and I worked the schema and the category mapping out together — my-plugins would fold into developer, the handful of review posts into geek, the music posts redirected off to a different domain entirely. We ran the migration as a dry run three separate times because I kept changing my mind about where things should resolve. A human developer would, justifiably, have been getting visibly annoyed by round three. Claude just ran it again. That patience — combined with the typing speed and the docs-recall — turned what would have been a week’s work on my own into an evening’s.
Where it got more interesting was the things Claude thought to raise before I did. The _redirects file for Cloudflare Pages — mapping every old URL to its new equivalent, including the retired categories — was something Claude flagged early in the build. I had it on my list, but it came up before I got there. Similarly, when I’d said I wanted search but hadn’t picked a tool, Claude suggested Pagefind — a static index generated at build time, running entirely in the browser, no API account to manage. I hadn’t heard of it. It’s a better fit for this site than anything I’d have come up with on my own. Like any good partner, Claude turned out to be thinking ahead in at least a few places.
The recurring miss, though, was voice. I’d set up a will-voice skill specifically to keep AI-fingerprint phrasing out of my copy — the idea being that Claude would invoke it before drafting any user-facing text, and the output would sound like me rather than like a medium-quality content brief. In practice, early drafts of things like the footer copy and the About page arrived with phrases like “served from the edge” and “the occasional strong feeling” intact — the model reaching for the median draft rather than the specific one I’d asked for. I had to keep pulling Claude back to use the meta-tools I’d built.
The joke, which I’m aware writes itself, is that this comeback post is partly about how the AI kept failing to write like Will until Will reminded it of its own rules. Whether the version you’re reading now has successfully avoided that problem is, I suppose, a matter for you.
The headline figure — under five working hours from empty repo to deployed site — is real. But it is only real because the plan was clear before any code got written. CLAUDE.md as a rules document the AI reads first. Skills to handle recurring tasks. Project memory for the gotchas. Brainstorming before implementation. The hours are the output of the preparation, not the preparation itself.
What’s next
This is the comeback post. The site is rebuilt, it works, it’s fast, and there are already a dozen follow-up post ideas filed as GitHub issues — the Astro setup in detail, the Pagefind integration, the content migration in full. The plan is to write again, properly, monthly-ish.
A decade is a long gap. I’m not going to pretend there’s a grand reason for the return beyond the simple one: the old site stopped being something I was proud to send people to, and now it is again. That seems like enough.
What brought you here?
Filed under AI. No comments, on purpose.