# Astro vs WordPress: Why I Prefer Markdown and GitHub Actions for a Developer Blog

> Canonical: https://vxi.me/en/posts/astro-vs-wordpress-markdown-github-actions-blog/
> Locale: en-us
> Published: 2026-03-27
> Updated: 2026-03-27
> Markdown: https://vxi.me/en/posts/astro-vs-wordpress-markdown-github-actions-blog.md

If you run a personal technical blog, you eventually hit a pretty awkward problem: what slows publishing down is often not the writing itself, but everything wrapped around it.

I know the WordPress path well, and this is not a case of pretending it no longer works. It still does, and in a lot of scenarios it works very well. If you want an admin panel, a huge plugin ecosystem, themes, and a fast way to get a content site online, WordPress is still one of the most practical options around.

What changed for me was not whether WordPress was capable. It was the feeling of using it over time. As an independent developer, it slowly started to feel like “write an article, then also maintain a live application.” You are only trying to update content, but somehow you are also touching cache, plugins, backups, upgrades, compatibility, and the general health of the backend.

That is why I settled on the stack behind this blog now: Astro on the frontend, Markdown for content, content collections to keep structure under control, GitHub Actions for deployment, and a server that only serves static artifacts. The whole point was to separate writing from runtime maintenance.

## I do not think WordPress is outdated. I just do not want to keep carrying its runtime weight

This is not a “WordPress is bad” article. The issue for me is that WordPress naturally bundles a lot of concerns together.

