I’ve been building WordPress plugins for over a decade. I know the ecosystem inside out, the hooks, the filters, the way wp_options quietly becomes your application’s junk drawer, the moment you realize a single rogue plugin can read your entire database. I’ve made my peace with most of it.

But something has been happening lately that I can’t ignore.

Multiple developers, people who don’t know each other, working in different countries, solving different problems, are independently converging on the exact same architecture. The same stack. The same ideas about what WordPress should become.

A team built EmDash, a full CMS that reimagines WordPress on TypeScript and Astro. We built WP Astro MCP, a tool that adds an Astro frontend layer to WordPress sites through AI-powered automation. On Reddit, developers are posting about WordPress blocks not scaling. On Dev.to, the hottest articles are about AI agents and memory. On Hacker News, people are debating whether the CMS model itself needs a rethink.

And it’s not just indie developers and side projects. The people who built the WordPress ecosystem, the ones who shaped how millions of us use it, are making the same move.

Nobody coordinated this. We all just arrived at the same place.

And when unrelated people independently build the same thing, that’s not a coincidence. That’s a signal.

When WordPress Leaders Choose Astro

Let me tell you what made this feel real, not theoretical, not “maybe someday,” but happening right now.

Joost de Valk moved his personal site from WordPress to Astro. If that name doesn’t ring a bell, Joost is the founder of Yoast SEO, the plugin that literally defined how the WordPress world thinks about search engine optimization. When the person who built the most influential WordPress SEO plugin decides he doesn’t need WordPress for his own site, that’s worth paying attention to.

Joost’s setup is elegant in its simplicity: Astro on Cloudflare Pages, with a collection of Markdown files that get built into static HTML. No database. No server. No PHP. And here’s the part that should make every WordPress developer think twice, he found that SEO is actually easier to get right on a static site because you control the entire HTML output. The founder of Yoast saying that static sites give you more SEO control than WordPress is a sentence I never expected to write.

He’s not anti-WordPress. He acknowledges that CMSes still matter for multi-user collaboration, dynamic content, and application-level functionality. He’s even building a new project called Rondo on WordPress because it genuinely needs dynamic features. But for content sites? His conclusion is stark: most people don’t need a CMS, they need a website. And the overhead of running a full CMS for a content site is increasingly hard to justify.

His prediction about AI is even more striking: “When editing a static site becomes as easy as sending a message, the CMS’s core advantage for the majority of websites disappears.” That future is closer than most people think. It’s what MCP-powered tools are already making possible.

Chris Lema moved from WordPress to Astro with Payload CMS. Chris is one of the most respected voices in the WordPress business ecosystem, someone who’s spent years advising WordPress product companies and agencies. His reason for switching wasn’t performance or cost. It was AI agents.

“I wanted agents to be first-class participants in my content workflow. Not helpers. Participants.”

That single sentence captures what’s driving this entire movement. Chris wanted to build workflows where AI agents don’t just suggest edits, they participate in the content pipeline. They scan files, optimize for SEO, shape content across platforms. And to do that, he needed his content infrastructure to be accessible to code and AI in ways that WordPress’s architecture makes difficult.

He’s honest about the tradeoffs. Things that WordPress handles invisibly, draft and publish status, image optimization, media management, required manual configuration in the new stack. “You don’t have to deal with this in WordPress. Draft and publish status come for free,” he notes. The migration isn’t for everyone. Chris himself calls it “the tax you pay for operating at the bleeding edge” and estimates his use case is “the .001%.”

But here’s the thing, that .001% is growing. Every developer who builds an MCP server, every team that deploys a headless WordPress setup, every agency that discovers Astro’s performance advantages is expanding that sliver. What’s bleeding edge today becomes best practice tomorrow.

What EmDash Tells Us About Where CMS Is Headed

EmDash is an open-source project that caught my attention because it doesn’t just criticize WordPress, it rebuilds the ideas that made WordPress dominant, using today’s tools.

It’s a full-stack TypeScript CMS built natively on Astro. Not a headless WordPress plugin. Not a static site generator with a content layer bolted on. A complete content management system, admin panel, REST API, authentication, media library, plugin system, rebuilt from scratch on serverless, type-safe foundations.

What made me stop and study it was the plugin architecture.

Here’s the uncomfortable truth we all know but rarely say out loud: 96% of WordPress security vulnerabilities come from plugins. That’s not a bug in the ecosystem, it’s a fundamental architectural problem. WordPress plugins have full access to the database, the filesystem, and every user’s data. A contact form plugin can read your payment records. A social sharing widget can modify your posts table. The trust model is “install and pray.”

