WordPress vs EmDash: a practical comparison for marketing-first teams

There’s a lot of “WordPress is dead” content out there that aged badly. WordPress runs almost half the web, and the obituary writers from 2015 turned out to be wrong. So this isn’t going to be one of those posts.

It’s also not going to pretend EmDash is a like-for-like replacement. It isn’t, and people who pretend otherwise are going to get burned. Cloudflare launched EmDash on April 1, 2026, and as of writing it’s a six-week-old open-source project. It’s going to be a different fit for different teams.

This is the honest comparison we run on intro calls when a prospect asks us “should we migrate?” The answer is genuinely “it depends,” and below are the dimensions it depends on.

Who this is for

This post is for the person who has to make the decision: an in-house marketing lead at an SMB whose dev team is at capacity, an agency PM running 5–50 client microsites, a founder whose CTO doesn’t have time for “stack research.” Not for someone shopping a CMS for a 50-person editorial team running 10,000 articles — different math, different post.

If you’ve already decided you want to migrate and just need the playbook, skip to the four-week migration sequence. If you’re new to the case for moving at all, the original argument is here.

What WordPress is good at — honestly

We are not going to strawman WordPress. The real strengths, in priority order:

Plugin ecosystem. Whatever feature you need, there’s a plugin. CRM integration, learning management, e-commerce, donations, multilingual, paywall, A/B testing, schema.org. EmDash has six first-party example plugins as of April 2026. WordPress has 60,000+. This is a structural advantage that will take years to close, if it ever closes.

Editor familiarity. WordPress has trained two decades of marketers. The Gutenberg block editor, the page builders (Elementor, Beaver, Bricks, Divi, Avada) — there’s enormous installed knowledge. Asking a 50-person marketing org to learn a new editor is a real cost.

Hosting market depth. WP Engine, Kinsta, Pantheon, SiteGround, Pressable — the managed-hosting market for WordPress is competitive and mature. Backups, staging, security patching, support. EmDash hosting in 2026 is “Cloudflare or you do it yourself.”

Recovery options. A broken WordPress site can be fixed by any one of millions of developers, often in hours. A broken EmDash site needs someone who’s read the source. That gap will narrow, but it’s real today.

If any of those four matter more than what’s below, the answer is “stay on WordPress.” We’ve told three prospects that this year.

What WordPress is bad at — in the AI era

What changed in 2025–2026 is that AI agents are now sitting between marketing teams and codebases. WordPress’s structural decisions, which were sensible in 2003, are hostile to that workflow.

Content as a serialized blob. Page-builder content lives in wp_postmeta as serialized PHP. Two pages with the same hero might serialize differently because they were built on different days with different plugin versions. Claude can’t reason statically about that.

Plugins as runtime side effects. Two plugins might both register a hook on init. Whether they collide is only knowable at runtime. AI agents (and senior devs after a year away from the code) can’t predict which combinations break.

Hosting variability. The same plugin behaves differently on WP Engine vs shared hosting because of caching layers, PHP versions, and OPcache settings. AI agents tested against one environment can ship code that breaks on another.

No introspectable schema. Custom Fields plugins help, but they’re optional and inconsistently used. Marketing teams asking Claude to “edit the hero” first need to tell Claude what shape a hero is, on this site, in this plugin’s representation.

These aren’t going to be fixed by WordPress core. They’d require breaking changes the WordPress community is structurally unable to make at scale.

What EmDash is good at

EmDash’s design choices map directly to those AI-era pain points.

Typed schemas. Every content type has a schema, validated at write time. A hero is a hero — Claude reads the schema, knows the fields, edits within constraints.

MCP server in the box. Cloudflare ships MCP support out of the box. Claude Desktop or Cursor configures the EmDash MCP endpoint and immediately knows all your content types, fields, and validations. No glue layer to write.

Sandboxed plugins. Plugins run in Cloudflare Worker isolates with declared permissions. A plugin can’t read fields it wasn’t granted. A misbehaving plugin can’t crash the site — it gets isolated. The “one plugin update broke everything” failure mode goes away.

Performance baseline. EmDash + Astro + Cloudflare Pages ships static-site speed by default. Lighthouse 95+ on mobile is the floor, not the ceiling. WordPress can hit those numbers with effort; EmDash hits them on day one.

