I have a confession to make: I’ve never particularly liked WordPress.

I’ve worked with it for years. I’ve built with it, repaired it, secured it, updated it, migrated it and rescued more than a few WordPress sites after something went sideways. It can be a perfectly capable platform, and for some websites it makes sense.

But for this website, it stopped making sense a long time ago.

This blog is not a newsroom. We don’t have ten writers publishing three times a day. I write when I have something worth saying, which means the actual job of the site is pretty simple: preserve the articles, organize them well, make them easy to find, keep the old URLs working and present the material professionally.

WordPress was doing all of that with far more machinery than the job required.

So we finally dumped it.

And, yes, for this blog I mean for good.

The problem wasn’t that WordPress couldn’t do the job

It could. That was never the issue.

The issue was everything that came along for the ride.

A WordPress site means PHP, a database, an administrative login, themes, plugins and a steady stream of updates. Then you have to pay attention to whether a plugin still works with the latest version of WordPress, whether the theme has changed something, whether PHP needs updating, whether an old plugin has become a security problem, whether some bot is hammering the login page, and whether today’s routine update is going to turn into tomorrow’s repair job.

That’s a lot of moving parts for a site whose primary purpose is to display articles.

I’ve been in this business since 1998. One lesson that gets reinforced over and over is that every unnecessary moving part eventually wants attention.

Sometimes the best technical improvement isn’t adding another feature. It’s removing ten things you never needed in the first place.

We started by asking what the blog actually needed

Instead of asking, “What should replace WordPress?” we asked a better question:

What does this site actually need to do?

The answer was fairly short.

It needed to preserve the existing content. It needed clean navigation and categories. It needed search. It needed a sitemap and RSS feed. It needed proper structured data and canonical URLs. It needed to preserve the SEO value of the old article URLs. It needed to work beautifully on desktop and mobile. And it needed to make publishing a new article straightforward when I actually had something to publish.

What it did not need was a database-driven content management system running every time somebody opened a page.

That changed the entire direction of the rebuild.

What replaced WordPress

The new site is built with Astro, with the articles stored as simple Markdown files.

Astro is used to build the site. It is not sitting on the production server processing requests every time somebody visits. When we publish, Astro generates ordinary static HTML, CSS and the small amount of JavaScript the site needs.

Then Apache serves those files directly.

The difference is pretty substantial.

The old arrangement was essentially:

Visitor → Apache → PHP → WordPress → theme/plugins → database → page

The new arrangement is:

Visitor → Apache → HTML

That’s it.

No WordPress runtime. No public CMS login. No production database. No plugin stack. No PHP application required to render an article.

At our first production build, the system generated 105 static pages in just over a second. Once generated, those pages are simply files waiting to be served.

I like boring technology when boring technology gets the job done.

Moving the old blog without throwing away its history

Getting rid of WordPress did not mean throwing away the years of content already there.

We exported the old site and migrated all 93 published articles into individual Markdown files. Two old drafts stayed behind because they had never been published. We inventoried the old media, preserved the original metadata we might need later and kept the original publication dates internally even though we intentionally don’t display them publicly.

That last part was deliberate.

I don’t publish according to a content calendar just so a website can look busy. If something is useful, I want it presented as useful. If an article is clearly tied to an older product, statistic, interface or period of the Internet, it goes into the Adtastic Archives where that historical context makes sense.

The age of an article by itself doesn’t determine whether the idea is still useful.

We also created a one-to-one permanent redirect for every old WordPress article URL. So an address such as an old /index.php/2024/.../ link doesn’t simply disappear or get dumped onto the homepage. It redirects to the corresponding article in the new site.

That’s the way a migration should be done. A redesign is not an excuse to casually burn years of accumulated URLs and search history.

The part I care about most: the site can outlive the tools that built it

There was another requirement I considered non-negotiable.

I use AI heavily in development now, and the capabilities of ChatGPT and agent-based development systems are moving very quickly. I don’t want this website to become dependent on one particular model, one giant conversation or my ability to explain six months from now exactly what we were thinking when something was built.

So the repository itself is the project’s memory.

It contains the architecture rules, design system, content model, SEO and URL policy, deployment instructions, project state, major technical decisions and automated verification checks. A future AI agent — or a human developer — should be able to open the repository, read the operating documents and understand what the site is supposed to do without reconstructing its history from old conversations.

We even have one verification command that checks the important rules before a build is accepted.

That includes things like preserving the old redirects, keeping publication dates out of the public design, preventing malformed URLs, validating the content structure and making sure WordPress/PHP hasn’t somehow crept back into the project.

That’s a much better form of “memory” than hoping everybody remembers what happened six months ago.

What did we give up?

For us, not much.

WordPress gives you a browser-based editor and a familiar administrative dashboard. If I had a team of writers who needed to log in all day and publish without touching the project source, that convenience would matter more.

But I don’t.

I publish occasionally, and adding an article as a Markdown file is hardly a hardship. In return, we’ve removed an enormous amount of ongoing maintenance that provided very little value to this particular site.

That’s a trade I’ll make all day long.

Would I tell everybody to dump WordPress?

No.

Technology decisions should fit the business and the job. There are sites where WordPress remains a reasonable choice, especially when a business genuinely benefits from the CMS workflow or relies on functionality already built around that ecosystem.

But too many websites are built around a platform first and the actual requirement second.

For a relatively straightforward expert-content site like this one, running a full dynamic CMS just because that’s how blogs have traditionally been built is hard to justify anymore.

We now have a faster, simpler, more portable website with dramatically fewer things to maintain. The content is ours in plain files. The structure is documented. The old URLs are protected. The entire site can be rebuilt from the repository. And there isn’t a WordPress dashboard anywhere in sight.

I consider that progress.

Sometimes the smartest website upgrade is finally getting rid of the technology you no longer need.