EmDash takes a different approach. Plugins run in isolated Worker sandboxes via Cloudflare’s Dynamic Worker Loaders. Each plugin declares a capability manifest, it requests read:content and email:send, and that’s exactly what it can do. Nothing else. No filesystem access. No database free-for-all. The plugin boundary is enforced at the runtime level, not by convention.

export default () =>
  definePlugin({
    id: "notify-on-publish",
    capabilities: ["read:content", "email:send"],
    hooks: {
      "content:afterSave": async (event, ctx) => {
        if (event.content.status !== "published") return;
        await ctx.email.send({
          to: "editors@example.com",
          subject: `New post: ${event.content.title}`,
        });
      },
    },
  });

This is what WordPress’s plugin architecture would look like if you designed it in 2026 instead of 2004.

Then there’s the content model. WordPress stores rich text as HTML with metadata embedded in comments, tying your content permanently to its DOM representation. EmDash uses Portable Text, a structured JSON format that decouples content from presentation. Your blog post can render as a web page, a mobile app screen, an email newsletter, or an API response, without parsing HTML. The content is the content. The presentation is a separate concern.

And the part that really got my attention: EmDash ships with a built-in MCP server. AI tools like Claude can interact with your site directly, managing content, modifying schema, building plugins. This isn’t a bolt-on integration. It’s a first-class architectural decision. The CMS was designed from day one to be operated by both humans and AI agents.

EmDash is in beta. It has around 1,800 stars on GitHub. It’s MIT licensed. And it’s a clear signal of where CMS architecture is heading.

What We’re Building with WP Astro MCP

While EmDash represents the “rebuild everything” approach, we’ve been working on the bridge.

WP Astro MCP is a Model Context Protocol server that turns WordPress into a headless CMS with an Astro frontend. The philosophy is different from EmDash: we’re not replacing WordPress. We’re adding a fast, secure, public-facing Astro layer while keeping WordPress as the content engine behind the scenes. I wrote about the early days of building this in how I built an MCP server that connects WordPress to Astro, and the journey since then has evolved significantly.

The core idea: WordPress is excellent at content management. The admin UI, the editor, the workflow for non-technical content creators, all of that works. What doesn’t scale is exposing that same WordPress installation to the public. PHP templating, full-page caching to compensate for dynamic generation, the security surface area of running a publicly accessible PHP application. We wanted to separate the CMS (where WordPress excels) from the frontend (where Astro excels). WordPress moves to a private subdomain. Astro serves the public domain. Editors keep using wp-admin. Visitors get static HTML.

The v3.0 “Living Bridge” architecture ships in two pieces that work together:

WP Astro MCP (the MCP server) provides 57 specialized tools organized into nine groups: site management, content extraction, transformation, output and media handling, GitHub integration, export pipelines, content synchronization, a setup wizard, and webhook processing. But here’s the design decision I’m most proud of: we don’t expose all 57 tools directly.

Instead, we use a router pattern with just three meta-tools: wp_astro_run, wp_astro_help, and wp_astro_describe. Claude discovers and invokes the right tool through natural conversation. You say “set up an Astro frontend for my WordPress site” and the MCP server handles the rest: pulling content via REST API, running it through a 13-step transformation pipeline, scaffolding a complete Astro project with search, pagination, related posts, and JSON Feed, and pushing it to GitHub.

The new setup_wizard command does the entire flow in one shot: register your WordPress site, analyze content, configure export, preview sample posts, scaffold the Astro project, export all content, generate redirects, and initialize git. What used to be 8-10 separate commands is now a single guided flow. Five minutes from “I have a WordPress blog” to “I have a deployed Astro frontend on Vercel.”

wp-astro-bridge (a lightweight WordPress plugin) is the second piece. Three PHP classes, zero dependencies, zero bloat. It does three things:

  • Webhook dispatcher: when an editor publishes, updates, or deletes a post, the plugin fires an HMAC-signed webhook to the Astro deployment platform. The site rebuilds automatically within 1-2 minutes. No manual sync needed.
  • Preview URL rewriter: the WordPress “Preview” button gets rewritten to point to the Astro frontend’s /preview route. Editors click Preview and see their draft rendered on the real Astro design, not the WordPress theme. Token-based authentication with 5-minute expiry, no shared secrets.
  • Normalized SEO REST field: a single astro_seo REST field that returns the same format regardless of whether the site uses Yoast, RankMath, or AIOSEO. Title, description, canonical, OG image, robots, focus keyword. One API, three plugin adapters.

The combination changes what “headless WordPress” feels like in practice. Without the bridge plugin, it’s a build-time tool: export content, deploy, done. With it, WordPress and Astro stay connected. Editors publish in WordPress, the Astro site updates automatically, drafts are previewable on the real frontend. The content team doesn’t need to learn anything new. The development team gets a modern, performant, secure frontend that stays current without manual intervention.

