Tim Leland ran his blog on WordPress for more than ten years. In March 2026 he wrote up the move to Astro. This is his own post, not a vendor page.
The trigger was a server migration. The site is mostly static. Moving WordPress to a new host felt like too much work for that.
He did not need a database, PHP, plugins, or an admin dashboard. He wanted fast pages, simple editing, reliable deploys, and a setup he could keep.
If you are looking at the same route, start with the WordPress → Astro playbook. Tim’s post is the field report. The playbook is the WXR-and-backup path.
Why he left
WordPress had worked. Then he had to move hosts, and the stack looked heavy for a personal site.
He says the blog never needed a CMS. A few pages and a blog can live as a static site. The extra admin, plugins, and database were solving problems he did not have.
He wanted fewer moving parts. He was tired of plugin surprises, database issues, and admin panel problems.
He does not give a hosting bill or a Lighthouse score. I am not inventing either.
How he moved it
He used Codex 5.4 for the conversion.
The agent SSH’d into the WordPress server. It pulled the existing content. It turned posts and pages into local Markdown. It recreated the theme in Astro.
The site had hundreds of pieces of content. Doing that by hand would have been painful.
The playbook starts from a file you can restore. WordPress’s Tools → Export writes a WXR file with posts, pages, comments, fields, and terms. WordPress backups still want a separate database dump and a copy of the files. Tim describes an agent reading the live site and writing Markdown.
I would still take that WXR and the file backup before an agent touches production. If a post went missing, he does not say how he would have restored it.
The thing he cared about most was the URLs. He kept the slugs, canonicals, sitemap, and site structure. The framework matters less than that if you do not want an SEO mess.
Astro can emit those paths. File routes and dynamic pages map a slug to the same public URL. Content collections are the usual folder of Markdown posts.
He also copied images and other assets onto the new site so it did not keep pointing at WordPress.
What he gained
The pages are prebuilt. A deploy is a static upload. There is less that can break than a live WordPress install.
He says the site is lighter and faster. Editing is easier. He trusts it more.
Posts now live as Markdown in the repo. The blog is code plus content. Git holds the history. He can read a diff. He can roll a bad edit back. A content change and a theme change can sit in the same commit.
He also had Codex build a local post editor. He writes there, saves Markdown, and commits. That replaced the WordPress admin for him.
Recovery got simpler. If the server died tomorrow, the content and the code are already in Git. He would redeploy from the repo instead of restoring a WordPress dump.
He then put Cloudflare in front and cached the HTML plus the static files at the edge. Most requests never hit the origin. Visitors get a cached copy, so pages load almost instantly.
Hosting got cheaper because the origin does less work. A small server is enough. He says cheaper. He does not name a price.
Cloudflare does not cache HTML by default. You add a Cache Everything rule, or HTML still goes to origin. That rule caches all HTML, including pages that change per visitor. Cloudflare warns about that. Tim does too. Skip full-page cache if the page is personalized, behind auth, or different on every request.
He also purges the cache on deploy so a new post does not sit behind an old HIT.
SEO tags still work. Sitemaps, canonicals, titles, descriptions, Open Graph tags, RSS, and structured data are HTML. A static build can emit the same tags. He says this setup is easier to reason about because no plugin is rewriting the head.
Local Markdown also made AI maintenance easier. He can scan the files for broken links, old screenshots, and stale copy. A live WordPress admin is a worse target for that.
The site is still up. He kept publishing there after the March post.
What he left behind
He gave up the WordPress admin. Non-technical editors still do better in a CMS. He says so.
He also gave up the old theme. Codex rebuilt it. The playbook calls the WordPress theme a loss. You take screenshots and start over.
He does not describe a failed import, a broken URL, or a rollback. The losses he names are the CMS pieces he wanted gone.
The playbook still lists things his post does not cover. Comments have nowhere to live on a static site unless you archive them or pick a comment host. Forms, search, and login do not come along. Shortcodes stop rendering. I am not saying those broke for him. He does not mention them.
WordPress still makes sense if you have several editors, approval workflows, scheduled publishing, ecommerce, memberships, or personalized pages. He kept that line in the post.
What I would copy
Decide how static the site really is before you cache HTML at the edge. If every visitor gets the same page, Cache Everything helps. If they do not, you will serve the wrong HTML.
Keep the public URLs. Map every old slug to the same Astro route, or add a one-hop redirect. Then copy the media. A Markdown repo that still hotlinks wp-content/uploads is not done.
Put posts in Git. That is how he got diffs, rollbacks, and a recovery path that is not a database dump.
Purge Cloudflare on every deploy. Otherwise a cached homepage can outlive the new build.
Take a real WordPress backup anyway. WXR plus database plus uploads. The playbook starts there because an agent conversion is not a restore test.
Run the WordPress → Astro playbook. Use Tim’s post for the URL and cache calls. The reverse route is Astro → WordPress if you need a way back.