The "Rewrite WordPress" Phase (And What Comes After)

Cloudflare recently introduced what they call a "spiritual successor to WordPress." That's a bold claim. And honestly, I don't think they're wrong about the problems.

If you've worked with WordPress long enough, you've seen it: plugins breaking things in unexpected ways, security patches becoming routine, frontend output that feels impossible to fully trace. At some point, it all starts to feel fragile. And that's usually when a certain idea shows up.

The Idea Everyone Has at Some Point

"I should just rebuild WordPress properly."

I've been there. Years ago, I wanted to rewrite WordPress entirely: first in Zend Framework, then Symfony, then Laravel. Every few years, same thought: this time it will be clean, this time it will make sense, this time it won't have all the baggage.

It's a very tempting idea. And if you're technical, it almost feels obvious.

But Here's What You Eventually Realize

The problem isn't that WordPress does too much. The problem is that nothing inside it is isolated.

There's no real architecture. Everything is global state. A plugin can modify any query, any output, any behavior. A theme function can reach into the database. A hook can rewrite the entire page. There are no layers, no contracts, no boundaries between any of these things.

That's why WordPress is hard to reason about. Not because it's old or bloated, but because everything can modify everything else, and there's no clear way to trace what happened or why.

The Real Shift Isn't "WordPress vs Something Else"

That's the framing Cloudflare is pushing. But I think the real shift is simpler than that.

It's not about replacing WordPress. It's about putting a wall in front of it.

"Software architecture" gets thrown around a lot in our industry, often without much behind it. After 20+ years of writing code and reading more books on the subject than I probably should have, the conclusion I keep coming back to is surprisingly simple.

I've made this mistake myself, more than once. You look at a legacy codebase at some company, you see the tangled mess, and the instinct is: "Let's rewrite it. It's a big ball of mud. We'll do it properly this time." And it always turned out badly. The rewrite takes longer than expected, the new system quietly inherits the same problems, and you've lost months (or years) of institutional knowledge baked into the old code.

Martin Fowler wrote an entire book about this. The whole point of Refactoring is that you don't burn it down and start over. You improve a system incrementally, in small safe steps, with boundaries and tests protecting you along the way. Isolate the mess, define a clean interface, test against that interface, and then rewrite what's behind it piece by piece. That's not a WordPress opinion. That's what every serious book on the subject will tell you.

Headless is exactly that pattern applied to WordPress. It introduces a boundary. Behind it, WordPress can be as messy as it wants. Plugins can fight each other, hooks can fire in whatever order, global state can do its thing. It doesn't matter, because none of that reaches your users.

On your side of the wall, you have clean code, clear components, files in a repo. Something you can read, version, and reason about.

And This Matters Even More Now Because of AI

There's a growing idea that AI will "fix" complexity. But in this case, it exposes it.

AI struggles with hidden logic, serialized data, and systems without clear structure. Which describes a lot of modern WordPress setups. When there are no boundaries, there's nothing for AI to hold onto.

On the other hand, AI works extremely well with files, clear component structures, and version-controlled codebases. That boundary you introduced for architectural reasons? It also happens to be the thing that makes your frontend AI-friendly. The gap between what AI can do with a clean codebase versus a tangled WordPress install is only getting wider.

The Phase vs The Outcome

Wanting to rewrite WordPress? That's a phase. Most developers go through it at some point.

But if you stick with the problem long enough, you usually arrive at a different conclusion: you don't need to replace WordPress. You just need a boundary between it and everything else.