That 13-step content pipeline is where the real engineering lives. WordPress content comes through the REST API as rendered HTML. The pipeline sanitizes it with DOMPurify, resolves shortcodes, strips Gutenberg block comments, normalizes HTML, converts to clean Markdown via Turndown with WordPress-specific rules, rewrites internal links to Astro paths, handles media URLs, cleans conversion artifacts, processes embeds, and validates the output. Standard Gutenberg and classic editor content converts cleanly. We’re honest about the limitations: page builder content (Elementor, WPBakery, Divi) comes through as deeply nested HTML with far more markup than actual text. The converter extracts the content, but complex visual layouts don’t carry over. This tool works best with content-focused WordPress sites using the standard editor.

The scaffolded Astro project ships production-ready: paginated blog index, Pagefind-powered search, related posts computed at build time, JSON Feed alongside RSS and sitemap, Open Graph metadata, JSON-LD structured data, reading progress bar, and a proper 404 page. It targets Astro 6 with hybrid rendering mode, so the preview route works as an SSR page while everything else stays static.

The result: a WordPress site with thousands of posts can get a fast, secure, deployable Astro frontend through a conversation with Claude. And the content stays in sync going forward, either through scheduled cron sync (no plugin needed) or instant webhook-triggered rebuilds (with the plugin). The whole system is open source, free, and runs entirely on your infrastructure.

How MCP Changes Everything for WordPress Developers

If you’re a WordPress developer and you haven’t explored MCP yet, you’re missing the most important shift in developer tooling since package managers. The Model Context Protocol isn’t just another API standard, it’s a way to give AI assistants structured, domain-specific capabilities that go far beyond chat.

I’ve been using MCP servers in my daily WordPress workflow for months now, and the productivity shift is real. Instead of context-switching between the WordPress admin, terminal, database client, and documentation, I have specialized MCP tools that handle each domain. Content migration, code analysis, database queries, deployment, all accessible through natural conversation with an AI that understands the WordPress ecosystem.

What makes MCP different from just asking ChatGPT or Claude a question is the tool layer. When you ask a generic AI to “migrate my WordPress site,” it gives you a list of steps. When you give an AI access to an MCP server built for WordPress migration, it actually does the migration. It connects to your WordPress REST API, pulls content, transforms it, generates files, and pushes to GitHub. The difference is between advice and action.

This is why the MCP ecosystem is growing so fast. Developers are building domain-specific MCP servers for everything, database management, deployment automation, content moderation, SEO optimization. Each server encapsulates expert knowledge in a format that AI can execute, not just discuss. And because MCP is an open protocol, these servers compose. You can chain a WordPress content extraction server with an Astro project scaffolding server with a Cloudflare deployment server, and the AI orchestrates the entire pipeline.

The WordPress ecosystem is uniquely positioned to benefit from this. WordPress has the richest REST API of any CMS. It has the most standardized data model. It has the largest library of hooks and filters that MCP servers can leverage. The tooling surface area is massive, and MCP is the protocol that unlocks it for AI-powered automation.

The Community Is Saying the Same Thing

What convinced me this is a real movement, not just a few projects, is the community conversation happening right now.

On r/ProWordPress, a post titled “WordPress blocks don’t scale. We built a registry system to fix it” sparked 18 comments of developers sharing the same frustrations. The block editor is powerful for content, but the developer experience of building and maintaining custom blocks at scale is hitting real walls. Teams are discovering that what works for 10 blocks breaks down at 50, and the tooling to manage block libraries at enterprise scale simply doesn’t exist in core WordPress.

On r/webdev, “AI has sucked all the fun out of programming” got 1,400 upvotes and 377 comments. But read past the headline, the real conversation isn’t anti-AI. It’s about wanting AI to handle the tedious parts (migration, boilerplate, configuration) so developers can focus on architecture and creativity. That’s exactly what MCP-powered tools do. The developers in that thread aren’t rejecting AI, they’re rejecting AI that tries to replace thinking. They want AI that eliminates drudgery. There’s a massive difference.

On Dev.to, the most popular article of the week was “Your agent can think. It can’t remember”, about AI agents, MCP, and persistent state. 153 reactions. The tags: ai, mcp, postgres, agents. People are building with MCP right now, and they’re excited about it.

On Hacker News, “Move Over, SaaS Dashboards: 2026 Is the Year of Agents-as-a-Service” made the front page. The conversation underneath is about how domain-specific MCP servers, exactly like what we built for WordPress-to-Astro migration, are more useful than generic AI assistants.

