Why I Built This Blog with Astro Instead of WordPress

For a long time I had wanted a place to write about my own experiences, the problems I run into, and how I solve them. The first thing that came to mind was WordPress: I have my own servers and a reseller hosting business, and I have been building and managing sites with WordPress for years — so both the tool and the infrastructure are familiar to me. The first path I considered was, naturally, that familiar one. But when I sat down and asked myself “what actually matters to me for this blog?”, I saw that my answers did not line up with the things WordPress is strong at. In the end I built the site from scratch with Astro.

In this post I explain the thinking behind that decision: what I compared the two on, what really pushed me away from WordPress, and what Astro gave me in practice. My goal is not to bash WordPress — below I also cover the cases where it is the right choice. It is just that my priorities pointed to a different tool.

WordPress was the obvious first thought, but it does not fit my case#

Let me give WordPress its due: roughly half of the sites on the internet run on it, and that is not without reason. Someone who cannot code can log into a panel and write posts, there are thousands of themes and plugins, and there is a huge community behind it. If my goal were “quickly spin up a site and enter content,” I would say WordPress without a second thought.

But my case is different. I already write code. The real value WordPress offers — running a site without technical knowledge — is not a gain for me, because I do not need that convenience. In return, I would be paying the cost of that convenience I am not using: a constantly running database, PHP code interpreted on every visitor request, and plugins that need regular updates for security.

There is also this: in WordPress, when you want to change how the site looks or behaves, you are intervening from the outside into a ready-made system. You can do it with certain methods — hooks (add_filter), a child theme, the template hierarchy — but every time you have to stay within the limits the platform allows you. I, on the other hand, wanted to write the site’s code myself from start to finish — that is, to build exactly what I wanted rather than forcing a ready-made system into shape.

What really made me walk away: security#

The thing I cared about most for this blog was security. WordPress is the most widespread content management system (CMS) in the world; but for that very reason it is also the system attackers target the most. This is not a flaw of its own — the more widespread something is, the more people there are trying to break it. But the result is this: on a WordPress site there are many doors you have to defend. The database, the PHP runtime, the admin panel, and the weakest link, the plugins. Even a single plugin you have not updated can become a way into the site.

On a static site, none of these doors exist. My site consists of nothing but pre-built HTML, CSS, and a small amount of JavaScript. There is no server code running when a visitor arrives, no database being queried, no panel to log into. When there is no surface to hack, there is nothing left to protect. For me, that alone was reason enough.

Speed and SEO#

Static HTML is the fastest thing possible: the file is sent to the browser as-is, with no waiting for a database query or page generation in between. WordPress, on the other hand (if you are not using caching), goes to the database and rebuilds the page on every request.

For me this is not just a matter of comfort. One of this blog’s goals is to show up in search results, and one of Google’s ranking criteria is page speed (Core Web Vitals). A static site gives me an advantage here from the start — speed was not up for negotiation.

The content is mine and under version control#

In WordPress, your posts live in the database. That means the content stays tied to the platform; moving it, backing it up, or migrating it to another system is a separate chore.

In Astro, each post is a plain Markdown file. They are all on my computer, under version control with git. This gives me a few things: the history of every change is kept, I can write with whatever editor I like, and the content is not locked to any platform. I am planning to accumulate hundreds, maybe thousands of posts on this blog over the long run — I did not want that archive trapped in a database; I wanted it sitting right in front of me as plain text.

What is different in Astro — in practice#

In Astro, the entire site is already my code. If I want to change the homepage, I open the relevant file and change it; there is no one else’s system to hook into or override.

My writing workflow is this simple:

# Prepares the file for both languages of the new post, its date and slug
npm run new "Title"

# Write the post, then publish
git add .
git commit -m "new post: title"
git push

The moment I push, the site automatically rebuilds and goes live. No panel in between, no “publish” button, no database.

A build-time safety net: the content schema#

This is one of my favorite features in Astro. You define which fields your posts should have as a schema:

const posts = defineCollection({
  schema: z.object({
    title: z.string().min(1),
    description: z.string().min(1), // required for SEO
    pubDate: z.coerce.date(),
    tags: z.array(z.string()).default([]),
  }),
});

If I forget a required field in a post or write the date wrong, the site raises an error at build time and tells me exactly which file is missing what. So I catch the mistake before the visitor does. In WordPress I would usually notice the same mistake on the live site, after the fact.

Cost and maintenance#

A static site can be hosted for free on services like Cloudflare Pages. WordPress, on the other hand, needs a running server — and therefore a monthly hosting fee and regular maintenance (updates, backups, security patches). For a single personal blog, that is a lasting burden, both in money and in time.

On my side there is almost no maintenance after deploy: no plugins to update, no vulnerabilities to patch, no database to back up. I wanted to spend my energy on writing posts, not on keeping infrastructure alive.

So when is WordPress the right choice?#

Honestly, in plenty of cases. If you do not write code and do not want to deal with technical details; if content is entered by people other than you (a team, an editor); if you need features that ready-made plugins solve quickly, like e-commerce, memberships, or reservations — WordPress genuinely makes these things easier. That is where it truly shines, and these are not things to be dismissed.

The question is not “which is better,” but “which fits your job better.” My job is writing code, my priority is security and speed, and my content is text-heavy. When these three came together, the scale tipped toward Astro.

What comes next#

Here I will write about the things I get stuck on while developing software and how I solve them. Primarily as notes to myself — because writing a problem down, instead of solving it once and forgetting, helps me understand it better and guides me if I hit the same wall again later. But if it helps someone else facing the same problem, all the better.