I Moved My Blog Off WordPress Onto Files on My Own Server

I moved my blog off WordPress onto a pile of files living on a hosting box whose keys I hold. No plugins. No database. No admin dashboard to log into. Just… files. And before you laugh, I want to be clear that I didn't have a grand architectural vision or a five-year infrastructure roadmap. I got tired of chasing updates, and I want to tell you what that actually changed and what it didn't.

Why I finally did it

WordPress in practice is not really "your blog." It's a stack: the core, a theme, a handful of plugins, and a database under all of it. And every one of those layers has a heartbeat. The core wants patching. A plugin gets a security release and the next morning there's a little nudge that says this one needed updating, which, when the plugin in question touched the thing your whole site depends on, is a mini-stress event you didn't sign up for. Do this enough and your relationship with a perfectly good tool quietly curdles into maintenance.

The treadmill is the thing that got me, not any single bug. I don't mind doing work. I mind doing work that keeps resetting — patching a layer of software whose only job is to render my words.

Here's what a static build actually removes, and I'm careful to list them out because it's the core of the whole decision:

• No PHP executing on the server. If there's nothing running to exploit, half the attack surface just vanishes.
• No database to be an injection target or to corrupt.
• No plugin update queue. There is no queue. There aren't even plugins.

All that's left is HTML, CSS, a little JavaScript, and images. The entire running surface of the site collapses to "files that either exist on the box or don't." That's not a small thing for a site whose whole job is to display text people wrote a while ago and want to find again.

The one-XML-export reveal

And then there was the thing I hadn't fully let sink in until I actually did it.

WordPress will export your entire site — every post, every page, the comments, the categories — into a single XML file. I ran Tools → Export → All content and it landed in Downloads as barfiesblog.WordPress.2026-08-27.xml. My whole blog, everything, in one file.

That hit me a little oddly. I'd half-narrated the move to myself as "freeing myself from WordPress," as if the software were holding my words hostage. But my words were never stuck in the database in any meaningful sense. The export was one click and one file. The reason the blog had felt permanent in that old stack wasn't the data — it was all the software around it: the install, the theme, the plugins, the specific way everything had to be present to make the site work. The data was always portable. I just never moved it, because moving meant carrying the whole engine too, and I wasn't carrying the engine.

That's been the observation I keep coming back to: a blog is less hostage to its platform than it feels, and a lot of that feeling is the software, not the sentences.

How the move actually went

It was unglamorous in a way I thought I'd find depressing but didn't.

1. Export. WordPress admin, Tools, Export, all content, one XML, saved. 27 August 2026.
2. Rebuild. Turned the exported posts and pages into a static site — a folder of .html files plus the CSS and images, generated from the content rather than assembled by a running app.
3. Deploy to my own hosting. Uploaded the static files to the hosting box (CPanel on cpanel-007-syd.hostingww.com) and let it do the boring, good parts: Apache serving the files straight, and Let's Encrypt certificates issued automatically via AutoSSL. HTTPS without me touching a key.
4. Leave the old install in place — asleep. I didn't rip the WordPress install out and delete it. It's frozen at public_html/old-wp-backup/. If the static rebuild ever reveals I was wrong (genuinely possible, I'm making this up as I manage it), I have a rollback. So far I haven't needed it.

Now, the part where I want to be honest rather than smooth, because "I did it and everything's fine and SEO just worked out" isn't the true story.

Keeping the URLs was the actual work, and it got my attention. Every post lives at a /yyyy/mm/slug/ path — that's a habit a couple of years of writing WordPress permalinks burned in. The moment I decided I was keeping exactly those paths, most of my anxiety went away, because "keep the old paths" means every old link, every search result, and the RSS feed all still resolve to the same address. Nothing hard-404s. That was the part I could control, and I controlled it.

What I couldn't control was the re-crawl. When the site technically changes underneath it — from a running CMS to plain served files — search engines will notice and re-evaluate, and I can't tell you the ranking impact with a straight face. So here's the honest version instead of the postcard version: I kept the paths identical so there's nothing broken to crawl, I kept the RSS feed live at /rss.xml, and I'm going to watch the indexing and search console for the weeks after rather than claim this was seamless. If there's a wobble, I'm not going to paper over it in the log. I'd rather be the one that says "here's what I did and here's what I'm watching" than the one who said "flipped the switch, shipped."

The receipts, and when this is actually worth it

So what does it look like now? Same tagline — "probably the best nonsense on the interweb" — the posts at their old addresses, the RSS feed still pulling, and that little "About the blog" block still there. The engine is gone; the content and its addresses are exactly where they were. Those are the receipts I can stand behind, and I'll stop there rather than invent any speed numbers or uptime stats that sound nice but would be made up.

And I still write by hand. A new post is a new file I edit, and there's no dashboard nudging me with a red badge. Honestly, for a blog rather than a platform, I'm fine with it. The whole point was fewer moving parts to babysit.

When is this worth doing? I'll say it plainly because I'd hate to send someone to do this for the wrong reasons:

• It's a great fit for the things I actually run — small to medium content sites, blogs, docs, a portfolio. Mostly write-once content, low volume, where you value control, soundness, and owning the stack more than you value features.

• It's not a great fit the moment you need moving parts that talk to a database and you actually need them to: real e-commerce, user accounts, scaling comment moderation, frequent dynamic changes, or the moment "I will never touch a server again" is a feature you actively want. If your site is its application and not its words, you probably want a real CMS or managed hosting, not files on a box you own.

The one line I'd keep above everything: the cheapest security and ops upgrade you can make to a small website is subtraction — take out the engine, keep the words, and accept that you are now the one and only person who can accidentally break it. Which is a smaller universe of things-that-can-break than I'd have bet.

So here's the question I've been turning over, and I'd genuinely read your answer in either direction. Did you ever look for a way out of WordPress and quietly give up because your blog felt "too small to be worth migrating"? Or is your 2018-era install still running on fumes and you just… aren't bothered? And if it's the second one — what was the one thing that would finally push you, and was it the fear of touching it at all?