Notice how the discussion is usually framed. It’s almost never “WordPress versus Craft,” “WordPress versus Statamic,” or “WordPress versus Payload.” It’s WordPress versus everything else at once. WordPress and the rest of the world. On one side the incumbent standard, on the other the entire modern stack.
No other CMS is treated this way. Nobody writes “Sanity vs the World.” This framing is reserved for WordPress, and it’s worth asking why it has survived into 2026, when the reason that once justified it has largely disappeared.
The classic reason to draw a hard line around your CMS was the cost of exit. Migrating off a platform meant a multi-month project: re-implementing templates, rebuilding the content model, porting plugins, retraining editors, rewriting queries. Switching stacks was expensive enough that the initial choice felt almost permanent. You didn’t pick a CMS. You joined a camp. And this wasn’t specific to WordPress - it was true of every other CMS too.
AI has quietly compressed a large part of that cost, especially for small, well-scoped content sites. So the divide should be weakening. It isn’t. And that fact is the interesting part.
What Actually Got Cheap
The tedious work of moving between stacks has dropped sharply in price. This isn’t a marketing claim, it’s a description of what practitioners are already doing.
Porting a Liquid template to Astro components, converting a WordPress theme’s PHP loops into a framework’s rendering layer, translating an ACF field structure into typed frontmatter, writing the export-transform-import script that moves ten thousand posts with their custom meta intact - these were the tasks that made migration a large budget line of its own. Today, increasingly, it comes down to a conversation with a model and an afternoon of review.
That changes the economics of the CMS decision at its root. When switching is expensive, the rational move is to over-invest in the initial choice and then defend it. When switching is cheap, the initial choice matters less than your ability to change the stack later. The stack stops being a home you buy and becomes a lease.
It’s worth being honest about the direction of that cost curve, though, because “cheap” is not “free” and the price isn’t static - it’s rising. The bigger and more entangled the thing you hand to a model - a full theme, a plugin nobody documented, a decade of custom meta - the more it costs to get a result you can trust: more tokens, more review passes, more iterations.
AI dropped the cost of migration by an order of magnitude compared to manual work, but the cost of driving that process well is real and rising, not trending to zero. How to keep that cost down - the economics of prompts and context design - is a topic for its own article. What matters more here is the narrower point: even the rising cost of AI-assisted migration stays far cheaper than the old manual process that turned a CMS choice into a multi-year decision.
If I can move a small content site off WordPress and onto any other CMS in days rather than months, then in that world the slogan “WordPress vs the world” sounds increasingly strange. So why does it still work?
This Was Never About the Code
Here’s the claim this whole piece turns on: setting WordPress against everything else was never really about technology. It was about the operational surface WordPress controls. AI lowered the cost of code, but it has barely touched that surface so far.
WordPress isn’t defended because its PHP is irreplaceable. It’s defended because of everything that surrounds the code. The editor who has published from that admin panel for eight years. The agency retainer built around one particular plugin stack. The client who wants to log in, see a familiar dashboard, and change the hero text without a developer. The forty plugins each solving one boring, real problem - forms, redirects, SEO fields, backups, a membership gate - that nobody wants to rebuild from scratch. This is the same point I made in Astro + AI vs WordPress for Simple Content Sites: the real competitor to WordPress was never another framework. It was the ready-made workflow WordPress provides.
AI compressed the part of migration that lived in code. It did almost nothing to the part that lives in people, habits, contracts, and organizational memory. And that second part is always the more important one. The divide survived because the thing it really encodes - editorial gravity, ownership of the publishing surface, the cost of retraining people - didn’t get cheaper.
Why the “Versus” Still Says Something - and Where It Lies
There’s a reason WordPress lands on one side and “everything else” on the other, and it isn’t purely a matter of camp loyalty. WordPress genuinely occupies a distinct position: it’s the dominant mainstream application that delivers a complete editorial product with no assembly required - roles, revisions, a media library, publishing schedules, previews, an interface non-technical teams already know. Most of “the rest of the world” ships a technical content layer and makes you assemble it into a workflow yourself.
So the slogan “WordPress vs the world” partly captures something real. It just aims at the wrong axis. The honest split in 2026 isn’t WordPress versus modern stacks. It’s bundled editorial surface versus assembled editorial surface - and that line runs through the modern ecosystem too. A headless Sanity setup with a well-built Studio sits closer to the first side of that line. A raw Astro repo with Markdown files sits closer to the second. WordPress is one prominent instance of the bundled model, not a category of its own.
The same correction shows up on a completely different axis when the problem isn’t content at all. Laravel vs WordPress for a transactional ledger app redraws the line as a content problem versus a transactions problem, and reaches the same verdict from the other side: the camps were always a proxy for fit, not a real opposition. Two different axes, one conclusion - the “camp” was never a useful unit of analysis.
You’re not choosing a camp. You’re choosing how much editorial infrastructure to buy and how much to build. And because AI made building cheaper, you can now tune that ratio per project instead of locking yourself into a decade-long decision. The CMS market’s composability fatigue tells the same story from the other direction: teams that bought the “assemble everything” vision are discovering the assembly cost was underestimated, just as the migration cost once was.
What Should Replace the Divide
If switching stacks is cheap and the real variable is workflow ownership, the useful question is no longer “WordPress or not.” Better to break it into a sequence of concrete questions.
Who owns the editorial surface, and do they need to control it independently of developers? If a non-technical team must publish and restructure content without engineering support, you’re buying a bundled workflow, and WordPress is a strong, honest answer to that requirement. Not a legacy compromise. A correct fit.
How much of the “forty plugins” problem actually carries the value of the site? Much of WordPress’s weight solves problems a focused content site simply doesn’t have. If you’re not running memberships, comments, campaigns, and a commerce funnel, most of that bundled surface is cost without benefit, and a leaner stack wins.
And most important: how reversible is this decision now? This is the one thing AI actually changed. Since you can migrate later at a fraction of the old cost - where the editorial surface is light enough for that to hold - you’re allowed to make a smaller, more contingent decision. Start with the monolith and pull out the frontend only when the problem becomes concrete. Start with flat files and add a git-based CMS when a second editor arrives. The stack becomes a position you hold, not a wall you build.
What This Means in Practice
The persistence of “WordPress vs the world” is a signal that the industry is still pricing CMS decisions as if they were irreversible, in a year when in most cases they no longer are. That mispricing produces two symmetric mistakes.
One camp defends WordPress long after it stopped fitting, because the framing tells them that leaving means defecting to the enemy - when for a small, well-contained site it may now mean a migration script, a review, and a preview deploy. The other camp abandons WordPress on principle, treats the bundled editorial surface as embarrassing legacy weight, and then rebuilds a worse version of it by hand because they underestimated where the value actually lived.
Both mistakes come from believing the divide is about technology. It isn’t. It’s about who does the editorial work, how independent they need to be from developers, and - for the first time - how easily you can change your mind later.
Conclusion
WordPress keeps getting set against the entire rest of the world because that opposition was never a technical claim. It was a proxy for a real trade-off: buy a complete editorial workflow, or assemble your own. That trade-off still exists, it’s still worth arguing about, and it still often ends, rightly, with choosing WordPress.
AI changed the cost of being wrong. Migration got cheaper, the choice became more reversible, so the framing lost its economic foundation even as it kept its momentum. The camps outlived their own justification.
The important question isn’t which side you’re on. It’s how much editorial surface this specific project should buy and how much it should build - and how cheaply you can revisit that answer when the project changes. Answer those two questions for yourself. “WordPress vs the world” stops being a battle line and turns back into what it always should have been: a routine, revisable engineering decision.