What AI Changes About Building Blogs
AI has changed the economics of moving a blog: the hard part is no longer the migration work, but knowing what you want to build.
WordPress powers around 43% of the web. For years it was the default answer to “how do I start a blog?” It was mine too.
This is not a post about why WordPress is bad. It is about something its pricing quietly depends on: the belief that leaving is expensive.
For most of the web’s history that belief was correct. Migration meant days or weeks of work: exporting content, rebuilding themes, fixing images, redesigning layouts, and repairing formatting. So people stayed.
AI has changed that calculation.
The Final Straw
I had been on WordPress.com for years. Mixed content, inconsistent posting: a burst of twenty articles back in 2019, then a long gap before I started writing seriously again this year.
The friction accumulated slowly. Themes locked behind higher-tier plans. Limited customisation unless you paid more. None of that was unreasonable on its own. Platforms cost money.
What finally pushed me over the edge was much smaller.
I wanted a staging environment to test changes before pushing them live. WordPress.com charges for a second site, then charges again for the tooling to sync changes between them. Staging does carry real cost, but the pricing made a routine workflow feel disproportionately expensive for an individual blog. It stopped feeling like infrastructure and started feeling like a toll booth.
The question stopped being “should I stay?” and became “how long would it take to leave?”
The answer turned out to be: a few hours of AI-assisted work.
The Migration
To WordPress.com’s credit, the export is excellent: one XML file containing posts, pages, metadata, and media references.
From there, I handed the problem to AI.
I used the OpenAI Codex app, a macOS coding agent that works across a local development environment. I gave it the export, pointed it at my existing site, and asked it to recreate the blog in Hugo with roughly the same visual feel.
What came back was not a scaffold or a starter template. It was a functioning site: migrated content, working structure, and a recognisable design language. Separately, I used Claude to build a colour palette and refine the visual direction.
Then I iterated. Better typography. Cleaner layouts. Simpler navigation. Things I had wanted to fix for years but had never got around to inside the WordPress editor.
Export to deployment took a couple of hours. Another few refined the design.
The Image Problem
The export solved content migration, but not presentation. Some posts had inline images. Some had none. The older 2019 articles were visually weak: written quickly, published with little thought for consistency.
I wanted every article to have a proper hero image.
So I described the problem to Codex: identify posts missing hero images, promote suitable inline images where possible, and flag the gaps. Then I used AI image generation to create artwork for the rest.
Something useful happened in the process. Without planning it, I started developing a visual identity. The generated images began sharing a palette, a mood, a texture. That consistency now carries forward into new writing.
The result is the thing WordPress never made worth my time: a consistent visual identity across the whole archive, old and new, without editing it post by post. I will revisit the weakest of the early images eventually, but the archive already hangs together.
Why Hugo and GitHub Pages
Hugo is fast and simple. There is no database. Content lives as Markdown files in Git. Deployment is a push. There are far fewer moving parts than a dynamic CMS.
GitHub Pages hosts it for free, with HTTPS and custom domains.
The trade-off is real: you lose WordPress’s browser-based editor and plugin ecosystem. For non-technical creators who value integrated editing, plugins, memberships, forms, and low-friction publishing, WordPress still makes a great deal of sense.
But for technical writers, and increasingly for anyone comfortable with AI-assisted tooling, static publishing is far more accessible than it used to be.
What This Actually Means
The shift here is not Hugo specifically. It is that AI has collapsed migration friction.
Work that used to require significant developer time, such as rebuilding layouts, transforming content, repairing formatting, auditing media, and iterating on design, now compresses into a few hours of directed work with coding agents.
That changes the balance of power between platforms and users. Platforms have always benefited from inertia: even mildly dissatisfied users stayed because leaving felt expensive and risky. Much of that friction has now gone. For technically comfortable users, the barrier is less about implementation and more about clarity of intent.
I am not suggesting everyone should move to Hugo and GitHub Pages. The right answer depends on your audience, your workflow, and your tolerance for technical tooling.
AI does not remove the need for judgement, taste, or technical understanding. What it removes is the implementation cost of acting on them. And once that cost falls far enough, “it is not worth the effort to move” stops being a reason and starts being an excuse.
What I Haven’t Solved Yet
The migration is done. The design is where I want it, and the site now sits on the kind of infrastructure I prefer: static files, GitHub Pages, a custom domain, and Cloudflare in front.
But there are still things Jetpack handled on WordPress that need replacing properly: analytics, subscriber capture, automatic emails, and newsletters. When I started looking at this, it became clear that there are limited low-cost integrated toolsets for the GitHub Pages blogger. There is no direct equivalent of what Jetpack offered WordPress users.
The components all exist. Nobody has bundled them in quite the same way.
That is the next problem to solve.