Costs. A typical SMB marketing site on WordPress runs $30–80/month in managed hosting plus $20–60/month in plugin licenses. The same site on Cloudflare Pages + EmDash on Workers + R2 typically runs $0–20/month, all in, including the contact-form Worker and image storage.

Portable structure. Astro components and structured content move cleanly to Sanity, Payload, or Decap if EmDash itself fails to take off. WordPress lock-in (page builders, custom plugins, ACF dependencies) is much harder to escape.

What EmDash is bad at — honestly

This is the part most “EmDash review” posts skip. We won’t.

Plugin ecosystem is empty. There are six first-party example plugins. There is no Yoast SEO equivalent. There is no Gravity Forms equivalent. There is no WooCommerce equivalent. We rebuild a lot of that ourselves on each migration; for some clients, that’s a deal-breaker.

Marketer UX is unproven. The TinyMCE editor in EmDash is a regression from Gutenberg. The MCP-via-Claude workflow is the headline feature, but it requires marketers to learn a new way to work. Some teams adopt it in an afternoon; some never do. We don’t have enough data to predict which yet.

Cloudflare lock-in. Yes, EmDash technically runs on Node, Vercel, or Netlify. In practice, it’s best on Cloudflare. R2, D1, Workers — the three integrations that make it sing — all live on Cloudflare. If your org has a “no Cloudflare” policy, this is a real obstacle.

No managed hosting market. No WP Engine equivalent for EmDash exists. You self-host on Cloudflare or you don’t run EmDash. That’s fine for technical teams; it’s a non-starter for orgs that need a phone number to call.

Recovery is harder. When the site breaks at 2am the day before launch, the pool of people who can fix it is a couple hundred developers, not a couple million. That improves with adoption. It’s a real risk today.

It’s beta. v0.1.0. Breaking changes will happen between now and 1.0. We track the EmDash release notes and update client sites within the maintenance retainer; if you’re DIYing, you’re signing up for that vigilance.

Side-by-side comparison

Dimension	WordPress	EmDash
Editor for marketers	Gutenberg + page builders. Familiar, mature, sometimes slow.	TinyMCE + MCP-via-Claude. Newer, faster once trained, fewer guardrails.
AI agent compatibility	Hostile. Serialized blobs, runtime hooks. Possible with effort.	Native. Typed schemas, MCP server in the box.
Plugin ecosystem	60,000+ plugins. Mature.	~6 first-party. Empty.
Performance baseline	Possible to hit Lighthouse 95+ with effort.	Default. CWV-green is the floor.
Hosting cost (typical SMB)	$30–80/month.	$0–20/month.
Plugin license cost	$20–60/month.	$0.
Time to first deploy	Hours (one-click installers).	Hours (after first setup; minutes for subsequent).
Rollback options	Backups, snapshots, well-trodden.	Git + Pages rollback. Younger workflow.
Pool of developers	Millions.	Hundreds.
Lock-in risk	High — page builders + ACF + custom plugins.	Low — Astro + structured content is portable.
Multilingual	Mature plugins (WPML, Polylang).	Possible via Astro routing; no first-party CMS support yet.
E-commerce	WooCommerce.	None. Use Shopify alongside if needed.
Membership / paywall	Mature plugins.	None yet.
SEO tooling	Yoast, Rank Math, Math AI.	DIY via @astrojs/sitemap + manual schema.

Decision framework

When we walk through this on intro calls, we usually land in one of four buckets.

Migrate (about half of our intro calls)

• Marketing-first site (services, landing pages, blog).
• Under 200 pages.
• Page-builder maintenance has become a tax (multiple plugin-collision incidents per year).
• The team is already using AI tools in adjacent workflows (Slack bots, Claude for support, Cursor for dev).
• Hosting bill is a line item the CFO has noticed.
• No e-commerce, no membership, no multilingual. Or those parts are scoped out.

If five of six are true, we recommend migrating. If three or four, it’s a coin flip — usually decided by the team’s appetite for adopting Claude.

Stay (about a quarter)

• WooCommerce or LearnDash powers a meaningful chunk of revenue.
• The marketing team is happy with WordPress and not interested in changing tools.
• Internal IT has a Cloudflare-ban policy.
• The site is large (1,000+ pages) and internal links are tightly woven.

