WordPress developers are switching to EmDash because it was built for a world where AI agents do most of the development work. EmDash stores all content as structured JSON, gives each post type its own database table, ships with a dedicated MCP server, and comes with documentation written specifically for AI. At TJ Digital, we manage websites for roughly 40 to 50 clients, and we’re already migrating our own site to EmDash. We’ll likely start building client sites there too.
WordPress was built for humans. EmDash was built for AI agents. In 2026, that distinction matters more than most developers realize.
What Is EmDash?
EmDash is a new open-source CMS released by Cloudflare on April 1, 2026. Cloudflare describes it as the “spiritual successor to WordPress.” It’s a ground-up rebuild using TypeScript and Astro, designed to run on Cloudflare’s infrastructure (Workers, D1, R2) or on any Node.js server with SQLite.
It launched as a v0.1.0 preview, meaning it’s early. But it’s generating more serious attention from developers than any CMS release in recent memory. If you’re not familiar with the platform yet, my earlier article on what EmDash is covers the basics.
Why Developers Are Paying Attention
The most telling signal is who is taking it seriously.
Joost de Valk is the founder of Yoast SEO, one of the most widely installed WordPress plugins ever built. He’s spent the better part of two decades building on top of WordPress and advocating for it. When someone like Joost publicly builds an EmDash theme for his blog and starts migrating his content to a platform that launched three days ago, that’s worth paying attention to.
In his April 2026 post, Joost argues that EmDash is the first CMS he’s seen that’s designed for how development actually works in 2026: AI agents building sites, structured content that machines can parse, and deployment at the edge. His critique of WordPress focuses on architecture, not features.
He put it plainly: WordPress needs a full refactoring. What we’re getting is redecorating.
What’s Actually Wrong with WordPress Architecture
WordPress stores all post content in a central wp_posts table. Custom fields and metadata live in a separate wp_postmeta table as key-value pairs. That design made sense in 2003. In 2026, it creates real friction.
When Gutenberg creates a block, it stores the result as HTML with JSON embedded in comment delimiters. To read that data back out, WordPress provides a function called parse_blocks() that extracts attributes from those comment tags. Joost describes this as a workaround for the absence of a real content model, not a feature.
Plugin security is the other structural problem. Patchstack’s 2025 WordPress Security Report found 7,966 new vulnerabilities in the WordPress ecosystem in 2024, with 96% of those coming from plugins. Because every plugin runs inside the same PHP process with full access to the database and filesystem, a single compromised plugin can affect an entire site.
How EmDash Handles the Same Problems
EmDash takes a different approach to both content storage and plugin security.
Content types in EmDash are modeled as collections. Each one gets its own SQL table with typed columns. Custom fields become actual database columns with proper indexes, not key-value pairs in a shared metadata table. Rich text is stored as Portable Text, a structured JSON format, rather than serialized HTML. AI agents can read and write that data directly without any parsing layer in between.
For plugins, EmDash uses sandboxed Worker isolates. Every plugin must declare a capability manifest listing what it’s allowed to do. A plugin that needs to fetch data from an API has to declare network:fetch. A plugin that writes content has to declare write:content. No plugin can quietly reach outside its declared scope.
| Feature | WordPress | EmDash |
| Content storage | Central wp_posts table | Per-type collection tables |
| Custom fields | Key-value in wp_postmeta | Typed columns with indexes |
| Rich text format | HTML + JSON in comment delimiters | Portable Text JSON |
| Plugin security | Full PHP process access | Sandboxed Worker isolates |
| AI tooling | REST API (custom integration required) | Built-in MCP server at /_emdash/api/mcp |
| Documentation | Written for humans | Written for humans and AI agents |
| Maturity | 20+ years, massive ecosystem | v0.1.0 preview, April 2026 |
Why the MCP Server Changes Everything
The single feature that sets EmDash apart from any other CMS is the built-in MCP server.
Every EmDash instance ships with a Model Context Protocol server. AI tools, IDE extensions, and agent workflows can connect to it and interact with the CMS as a tooling backend. Searching content, managing schemas, updating posts, uploading media. Agents can handle all of it through a standardized protocol without anyone writing a custom integration.
EmDash also ships with a growing library of SKILL.md files. These are packaged instruction sets that give AI agents the context they need to work with the platform, including skills for porting WordPress themes and plugins to EmDash. The documentation itself was written with AI consumption in mind.
The result is that an AI agent can pick up a new EmDash codebase and start working without a human having to explain how the platform works. That’s the core premise of “AI-native”: the platform does the onboarding for you.
WordPress has a REST API and can be automated. The EmDash bet is that MCP, skills, structured storage, and capability-scoped plugins reduce the total friction of agent-driven development by an order of magnitude.
This also ties directly into how websites need to be structured to perform well in AI search. If you’re thinking about how AI agents evaluate and interact with your site, the underlying CMS architecture is part of that story. We cover that in more depth in our guide to AI-ready website structure.
Does WordPress Still Have an Advantage?
Yes. And it’s a significant one.
WordPress powers 42.5% of all websites and holds 59.8% of the CMS market among sites running a detectable CMS. There are tens of thousands of plugins, a massive pool of developers, and 20 years of battle-tested hosting patterns. That ecosystem doesn’t disappear overnight.
Today, “migration to EmDash” mostly means pilots, agency proof-of-concepts, and greenfield builds. For most established WordPress sites, moving is not urgent.
But the direction is clear. The developers who understand where website development is going are already building there.
Is This a Chicken-and-Egg Problem?
The common argument against EmDash adoption is that it’s hard to attract users without a developer ecosystem, and hard to attract developers without users.
I don’t think that holds. There are already large numbers of people using AI to build websites who would benefit from a well-structured CMS underneath those sites. Those users don’t need a plugin library first. They need a stable foundation. EmDash provides that now.
If you’re a WordPress developer, the skills for porting existing plugins and themes into EmDash already exist. The barrier to getting started is lower than at any previous point in CMS history. Agents can do much of the mechanical work.
The window where you can get ahead of this curve is open. It won’t stay open.
Frequently Asked Questions
Is EmDash ready for production websites?
EmDash launched as a v0.1.0 preview in April 2026. Early adopters have reported issues, including a data corruption bug affecting Cloudflare D1 under specific full-text search conditions. It’s appropriate for pilots, new builds, and agencies testing the platform. Not yet for high-stakes production sites that can’t afford downtime.
Can you migrate an existing WordPress site to EmDash?
Yes. EmDash provides a WordPress Exporter plugin that adds REST API endpoints to your existing WordPress site. It imports custom post types, media with metadata, custom fields (including ACF), taxonomy structure, and SEO metadata from Yoast and Rank Math. You can also export a WXR file from WordPress admin and import it directly.
Do you need to know TypeScript to build on EmDash?
EmDash themes are Astro projects, so TypeScript is the primary language. Developers comfortable with modern JavaScript stacks will adapt quickly. If you’re primarily a PHP WordPress developer, there’s a learning curve. That said, AI agents can handle a significant portion of the boilerplate, which narrows the gap.
Is EmDash locked into Cloudflare?
Cloudflare built EmDash, and some headline features (specifically the sandboxed plugin system) currently depend on Cloudflare Dynamic Workers, which are only available on paid Cloudflare accounts. That said, EmDash’s README states it runs on any Node.js server with SQLite, and the project uses portable storage abstractions. Cloudflare is the best supported deployment target, not the only one.
Why is Joost de Valk’s migration significant?
Joost spent over 15 years building Yoast SEO, one of the most widely used WordPress plugins ever made. His migration to EmDash is significant because he understands WordPress’s architectural constraints better than almost anyone. When someone with that level of investment in the WordPress ecosystem publicly builds on the alternative, developers pay attention.
If you want a clear picture of where your website stands in AI search, claim your free marketing audit. I’ll personally review your site and walk you through the highest-impact changes you can make right now.