Its own documentation is fairly honest about that. [Hardening WordPress](https://developer.wordpress.org/advanced-administration/security/hardening/) talks about security as risk reduction rather than risk elimination, and it explicitly brings in file permissions, plugin sources, backups, and hosting. [Updating WordPress](https://wordpress.org/documentation/article/updating-wordpress/) is equally direct: updates can touch core directories, plugins, FTP access, and even files like `.maintenance`.

To me, that does not make WordPress look weak. If anything, it makes it look mature. It is a real runtime system, and the docs treat it that way. But that also means that once you choose it, writing content is never just writing content. It lives beside the ongoing care of a running CMS.

For a lot of teams, that is perfectly fine. They need roles, approval flows, online editing, and plugin-driven features anyway. But for someone writing technical content alone over a long period, the real question is not whether one post is easy to publish. It is whether the whole thing still feels pleasant after 30, 50, or 100 posts.

That is where my preference changed.

## What matters most to me now is that the content is back in my hands

When people talk about Astro, they usually start with speed, lighter hosting, and static delivery. Those are real benefits, but they were not the deciding factor for me.

The real shift was that posts became repository files again.

In this blog, one article is just two Markdown files, one Chinese and one English, living in the content tree. That sounds like a small implementation detail, but it changes the workflow a lot. Every title change, metadata tweak, structure edit, and internal link update has a real diff. If I want to roll back, I roll back through Git. I do not have to dig through an admin history view or think in terms of database state.

It also makes future changes less stressful. If I want to redesign the frontend, swap layouts, or change how posts are displayed, the content itself is still just content. It is not trapped in a backend. For an independent developer, that matters more than people often admit. You are not maintaining a newsroom. You are building a body of technical work that you want to keep control of.

There is another difference that only becomes obvious after you write like this for a while. Once posts are files, writing starts to feel aligned with the rest of development work. You write locally, preview locally, build locally, then ship. It is one continuous flow instead of “I am done writing, now let me switch into a totally different backend workflow.”

That alone makes publishing feel less heavy.

## Locking the content model down makes long-term publishing much easier

The longer I keep a technical blog alive, the more I feel that the real danger is not a boring design. It is structural drift.

The first few posts usually look fine. Later on, things start to slip. One article has a good description, another one does not. Tags start to reflect mood instead of logic. Paths stop lining up across languages. Categories get renamed, but old posts never quite catch up. At that point, you are not just updating a site anymore. You are patching old inconsistency over and over.

That is why I locked the content model into the project and let build-time validation enforce it. Astro’s [Content collections](https://docs.astro.build/en/guides/content-collections/) documentation keeps emphasizing schema and type safety, and I understand why now. The real value is not “this looks cleaner.” The value is that it stops future mess before it starts.

What I like most is that it does not politely suggest discipline. It simply fails the build when the content shape is wrong. Language, path, title, publish date, categories, tags, topic, and the other fields that matter all have to line up. That may look restrictive at first, but in practice it saves time. SEO metadata, bilingual routing, topic pages, and aggregation all become much more stable because the structure is enforced from the start.

WordPress can absolutely model content too, but it usually feels like an admin-layer capability. In this Astro workflow, the rules live closer to the repository itself. One is more flexible, the other is easier to keep clean over time. For the kind of blog I am building, I prefer the second one.

## Once publishing collapses into a push, the whole thing becomes lighter

I think people underestimate publishing friction.

If every article means switching into a backend, clicking publish, clearing cache, checking plugin side effects, thinking about backups, and then making sure production did not do something strange, you start delaying posts for no good reason. Not because you have nothing to say, but because the release ritual feels annoying.

My current flow is much shorter. I write Markdown locally, run a build, and push. The rest goes through GitHub Actions. GitHub’s [workflow event docs](https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows) already define things like `push`, `schedule`, and `workflow_dispatch` as standard triggers, so this is not a hacked-together release trick. It is a normal automation path.

In practice, the experience is simple. A scaffold creates the bilingual post skeleton, build-time checks validate the frontmatter and structure, GitHub Actions builds the output, uploads it to the server, switches the release, and Nginx points to the current version.

The biggest win is not that there are fewer clicks. It is that publishing stops feeling emotionally expensive. I do not have to switch mental modes and start “doing ops” after writing. I can finish a post and let the release pipeline carry it the rest of the way.

That changed my own behavior more than I expected. I do not need to build momentum just to hit publish anymore.

## The server finally behaves like a server, not like an incident waiting room

Another thing I used to dislike about the WordPress model was how many roles the server had to play at once.

It was the content backend, the runtime, the plugin container, the cache layer, and often the debugging scene too. You start by wanting to edit a post, and somehow you end up thinking about PHP, the database, plugin compatibility, admin exposure, and upgrade side effects.

With this blog, the production server has a much narrower job. Build happens locally or in CI. Production mostly receives static artifacts, keeps multiple releases around, switches the current target, and serves HTTPS. That sounds simple because it is simple, and that simplicity matters. The live environment no longer feels like an app you constantly need to go in and maintain. It feels like a stable deployment target.

That helps SEO too, indirectly. Your attention goes back to what matters: topic pages, internal links, evergreen posts, flagship articles, and publishing cadence. You spend less energy babysitting runtime behavior.

## The most “current era” part of this setup is how naturally AI fits into it

Switching from WordPress to Astro alone does not automatically make a blog feel modern. What really changed the picture for me was how naturally AI could plug into the workflow.

In this project, AI is not just an editor-side rewrite button. It can sit inside the full content pipeline. It can read Markdown source or a Notion page, reshape it into a more publishable technical article, generate a bilingual version, redact private details before release, suggest title and description and slug and taxonomy, then continue through build, commit, push, deployment, and verification.

That is the point where this stack starts to feel fundamentally different from a traditional CMS workflow. WordPress is still centered on online content management. This Astro setup behaves more like content-as-code, where content is a repository asset and AI becomes part of the workflow layer rather than an extra plugin bolted onto the side.

For an independent developer, that model compounds nicely. The more you want templating, SEO checks, privacy filtering, bilingual publishing, or automated release steps, the more natural the file-first and Git-first approach feels.

And honestly, that difference feels bigger to me than the usual “static sites are fast” talking point.

## In the end, it is not about which one is more advanced. It is about which one fits how you want to work

If your site depends on non-technical editors publishing directly online, relies heavily on role-based workflows, or needs forms, memberships, commerce, and plugin-led business features as fast as possible, WordPress may still be the smarter choice. There is no point pretending otherwise.

But if your goal looks more like mine, a personal technical blog that should keep growing through search, stay easy to version and roll back, handle bilingual content without turning into a mess, and eventually let AI plug into publishing in a serious way, then I would still choose this Astro + Markdown + GitHub Actions architecture.

Because the real thing that decides whether you will keep publishing is rarely the homepage design. It is whether the update path feels light, stable, and close to the way you already like to work.

That is the reason I prefer this setup now. Not because it is fashionable, but because I can still imagine wanting to use it a year from now.