In these cases we tell the prospect to stay, and we don’t bill for the call. Burning a relationship on a bad fit is more expensive than the unbilled hour.

Migrate the marketing site, leave the rest

• The site has a marketing surface (10–80 pages) plus a separate gated/commerce section.
• Move the marketing surface to EmDash on www.example.com.
• Leave the gated section on WordPress at app.example.com or as a subdirectory.
• Marketing gets the AI-edit workflow; commerce stays on the platform that does it well.

This is increasingly our most common recommendation for mid-market companies. It’s a smaller migration with most of the benefit.

Wait three months

• The team is curious but not committed.
• The pain isn’t acute (no recent plugin incidents).
• They want to see EmDash get past v0.5.0 before betting.

Totally fine. We tell them to subscribe to our blog and revisit at the next dev planning cycle. We are not in a rush to add clients; we’re in a rush to add good clients.

What we tell the AI-curious team

A common variant of “should we migrate?” is “we already use Cursor and Claude, what does adopting EmDash actually change in our workflow?” Worth answering directly — that’s the vibecoding-a-marketing-site post. Short version: it changes whether your AI tools see typed structure or serialized blob. It changes whether marketing can edit through Claude or has to file a ticket. It does not change anything about how you write code in your editor.

What this comparison costs to validate yourself

If you want to test EmDash before committing to a migration:

1. Spin up a fresh EmDash instance on a Cloudflare Workers free tier. ~30 minutes.
2. Run wp export on your WordPress site and emdash import on the new instance. ~1 hour.
3. Pick the five most-edited pages on your live site. Ask Claude (with MCP wired up) to make a copy change to each one. Time how long it takes.
4. If steps 1–3 take less than half a day and the test edits feel reasonable, the full migration is realistic.

Cost: about a half-day of one developer’s time. We do this as a paid evaluation engagement for $500 if a team wants us to drive it instead of DIYing. The output is a written go/no-go memo with the actual migration estimate.

FAQ

Should I migrate to EmDash now or wait for a 1.0 release?

Depends on your pain. If page-builder collisions cost you multiple incidents a year and your site is under 200 pages, the math points toward migrating now. If the site is stable and your team isn’t using AI tools yet, wait. Our internal estimate gives EmDash a 30–40% chance of meaningful adoption inside 18 months (Cloudflare blog, 2026).

Is EmDash a fork of WordPress?

No. EmDash is a ground-up TypeScript stack built on Astro, Cloudflare Workers, and D1 — no PHP, no MySQL, no shared lineage with the WordPress codebase. The naming is a nod to the editorial em dash, not an indicator of code heritage. The repo and six first-party example plugins are public (EmDash GitHub, 2026).

Will my SEO suffer during migration?

Not if redirects are done right. The risk is broken URLs and lost canonicals, not the platform swap itself. Map every old WordPress URL to its new path with 301 redirects before launch, preserve title tags and meta descriptions, and resubmit your sitemap (Astro docs, 2026). Most migrations we run see flat or improved rankings within four weeks.

Does EmDash have a marketplace like the WordPress plugin store?

Not yet. The registry lives in the EmDash repo as a registry/ directory, with submission via pull request (EmDash GitHub, 2026). Six first-party examples ship in the box; community submissions are in single digits as of writing. If your site needs WooCommerce, Yoast, or Gravity Forms equivalents on day one, this gap is a deal-breaker.

What’s the smallest project where this comparison even matters?

Marketing sites under 200 pages with no e-commerce, no membership, and no multilingual requirement. Below that threshold the AI-editing benefit, hosting cost delta, and performance baseline actually compound. Above 1,000 pages with tightly woven internal links and revenue-driving plugins, WordPress’s ecosystem advantage usually wins (Joost, 2026).

Bottom line

WordPress isn’t going anywhere, and that’s fine. EmDash isn’t going to replace WordPress for everyone, and that’s also fine. What EmDash is going to do is take the marketing-site segment of WordPress’s market — the SMB and agency-microsite use cases where AI editing matters and plugin ecosystem doesn’t.

If you’re in that segment, the math points toward migrating now. If you’re not, stay where you are. We’ll write a different post for you.