WordPress 作为自动答案已经死了，而不是作为软件。
这个区别很重要。如果你说 "WordPress 已死" 作为一个字面上的市场声明，数据会否定它。W3Techs 报告称，截至 2026 年 6 月，WordPress 驱动着 59.2% 的已知 CMS 网站和 41.5% 的所有网站。你不能称之为死亡。
但是如果你在 2026 年构建网站，旧的反应开始感觉不对。客户想要一个快速的网站，自定义布局，干净的 SEO，一些集成，以及一个不需要十个插件的编辑工作流。过去的答案是 WordPress，因为自定义代码既慢又贵。AI 改变了这个计算。
Cloudflare 的 EmDash 使得这种转变更难以忽视。Cloudflare 并不是说 WordPress 没有价值。它是在说下一个 CMS 可以是 TypeScript、无服务器、Astro 驱动、插件沙盒化，并且从第一天起就为 AI 代理构建。
我仍然尊重 WordPress。我仍然会在合适的项目中使用它。我不再认为它应该是默认选择。
为什么 WordPress 作为默认选择已死
WordPress 胜出是因为它赋予了非技术人员发布的权力。这是一个真正的突破。你可以安装一个主题，添加一个页面构建器，发布博客文章，添加表单，添加 SEO 元数据，并将网站交给客户。
这个推销在很多商业网站上显得不再适用。
一个简单的网站往往变成一堆插件：页面构建器、缓存插件、SEO 插件、表单插件、安全插件、图像插件、Cookie 插件、重定向插件、架构插件，有时还需要一个自定义字段插件来减少页面构建器的痛苦。每个部分都会增加更新、设置、数据库表、资产和另一个故障点。
问题不在于 WordPress 核心。问题在于许多 WordPress 项目在一年后所采取的操作形态。网站变成了一个小型后端系统，页面本可以作为干净的 HTML、小型 CMS 和一些 API 调用发布。
Patchstack 的 2026 年 WordPress 安全报告使得维护成本更难以忽视。报告称，2025 年在 WordPress 生态系统中发现了 11,334 个新漏洞，比 2024 年增加了 42%。它还指出，91% 的新漏洞出现在插件中，9% 在主题中，只有 6 个漏洞在 WordPress 核心中被报告，且都是低优先级。
这就是重点。WordPress 本身并不是恶棍。风险存在于插件表面。
EmDash 是最清晰的信号
这是我应该从一开始就包含的部分。Cloudflare 于 2026 年 4 月 1 日推出了 EmDash 的 v0.1.0 预览，并将其描述为 WordPress 的精神继承者。
细节与本文中的论点一致。EmDash 是用 TypeScript 编写的，基于 Astro，开源于 MIT，并为无服务器托管而设计。它还针对 WordPress 不断出现的痛点：插件。
在 WordPress 中，插件在与网站相同的环境中运行。它可以以需要大量信任的方式接触数据库、文件系统和运行时。Cloudflare 的 EmDash 模型将插件推入隔离的动态工作者，并通过绑定赋予它们声明的能力。插件应该在执行工作之前请求所需的确切权限，例如读取内容或发送电子邮件。
这就是现代 CMS 的理念：减少环境信任，增加明确权限。
EmDash 还很重要，因为它将 AI 代理视为工作流的一部分。Cloudflare 表示，每个 EmDash 实例可以暴露一个远程 MCP 服务器，以及 CLI 工具和代理技能。这意味着编码代理可以通过结构化工具管理内容、架构、媒体和迁移工作，而不是抓取管理面板或猜测数据的位置。
我今天不会告诉客户盲目迁移到 EmDash。这是一个预览。重要的是方向：Cloudflare 正在围绕我现在希望从网站中获得的相同内容构建 WordPress 替代品：沙盒扩展、干净的前端架构、编程控制和代理可读操作。
AI 改变了自定义网站的计算
几年前，自定义意味着昂贵。你要么支付开发人员构建每个页面和组件，要么使用页面构建器并接受其重量。
AI 使得中间路径变得可行。你可以描述布局，生成组件，调整间距，撰写文案，创建结构化内容，构建一个小型管理流程，并连接所需的确切服务。像 v0、Framer AI、Webflow AI、Lovable 风格的应用构建器和现代编码代理等工具使得自定义界面的生产速度更快。
这并不意味着 AI 取代了品味、质量保证或工程判断。它意味着初稿不再占用整个预算。
这就是 WordPress 失去默认位置的地方。如果我可以获得一个与品牌完全匹配、加载快速、发布干净架构并避免沉重后端的自定义 Next.js、Astro、EmDash 或 Webflow 构建，那么 WordPress 的妥协就变得更难以辩解。
页面构建器给你旋钮。AI 辅助的代码工作流给你实际的系统：组件、内容模型、路由、元数据、图像处理、表单、分析和部署规则。你可以检查它。你可以对其进行版本控制。你可以测试它。
这比主题市场更重要。
后端应该匹配工作
宣传网站默认情况下不需要数据库支持的管理面板。着陆页不需要 PHP、MySQL、二十个选项屏幕和缓存层来看起来快速。
当项目需要后端时使用它：
不要因为主题需要存储块的地方而添加后端。
一个精简的现代堆栈可以更小。静态页面、服务器渲染的路由、无头 CMS、Supabase、基于 Git 的内容流、托管表单、Stripe、搜索提供者和小型 API 覆盖了大部分网站。你会得到更少的移动部件和更好的性能控制。
这也是我关心干净 HTML 和经过测量的 SEO 工作的原因。在我的 Lighthouse SEO 分数案例研究→ 中，胜利来自于严谨的标记、架构、速度、可访问性和缓存。网站构建器可以提供帮助，但最终输出仍然必须被浏览器、搜索引擎和 AI 代理可读。
AI 使得精确设计成本更低
反对 WordPress 的最有力论据不再仅仅是速度。它是设计控制。
大多数 WordPress 项目从一个主题开始，然后使品牌适应它。你更改字体、颜色、部分和间距，但主题仍然留下指纹。网站看起来像是构建它的工具。
AI 翻转了这个工作流程。你可以从品牌、产品、受众和实际交互模型开始。然后你围绕这些约束生成界面。
这是一个更好的顺序。
一个咨询网站可以拥有它所需的确切证明结构。一个 SaaS 页面可以展示一个密集的产品表面，而不是一个通用的英雄。一个音乐产品页面可以感觉像一个真正的工作室工具，而不是一个模板。一个本地商业页面可以在不与主题布局假设作斗争的情况下，使预订、信任、位置和服务信息可见。
输出仍然需要审查。AI 可能生成糟糕的 CSS、弱的可访问性、臃肿的 JavaScript 和模糊的文案。人类仍然需要检查页面，测试移动端，检查链接，验证元数据，运行 Lighthouse，并保持写作的诚实。
但 AI 消除了自定义意味着缓慢的借口。
WordPress 仍然胜出的时候
当编辑工作流是产品时，我仍然会选择 WordPress。
如果一个团队发布许多帖子，使用现有的 WordPress 编辑习惯，依赖 WooCommerce，需要特定的成熟插件，或者已经在稳定的 WordPress 设置中拥有多年的 SEO 历史，那么为了时尚而重建是一个糟糕的选择。
WordPress 对于需要熟悉的管理界面而不是自定义前端的团队也很有效。人们已经知道的工具是有价值的。
错误在于在询问网站需要做什么之前选择 WordPress。
对于许多新构建，网站需要速度、结构、自定义设计、受控集成和低维护。WordPress 可以做到这些，但它通常通过额外的层达到这些目标。AI 辅助的自定义构建更直接地实现这些目标。
我的实用规则
我今天在选择 WordPress 之前会问三个问题。
首先，客户是否特别需要 WordPress 管理体验？
其次，一个插件是否比小型自定义集成更好地解决了一个棘手的业务问题？
第三，经过十二个月的更新、营销请求、跟踪脚本和内容更改后，网站是否仍然容易维护？
如果答案是肯定的，WordPress 可能是正确的选择。
如果答案是否定的，我会从更轻的架构开始，并使用 AI 构建确切的界面。这可能意味着一个静态网站、一个无头 CMS、一个 React 或 Astro 前端、EmDash、Webflow、Framer 或一个小型全栈应用。堆栈应该适合工作，而不是习惯。
这也是 AI 代理变得有用的地方。一个好的代理可以检查网站，验证链接，检查元数据，测试构建，更新内容，并留下痕迹。我在我的 MCP 开发者工作流文章→ 中写到了这个控制层。相同的理念适用于网站：工具应该暴露明确的操作，而不是将一切隐藏在插件屏幕后面。
结论
WordPress 作为自动答案已经死了。WordPress 作为软件并没有死。
EmDash 还处于早期阶段，但它展示了 CMS 讨论的方向：默认无服务器、友好的 TypeScript、前端原生、安全的插件边界，以及 AI 代理工作流，而不是手动管理琐事。
网络已经朝着更快的前端、更小的后端、AI 辅助设计和对最终输出的更明确控制发展。WordPress 仍然有一席之地，但它必须在每个项目中赢得这个位置。
如果你需要一个发布机器，就使用一个。如果你需要一个感觉精确、加载快速并避免沉重后端的自定义网站，AI 使得更好的路径更容易选择。