And then there’s the sentiment I keep seeing in WordPress communities: people love the content management, but they’re increasingly frustrated with the rendering architecture, the security model, and the performance workarounds. They don’t want to abandon WordPress. They want WordPress to evolve.

The Stack Everyone Is Converging On

Here’s what fascinates me. Without any coordination, multiple independent projects and conversations are pointing to the same architectural stack:

TypeScript instead of PHP for the application layer. Not because PHP is bad, it powers 40% of the web. But because TypeScript gives you type safety across the database, API, and UI layers simultaneously. When your CMS schema generates TypeScript types that your frontend components consume, entire categories of bugs simply disappear.

Astro as the rendering framework. Server-side rendering by default, with client-side interactivity only where needed (the “islands” architecture). Built-in content collections. Excellent performance without configuration. Astro isn’t trying to be React or Next.js, it’s purpose-built for content-driven sites, which is exactly what CMS platforms produce. A blog built on Astro ships zero JavaScript to the browser by default. A WordPress blog ships jQuery, wp-emoji, block library CSS, and whatever else the theme and plugins inject. The performance difference is not incremental, it’s categorical.

MCP as the AI integration layer. The Model Context Protocol gives AI assistants like Claude structured access to domain-specific tools. Instead of asking an AI to “figure out” how to migrate content, you give it purpose-built tools for content extraction, transformation, and deployment. The AI handles orchestration. The tools handle domain logic.

Serverless and edge computing for deployment. Cloudflare Workers, D1, R2. No server to maintain. No PHP version to manage. No caching layer to configure. Your CMS runs at the edge, close to your users, with zero infrastructure overhead.

WordPress as a content source, not a rendering engine. This is the key insight that ties everything together. WordPress’s strength is content management, the editor, the workflow, the user experience for non-technical creators. Its weakness is everything that happens after the content is created: rendering, caching, security, performance optimization. The modern approach decouples these concerns.

EmDash chose to rebuild the content management layer from scratch with this stack. We chose to keep WordPress for content management and build the rendering bridge. Joost went full static with Markdown. Chris chose Payload CMS. The destination varies, but the direction is the same: away from monolithic WordPress rendering, toward Astro, TypeScript, and AI-native infrastructure. The convergence is organic, and that’s what makes it meaningful.

What This Means If You’re a WordPress Developer

If you’ve spent years in the WordPress ecosystem, this moment might feel uncomfortable. It might feel like the ground is shifting. But I want to be clear about something: WordPress isn’t dying. WordPress powers 43% of the web. It has the largest CMS ecosystem on the planet. The content management experience is unmatched for non-technical users.

What’s changing is the architecture around WordPress.

The rendering layer is decoupling. Static site generators and modern frameworks are taking over the frontend. The “headless WordPress” approach, using WordPress for content management while rendering with Astro, Next.js, or similar, is moving from experimental to mainstream. Agencies that resisted headless two years ago are now actively building on it because clients demand the performance and security benefits.

AI agents are becoming first-class CMS citizens. Not as chatbots or content generators, but as operational tools. An MCP server that can migrate 5,000 posts, clean up page builder markup, and deploy to Cloudflare, that’s not replacing developers. That’s giving developers leverage.

The security model is getting a fundamental rethink. EmDash’s sandboxed plugin architecture isn’t just clever engineering, it’s a response to a decade of plugin-related security incidents that the traditional WordPress architecture can’t solve without breaking backward compatibility. Future CMS platforms will treat plugin isolation as a baseline requirement, not a nice-to-have.

And the opportunity for WordPress developers is enormous. If you understand both worlds, the WordPress content model and the modern rendering stack, you’re uniquely positioned. You can build the bridges. You can help organizations evolve their WordPress investments without throwing everything away. You can contribute to projects like EmDash or WP Astro MCP that are defining what this transition looks like.

The worst response is to pick sides. “WordPress forever” or “WordPress is legacy” are both wrong. The right response is to understand the forces at work and build at the intersection.

Build What Feels Right

The most reliable signal in technology is when unrelated people, solving different problems, independently arrive at the same architecture. It means the architecture is responding to real forces, not hype, not marketing, but the actual constraints and opportunities that developers face every day.

TypeScript, Astro, MCP, edge deployment, WordPress as a content platform, this stack isn’t being promoted by any single company. It’s emerging from the work of developers who got tired of workarounds and started building what felt right.

Joost de Valk is building on it. Chris Lema is building on it. The EmDash team is building on it. We’re building on it. And the community conversations, on Reddit, Hacker News, Dev.to, confirm that thousands more are thinking the same way.

If any of this resonates, here’s where to start:

Something is happening. And the best time to be part of it is right now.