For over 10 years, this blog has run on WordPress. It worked well for years, but recently I needed to migrate it to a new server, and it felt like too much for what is mostly a static site.
This site does not need a database, PHP, plugins, admin dashboards, or all the extra moving parts that come with a traditional CMS. I mainly needed fast pages, simple editing, reliable deploys, and a setup that would be easier to maintain long term.
What changed for me was not just the framework. It was realizing this site never really needed a CMS in the first place. It needed a fast, maintainable website.
So I migrated the entire site to Astro.
How I Migrated
One of the most interesting parts of this project was using Codex 5.4 to help with the migration itself.
Codex was able to SSH into my server, pull down the existing WordPress content, convert all of my posts and pages into local Markdown files, and recreate the theme in Astro. That saved a huge amount of manual work. Instead of copying content one page at a time, I could move the site over much faster and keep the structure under my control.
This site currently has hundreds of pieces of content, so doing that by hand would have been painful. Having the content as local files made the whole migration much more manageable.
One thing I cared about most was preserving the existing URLs. The framework matters far less than keeping your slugs, canonical URLs, sitemap, and overall site structure consistent to avoid unnecessary SEO problems during the move.
Why Astro
Astro is a much better fit for this blog because the output is static. The pages are prebuilt and simple to deploy, with very little that can go wrong compared to a WordPress installation.
The result is a site that is much lighter and faster. It is easier to understand, easier to edit, and easier to trust.
I also like that the content now lives in Markdown files inside the repo. That means my blog is just code and content. No, weird plugin behavior. No surprise database issues. No admin panel problems.
More broadly, this move changed how I think about small websites. For a long time, building a website usually meant choosing a CMS first. That framing makes less sense now. If all you really need is a handful of pages and a blog, a static site is often the simpler and better answer.
SEO Still Works Fine
One common assumption is that moving away from WordPress means giving up SEO features. In practice, that is not true.
XML sitemaps, canonical URLs, title tags, meta descriptions, Open Graph tags, RSS feeds, and structured data are all just output. A static site can generate the same HTML just as well.
If anything, this setup is easier to reason about. There are fewer moving parts, no plugin conflicts modifying the head, and much less mystery around what search engines actually receive.
Cloudflare Caching
Another big improvement is that I now use Cloudflare to cache the HTML and static assets at its edge fully.
That means most requests never even hit my server. Pages load almost instantly because visitors receive content directly from Cloudflare rather than waiting for an origin server to build or serve each request.
The nice side effect is that hosting gets much cheaper. Since the server is doing so little work, you can host a blog like this on a very inexpensive server and still get excellent performance.
If your content is highly dynamic, personalized, behind authentication, or changes on every request, a setup like this becomes more complicated. Full HTML edge caching is amazing for static content, but you have to be more careful once the page is no longer the same for every visitor.
Easier to Edit
I also used Codex 5.4 to build a local blog post editor for this site.
Now I can write posts locally, save them directly as Markdown files, and use Git for version control of edits, new posts, and theme changes. That is a much more reliable workflow than editing content directly in WordPress.
Every change has history. I can see diffs. I can roll back mistakes. I can make content changes and site changes together in the same commit. That alone makes the site feel much more durable.
If the server crashed tomorrow, I would not be worried about backups in the same way I was with WordPress. The content and code are already in the repo so that I can redeploy the site. That is a much simpler recovery story.
Content is Local
One of the biggest unexpected benefits is how much easier this setup is for AI-assisted maintenance.
Now that all the posts are local Markdown files, I can have AI scan the site for broken links, outdated information, outdated screenshots, inconsistent formatting, or content that needs refreshing.
That is much easier than asking AI to work against a live WordPress admin or database-backed CMS. Local files are simpler to search, compare, update, and review. AI can work through the content much more reliably when everything is organized in a standard project structure.
That also changes the editing story over time. Today, a CMS still wins if the main requirement is a familiar admin interface for non-technical editing. But once updating a site becomes as easy as telling AI to change a page, committing the edit, and deploying it, that advantage starts to shrink fast.
Where a CMS Still Makes Sense
I do not think this means CMSs are obsolete. They are still the right choice for plenty of websites.
If you have multiple editors, approval workflows, scheduled publishing, complex relational content, e-commerce, memberships, or personalized experiences, a CMS is still solving a real problem. In those cases, the complexity is often justified because the site is doing much more than serving mostly static pages.
But for a personal site or a simple content site, the tradeoff increasingly looks different. A CMS can end up solving problems you do not have while adding maintenance, security, and performance overhead you do.
A few tips if you do this
If you are thinking about making a similar move, these are the main things I would focus on:
- Keep your existing URLs the same if possible.
- Move your images and other assets locally so the site is self-contained.
- Use Git for content, not just code.
- Purge or refresh your cache on deployment, so updates appear quickly.
- Review how static your site really is before going all in on full-page caching.
For my use case, this migration was absolutely worth it. The site is faster, cheaper to host, easier to maintain, easier to deploy, and much easier to work on with AI.
WordPress is still a good fit for many sites, especially if you need a traditional CMS with multiple editors and extensive dynamic behavior. But for a mostly static personal site like this one, Astro has been a much better setup.