Why WordPress isn't suited to a professional website (and with AI it's even less so)

I want to start with some credit, because it’s deserved: WordPress did something no other software has done. It put a text editor in front of millions of people who had no reason to learn FTP, and convinced them that publishing was something they could do too. The amateur web of the 2000s exists largely thanks to it. I started there too.

The problem is that this tool, born so a photography enthusiast could publish from their living room, became the default foundation for commercial assets. The site a company builds half its customer acquisition on runs on the same engine as the recipe blog of twenty years ago. And that engine wasn’t designed for that job.

The promised independence nobody actually uses

The number one argument for WordPress is always the same: “this way the client is independent”.

In my experience it’s the least kept promise in the industry. The typical case that reaches me is a company where the marketing manager hasn’t touched the site in two years, because the last time they tried to change a price they broke the layout of the section. The independence exists on paper, not in the head of the person who’s supposed to exercise it.

What the client is left with isn’t the freedom to make changes, it’s the responsibility of maintenance. Which is exactly the opposite.

The cost of keeping an application running to serve content that doesn’t move

Most business sites are made of pages that change three or four times a year. Serving them with WordPress means that on every single visit you boot the CMS, resolve the filesystem at runtime, run the hook chain, query the database and build the page in memory. All this to return text that was identical yesterday and will be identical tomorrow.

I’ve measured the difference on real projects: moving a simple page from the PHP runtime to a modern stack easily improves response time tenfold. I wrote about it in detail in From WordPress to a modern stack (without throwing everything away).

Every plugin is one more lock to maintain

The average professional WordPress site runs between fifteen and thirty plugins, written by different authors, with different release cycles, running code on every visit. None of those authors answers for your site. Their sum does, though.

In August one of the sites I manage was attacked precisely through the WordPress instance I had left running behind the proxy. I shut it down and rebuilt it as a static build: the story of the intervention is here. The operational lesson is trivial and I repeat it often: a live application exposed to the public is a house with ten doors, and each door has a lock someone has to maintain forever.

The new part: the database is a wall between your content and AI

I understood this part by working, not by reading.

Since I started using agentic tools to work on clients’ sites, the criterion I judge a stack by has changed. Agents are excellent at one thing: reading and writing files inside a repository. It’s their natural terrain, it’s the format they were trained on, and it’s where they do their best work.

Now try asking an agent to work on a WordPress site.

The content lives in MySQL. The layout lives in the PHP theme. The configuration lives in a table of serialized options. And if there’s a page builder, the page structure is a JSON blob nested inside the post meta, unreadable for a human and only slightly more readable for a machine. There’s the REST API, sure, but it’s a bridge: it gives you access to the data, it doesn’t give you back the site as a single, understandable object.

The practical result is that a simple request becomes complicated. “We’ve renamed the service, update it everywhere it appears and fix the headings accordingly.” In a repo the agent searches the whole project, touches twenty-three files, and I open a diff that tells me line by line what changes before it goes live. On WordPress there are two options: do it by hand page by page, or give a script access to the database and hope for the best. In neither case is there a moment when I see everything together and decide.

And then there’s the part that matters most when there are many changes: undoing. With content in git, a wrong change across forty pages is undone with one command. With content in a database, it’s undone by restoring a backup, which means throwing away everything that was right in the meantime too.

When content and code live in the same place, the agent sees the whole site: text, structure, components, internal links, redirects. It can reason about all of it together, and every proposal goes through a tracked review. It’s not a developer convenience: it’s the difference between using AI seriously on a production site and not using it.

What I use instead of WordPress

What I actually use on client projects is Sandy, an editor I wrote myself. I’ll declare the conflict of interest right away, so take what follows with the caution it deserves.

It comes from a specific frustration: I wanted an interface that’s comfortable for the client, the content inside the repository and no invented format. Sandy connects to the site’s repository and works on the files already there, markdown with metadata at the top, the same files Astro, SvelteKit or Jekyll read without needing anything else. The client sees their articles in a grid with cover and date, writes in the text as in a normal editor and fills in the rest in a panel of fields. Every save is a commit in their name on a draft of their own, which goes live only when they publish it. If Sandy disappeared tomorrow, the site would stay exactly as it is.

For pages that aren’t articles, like the home page or a sales page, there’s an agent. The client opens the page and writes “shorten the headline”: the agent finds the files that make up the page, edits them in an isolated copy of the site, checks the result on phone, tablet and desktop and saves everything to the same draft. Before publishing you see a preview of every page that changed.

It’s very young, but it’s already stable, because it builds on what already exists (markdown files, git, the site itself) instead of inventing a new language. If you need something mature, with a community behind it and years of use cases, these are the two sensible alternatives.

Astro is the easiest to defend when the site is mostly editorial. Content is markdown files organized in content collections, the build is static, and the result is a set of files on disk that a human and a machine can read without intermediaries.

TinaCMS solves the problem of the non-technical client, which is the real reason most agencies stay on WordPress. It’s a git-backed CMS with visual editing: whoever writes opens the page, edits the text where they see it, and produces a commit without knowing it.

If you’re weighing what to do with yours

If you have a WordPress site and you’re wondering whether it makes sense to keep going like this, tell me about it. Send me the domain and what bothers you today: I’ll tell you which part of your site really needs to be a live application, which can become a file, and where I’d start.