WordPress is dead as the automatic answer, not as software.
That distinction matters. If you say "WordPress is dead" as a literal market claim, the data rejects it. W3Techs reports that WordPress powers 59.2% of websites with a known CMS and 41.5% of all websites as of June 2026. You do not call that dead.
But if you build websites in 2026, the old reflex has started to feel wrong. A client wants a fast site, custom layout, clean SEO, a few integrations, and an editing workflow that does not need ten plugins. The answer used to be WordPress because custom code was slow and expensive. AI changed that calculation.
Cloudflare's EmDash makes the shift harder to ignore. Cloudflare is not saying WordPress has no value. It is saying the next CMS can be TypeScript, serverless, Astro-powered, plugin-sandboxed, and built for AI agents from day one.
I still respect WordPress. I would still use it in the right project. I no longer think it deserves to be the default.
Why WordPress is dead as the default
WordPress won because it gave non-technical people publishing power. That was a real breakthrough. You could install a theme, add a page builder, publish blog posts, add forms, add SEO metadata, and hand the site to a client.
That pitch aged badly for a lot of business sites.
A simple site often becomes a stack of plugins: page builder, cache plugin, SEO plugin, form plugin, security plugin, image plugin, cookie plugin, redirects plugin, schema plugin, and sometimes a custom field plugin to make the page builder less painful. Each piece adds updates, settings, database tables, assets, and another failure point.
The problem is not WordPress core. The problem is the operational shape many WordPress projects take after a year. The site becomes a small backend system for pages that could have shipped as clean HTML, a small CMS, and a few API calls.
Patchstack's 2026 WordPress security report makes the maintenance cost harder to ignore. The report says 11,334 new vulnerabilities were found in the WordPress ecosystem in 2025, up 42% from 2024. It also says 91% of new vulnerabilities were found in plugins, 9% in themes, and only 6 vulnerabilities were reported in WordPress core, all low priority.
That is the point. WordPress itself is not the villain. The plugin surface is where the risk lives.
EmDash is the cleanest signal
This was the part I should have included from the start. Cloudflare introduced EmDash on April 1, 2026 as a v0.1.0 preview and described it as a spiritual successor to WordPress.
The details line up with the argument in this article. EmDash is written in TypeScript, powered by Astro, open source under MIT, and designed for serverless hosting. It also targets the specific WordPress pain point that keeps coming back: plugins.
In WordPress, a plugin runs inside the same world as the site. It can touch the database, filesystem, and runtime in ways that require a lot of trust. Cloudflare's EmDash model pushes plugins into isolated Dynamic Workers and gives them declared capabilities through bindings. A plugin should ask for the exact permissions it needs, such as reading content or sending email, before it can do that work.
That is the modern CMS idea: less ambient trust, more explicit permissions.
EmDash also matters because it treats AI agents as part of the workflow. Cloudflare says every EmDash instance can expose a remote MCP server, plus CLI tooling and agent skills. That means a coding agent can manage content, schemas, media, and migration work through structured tools instead of scraping an admin panel or guessing where data lives.
I would not tell a client to migrate to EmDash blindly today. It is a preview. The important part is the direction: Cloudflare is building the WordPress replacement around the same things I now want from websites: sandboxed extensions, clean frontend architecture, programmatic control, and agent-readable operations.
AI changed the custom-site math
A few years ago, custom meant expensive. You either paid a developer to build every page and component, or you used a page builder and accepted the weight.
AI makes the middle path practical. You can describe a layout, generate components, refine spacing, write copy, create structured content, build a small admin flow, and connect the exact services you need. Tools like v0, Framer AI, Webflow AI, Lovable-style app builders, and modern coding agents have made custom interfaces faster to produce.
That does not mean AI replaces taste, QA, or engineering judgment. It means the first draft no longer takes the whole budget.
This is where WordPress loses its default position. If I can get a custom Next.js, Astro, EmDash, or Webflow build that matches the brand exactly, loads fast, ships clean schema, and avoids a heavy backend, the WordPress compromise becomes harder to justify.
A page builder gives you knobs. An AI-assisted code workflow gives you the actual system: components, content model, routes, metadata, image handling, forms, analytics, and deployment rules. You can inspect it. You can version it. You can test it.
That matters more than a theme marketplace.
The backend should match the job
A brochure site does not need a database-backed admin panel by default. A landing page does not need PHP, MySQL, twenty options screens, and a cache layer to look fast.
Use a backend when the project needs one:
Do not add a backend because a theme needs somewhere to store blocks.
A lean modern stack can be smaller. Static pages, server-rendered routes, a headless CMS, Supabase, a Git-based content flow, hosted forms, Stripe, a search provider, and a small API cover a large percentage of websites. You get fewer moving parts and better control over performance.
This is the same reason I care about clean HTML and measured SEO work. In my Lighthouse SEO score case study→, the win came from disciplined markup, schema, speed, accessibility, and caching. A site builder can help, but the final output still has to be readable by browsers, search engines, and AI agents.
AI makes exact design less expensive
The strongest case against WordPress is no longer speed alone. It is design control.
Most WordPress projects start with a theme, then bend the brand to fit it. You change fonts, colors, sections, and spacing, but the theme still leaves fingerprints. The site looks like the tool that built it.
AI flips that workflow. You can start with the brand, the offer, the audience, and the actual interaction model. Then you generate the interface around those constraints.
That is a better order.
A consultant site can have the exact proof structure it needs. A SaaS page can show a dense product surface instead of a generic hero. A music product page can feel like a real studio tool instead of a template. A local business page can make booking, trust, location, and service information visible without fighting a theme's layout assumptions.
The output still needs review. AI can generate bad CSS, weak accessibility, bloated JavaScript, and vague copy. A human still has to inspect the page, test mobile, check links, verify metadata, run Lighthouse, and keep the writing honest.
But AI removes the excuse that custom means slow.
When WordPress still wins
I would still choose WordPress when the editing workflow is the product.
If a team publishes many posts, uses existing WordPress editorial habits, depends on WooCommerce, needs specific mature plugins, or already has years of SEO history in a stable WordPress setup, rebuilding for fashion is a bad move.
WordPress also works well for teams that need a familiar admin surface more than they need a custom frontend. There is value in a tool people already know.
The mistake is choosing WordPress before asking what the site needs to do.
For many new builds, the site needs speed, structure, custom design, controlled integrations, and low maintenance. WordPress can do those things, but it often reaches them through extra layers. AI-assisted custom builds reach them more directly.
My practical rule
I would ask three questions before choosing WordPress today.
First, does the client need the WordPress admin experience specifically?
Second, does a plugin solve a hard business problem better than a small custom integration?
Third, will the site still be easy to maintain after twelve months of updates, marketing requests, tracking scripts, and content changes?
If the answer is yes, WordPress can be the right call.
If the answer is no, I would start with a lighter architecture and use AI to build the exact interface. That can mean a static site, a headless CMS, a React or Astro frontend, EmDash, Webflow, Framer, or a small full-stack app. The stack should fit the work, not the habit.
This is also where AI agents become useful. A good agent can inspect the site, verify links, check metadata, test a build, update content, and leave a trail. I wrote about that control layer in my MCP developer workflows article→. The same idea applies to websites: tools should expose clear actions, not hide everything behind a plugin screen.
Verdict
WordPress is dead as the automatic answer. WordPress is not dead as software.
EmDash is early, but it shows where the CMS conversation is going: serverless by default, TypeScript-friendly, frontend-native, safer plugin boundaries, and AI-agent workflows instead of manual admin chores.
The web has moved toward faster frontends, smaller backends, AI-assisted design, and more explicit control over the final output. WordPress still has a place, but it has to earn that place project by project.
If you need a publishing machine, use one. If you need a custom website that feels exact, loads fast, and avoids a heavy backend, AI has made the better path easier to take.
