Behind the Scenes: why I moved my own site off WordPress

Last week I told you that a wrong URL on this site returns a real 404. When I checked the live site on 18 October, it didn't. It returned the homepage with a cheerful 200, which is the kind of mistake that stays invisible until someone goes looking. It returns a proper 404 now, and I've checked that too.

That was the most useful thing I learned this week, and it belongs in a post about why I took thisismyurl.com off WordPress, because the two are the same story. The obvious question after last week is why I moved at all. It wasn't a complaint, and the reason fits in a few paragraphs.

The week in short:

• Finished the cleanup after the move: old WordPress class names renamed, upload paths pointed at a plain media folder, 218 old /posts/ links rewritten to /blog/.
• Retired the account and sign-in pages the site no longer needs, with redirects to where that work lives now.
• Fixed the 404 behaviour and checked it against the live site.
• Kept working through the page-by-page search review across the sites.

Nothing is wrong with WordPress or PHP

WordPress runs a huge share of the web because it's good at the job. PHP is a mature language with a serious security team behind it. I still build on both, a well-kept WordPress site is still a sound place for a business to live, and the question I asked was narrower than "is it secure?" What does it cost me to keep my site secure, and has that cost changed?

AI made finding code flaws cheaper

For a long time, finding a weakness in software was slow, skilled work, and the slowness protected people. A flaw could sit in a plugin for months because finding it took someone with time and a reason to care.

That has been shifting. AI tools are now good at reading code for mistakes, which is patient, repetitive work. Google's security team published an early example of an AI agent finding a real, previously unknown bug in SQLite. I use these tools to review my own code, so I'm not guessing at what they do, and the same patience is available to people who don't mean well. How it plays out across the whole internet is beyond what I can tell you, but the gap between a flaw existing and someone finding it is visibly getting shorter, and patching when you get around to it was built for a slower world.

Fewer moving parts on a static site

Think of a guitarist's pedalboard. Every pedal on it is a good pedal, but the signal passes through all of them, and one loose cable can take down the whole song. Players who gig a lot tend to end up with fewer pedals. The ones they cut weren't bad. Each was one more cable that could fail mid-song.

My site was a full board. Core, theme, plugins, database, login, admin area, scheduled tasks, and PHP underneath, all well made. My host was already patching the server and PHP, so my share of the work was core, theme and plugin updates, but the surface was still there to be looked at, and almost none of it was doing anything for a site that mostly publishes pages. What I can control is how much there is to look at.

What a static site still has to protect

Plain files remove the login and the database. They don't remove everything, and I'd be overselling if I said so. The site still has a few Cloudflare Pages Functions behind it: a contact form handler, a search suggestion endpoint, some middleware. The build pulls in several hundred npm packages, which carry their own supply-chain risk. And the Cloudflare account that deploys the site is now the account worth guarding.

The honest comparison is where those things run. The packages run on my own machine at build time, not on a server a stranger can reach, and the functions are three small files I can read in one sitting. That's why I'm comfortable with the trade, though it isn't zero. A minimal WordPress install would have shrunk the board too, but core, login and database would still be on it, and I wanted them off.

I should also own up to a contradiction. I wrote in WordPress is rarely the wrong tool about custom builds that outlive the person who made them, and this site is now a custom build. The difference is that I'm the whole team here, and I'm staying.

What leaving WordPress cost me

Posting is more deliberate now. I edit a file and run a build rather than type into a browser, and a few conveniences I'd stopped noticing had to be rebuilt or let go. That suits me because I'm comfortable in an editor. If your site has a team posting to it, a shop or members, those moving parts are earning their keep, and the better move is to keep them and look after them well.

If you're not sure which parts of your own site are earning their keep, a site audit is where I'd start. And when there are fewer parts, each one has to be doing its job. Last week, one of mine wasn't.