>_Blogging Programmer~/notes since 2016
blogging-programmer › web-development › astro-why-i-moved-my-blog-away-from-wordpress.md
date: 2026-11-06 topics: [Web Development, Developer Workflow] read: 3 min words: 715

Astro: Why I Moved My Blog Away from WordPress

I started this blog in 2016 as a place to keep my notes. Ten years and more than 400 posts later, it was still running on WordPress, and it had slowly become something I maintained rather than something I enjoyed.

This is the first part of a short series about moving the blog to a static site built with Astro. This part covers why I did it and what I wanted from the new setup. Part 2 covers the migration itself, and Part 3 covers design, writing and publishing.

The Small Frictions Added Up

None of the problems was dramatic on its own.

The theme never really suited a programming blog, and changing it meant fighting the theme rather than designing anything. Code blocks looked acceptable at best.

The hosting dashboard kept warning me that the PHP version was outdated, and WordPress kept announcing new releases that required a newer PHP version first. One day the theme customizer simply answered with “There has been a critical error on this website.”

Small changes required plugins. Hiding a “Last updated” line, adjusting a date, adding a snippet: each one meant another plugin, another update and another thing that could break.

And then there were the comments. Most of what arrived through the comment form was advertising for betting sites and pills.

The Import That Pushed Me Over the Edge

The final push came from a series of 138 articles I had written in Apple Pages. Getting them into WordPress meant converting the document, generating an import file, importing, discovering a problem, deleting everything and importing again.

At one point the Python code examples in 25 articles had lost their line breaks, and every fix meant another round of deleting and re-importing posts. It worked in the end, but I remember thinking that publishing my own notes should not be this hard.

What I Actually Needed

When I wrote down what the blog really does, the list was short:

  • Show articles with good typography and readable, highlighted code.
  • Let readers search and browse by topic and by date.
  • Keep comments, but only from real people.
  • Let me write in a simple form, and import many articles at once when I have a series ready.
  • Publish posts on a schedule.

None of this requires a database or code running on the server for every visitor. A blog is mostly the same pages, served again and again.

Why a Static Site

A static site generator builds every page once, ahead of time. The server only stores finished HTML, CSS and a little JavaScript. There is nothing to update on the server, nothing to log into and very little that can be attacked.

The idea is not new. Some blogging tools were generating static files twenty years ago, and generators such as Jekyll and Hugo have been around for more than a decade. What is new is how pleasant the modern tools are to work with.

Why Astro

I chose Astro for a few practical reasons:

  • Content first. Posts are Markdown files with a small header for the title, date and categories.
  • HTML by default. Pages ship without a JavaScript framework unless a component actually needs one.
  • Familiar templates. Astro components feel like a simpler version of JSX, which made them easy to read as someone who writes about React.
  • Fast builds. The whole blog, with every post, topic and month page, builds in seconds.

My Requirements for the Move

Before touching anything, I set a few rules:

  1. No broken links. Every existing post address had to keep working.
  2. Nothing lost. Every post, category and approved comment had to come across.
  3. A design I actually like, not an adjusted theme.
  4. Publishing must stay simple: a form for single posts and an import for many.
  5. WordPress stays live until the new site is ready.

Conclusion

WordPress did its job for ten years. But for a blog that is mostly text and code, it had become more maintenance than benefit. A static site promised fewer moving parts, a design of my own and full control over how the content is stored.

In Part 2, I describe how the content left WordPress: the export, the conversion to Markdown and the surprises hidden in ten years of posts.

No comments yet #Web Development#Developer Workflow AstroWordPress
Ctrl J