回到2017年，一个客户惊慌失措地给我打电话。她在GoDaddy的建站工具上搭建了自己的花店网站，花了一个周末，在手机上看起来还不错，她为此感到自豪。后来她想添加一个简单的事件日历。只是一个日历。GoDaddy做不了。除非用一个丑陋到足以让初级开发者感到尴尬的变通方案。最后她支付我的费用把整个网站迁移到WordPress，我记得当时在想：为什么人们一开始要用这个呢？
关键要点:GoDaddy建站器比竞争对手更激进地用简便换取灵活性;WordPress、Webflow和Squarespace都在相似成本下提供更大的发展空间。
我能理解，说实话。GoDaddy 的宣传很诱人。注册、选择模板、输入业务名称、午餐前上线。对于从未接触过 CMS 的人来说，这种速度感觉像超能力。但这是暂借的时间。而在 Seahawk 建立了 12,000 多个网站后，我已经数不清为那些增长速度超出预期的客户进行过多少次 GoDaddy 迁移。
那么让我告诉你我实际上把客户（和我自己）转向了什么，以及为什么。
---
GoDaddy建站工具的问题不是速度，而是天花板
GoDaddy 的网站构建器启动速度确实很快。我不会装作不知道。他们的 AI 层 GoDaddy Airo 可以在你喝完咖啡之前，用徽标和电子邮件活动模板搭建一个品牌化网站。编辑器简洁、直观，对不知道 div 是什么也不想学的人来说没有威胁感。
但是。
你无法自由移动区块。你无法编辑HTML或CSS。你无法改变预设选项以外的布局。你当然也无法安装一个在他们封闭生态系统中不存在的插件。正如一份详尽的建站工具评测直言不讳地指出的那样，初始设置的便利性是真实存在的，但一旦你想要超越基础设计功能的任何东西，你就会碰到一堵墙。
那堵墙才是问题所在。不是构建器本身。
我有一个客户，一家位于布里斯托尔的物理治疗诊所，已经在GoDaddy上运营了三年。网站看起来不错。后来他们想要在线预约功能、带有表单的患者信息采集、与他们的诊所管理软件的集成，以及供患者观看锻炼视频库的会员区域。我们花了两个小时审查GoDaddy本身能支持什么。答案基本上是这个列表上的任何东西都不行。三年的内容积累，他们必须从架构上重新开始。
这不是关于 GoDaddy 的警示故事。这是关于根据你能多快开始而不是能走多远来选择平台的警示故事。
---
WordPress：对大多数人来说仍然是明智的默认选择
过去十年左右，人们一直在宣布WordPress已死。它仍然为整个互联网的约40%提供支持。这不是惯性，这是一种规模化的网络效应，没有任何东西成功地撼动过它。
我仍然推荐它的原因
插件生态本身就值得一用（说句公道话，它是免费的）。60,000+ 个插件意味着你能想到的几乎任何功能都已经有人构建过了，在数千个网站上经过生产环境测试，并在 YouTube 上被讲烂了。电商用 WooCommerce。自定义字段用 ACF。SEO 用 Yoast 或 Rank Math。这个技术栈很无聊，这真的是在夸奖。
对于代理公司来说，人才库也很重要。我可以在伦敦、拉各斯或卢布尔雅那招聘一个 WordPress 开发者，并且相当有把握他们知道什么是自定义文章类型。试试用专有建站工具做到这一点。
WordPress 的注意事项 我要坦诚说明
它不是完美的。插件冲突确实存在。保持 40 个插件更新而不破坏东西，正如一个 Hacker News 评论者所说的那样，就像"照看 MySQL"。当你运行一个维护不周的旧版插件时，安全是真正的顾虑。而区块编辑器（Gutenberg）仍然以一种几乎神学般的方式引发争议。
但对于一个需要真正灵活性、内容所有权，以及一个能与他们一起成长的网站的客户来说？除非简报特别指向其他方案，否则 WordPress 仍然是我的首选推荐。
---
无头 WordPress 和 Jamstack：当简报指向其他方案时
大约三年前，Seahawk开始接到更多把"性能"作为硬性要求而非仅仅是加分项的项目简报。快速加载时间。高Core Web Vitals分数。内容跨多个平台交付，网页、应用，也许还有零售环境中的展示屏。传统的WordPress托管无法满足。
那时我们开始更深入地采用无头架构。
无头架构实际上意味着什么（不用术语讲解）
Headless WordPress意味着你将WordPress保留为后端、内容仓库和客户登录的管理界面，但完全解耦前端。"头部"（用户看到的部分）用Next.js或Astro这样的JavaScript框架构建。WordPress通过其REST API或GraphQL提供内容。前端获取该数据并按其需要呈现。
结果是：页面加载速度极快，没有 PHP 渲染瓶颈，对前端架构有完全的自由度。安全性也提高了，因为 WordPress 管理界面不再以同样的方式公开暴露。
Jamstack CMS 生态
如果你走完整的 Jamstack，你甚至不需要使用 WordPress 作为后端。有一个坚实且不断增长的 headless CMS 选项领域，专门为这种架构构建。我在生产中使用过的一些：
- Contentful，成熟、文档详尽、在规模上成本略高但非常可靠
- Sanity，极其灵活的内容建模、出色的开发体验、适合编辑团队的实时协作
- Storyblok 的可视化编辑器对于想要实时查看更改的非技术客户来说确实印象深刻
- Strapi 是开源的、可自托管的、基于 Node.js 的，如果你想降低基础设施成本，这是个不错的选择
- Directus 被低估了，特别是对于需要适当数据库抽象层的数据密集型项目
这些都不是完美适用于每个项目的。Storyblok 的可视化编辑器对编辑来说很棒，但确实在开发者端增加了复杂性。Sanity 的 GROQ 查询语言有学习曲线。根据实际项目选择，而不是跟风。
---
EmDash：值得关注的新秀（需要留意的问题）
2026 年 4 月发布了一些有趣的东西。EmDash 是由 Cloudflare 支持的全新 CMS，将自己定位为 WordPress 的精神继承者，采用现代网络技术构建，通过 Cloudflare Workers 实现插件隔离，内容存储为结构化数据，原生可读性适配 AI 工具。
这个主张确实有意思。WordPress 运行在 PHP 上，虽然管用，但如果从 2026 年的角度从零开始设计，绝不会选择 PHP。EmDash 为边缘计算原生部署、结构化内容，以及人工智能助手日益成为信息获取主要方式的世界而构建。
我还没在生产环境中部署过 EmDash。它以测试版身份推出，我在关注它。有些真正值得注意的疑虑：
- 生态系统完全崭新。WordPress 有 60,000 个插件，而这边...还没有。暂时没有。
- 插件隔离功能仅在 Cloudflare 的运行时上工作，如果你致力于该基础设施这没问题，否则就有局限性。
- 这是一个测试版产品。固有的风险。我不会把测试版放在需要稳定性的客户面前。
测试过它的人们的诚实共识是：技术上令人印象深刻，实际上不完整。值得在 12-18 个月后重新查看。我会这样做。
---
如何实际选择这些选项
问题在于，网上大多数"哪个 CMS 最好"的内容都把这当作规格单对比。勾选框。功能矩阵。这不是你为真实项目选择平台的方式。
这是我实际的做法：
- 问客户18个月后会需要什么，而不是今天需要什么。如果他们是独立花店，托管主机上的WordPress可能就够了。如果他们是一家预计流量增长10倍的风投支持的创业公司，现在就要为此设计架构。
- 问上线后由谁来维护。无头Jamstack设置再棒，直到客户那位58岁的营销经理需要更新博文为止。然后它就会变成一个等着处理的支持工单。要让技术复杂度与团队能力相匹配。
- 问内容是否会发送到多个地方。多个前端（网页+应用+其他任何东西）几乎总是指向无头架构。
- 询问集成情况。CRM、预订系统、支付处理器、分析工具，在你提交到某个平台之前就要这些映射好，而不是之后。
- 询问持续维护的预算。自托管的 Strapi 实例需要有人保持 Node.js 版本更新。这需要花费时间或金钱。把这个因素考虑进去。
---
没人谈论的迁移现实
从 GoDaddy（或任何专有构建器）迁出并不简单。内容通常可以以某种形式导出，但结构往往不能。GoDaddy 不提供干净的数据库导出或内容 API。你通常需要进行抓取、复制粘贴，或使用完成大约 70% 工作的第三方迁移工具，然后手动清理其余部分。
我迁移过足够多的项目，已经有了一套流程，但我不会假装它很优雅。要为此预留真实的时间。绝对要确保你从 GoDaddy 的域名转出处理得当，他们有过度增加该流程摩擦的历史。
好消息是：一旦你迁移出去，就彻底出去了。转向 WordPress 或无头 CMS 的客户几乎从不回头。
---
常见问题
GoDaddy 的网站建设器有什么用处吗？
老实说，对于非常特定的用例，是的。一个为本地工匠设计的单页网站，只需要在线存在和电话号码。一个临时登陆页面。一个非技术人员需要在几小时内上线且永远不需要进行重大更改的东西。对于这些情况，快速设置是真正的优势。对于有增长野心的任何东西，它很快就会到达上限。
要转向 WordPress，我需要知道如何编写代码吗？
不一定。来自 Kinsta、WP Engine 甚至 Hostinger 这样的提供商的托管 WordPress 主机让运维方面更容易上手。你仍然需要对管理界面有一定的了解，理想情况下还要有人在出问题时可以求助。但很多小企业主不需要写一行代码就能运营 WordPress 网站。
无头 CMS 和常规 CMS 有什么区别？
传统 CMS（如经典 WordPress）既处理内容存储又处理页面渲染，是个耦合系统。无头 CMS 仅处理内容存储并通过 API 暴露它。你的前端由你喜欢的任何框架构建，获取该内容并决定如何显示它。好处是灵活性和性能。坏处是你需要前端开发者，而不仅仅是网站构建器。
EmDash是否可以投入生产使用？
在我看来，对大多数企业都不行。它在2026年4月以测试版推出，生态系统确实处于初期阶段。底层架构很有趣，Cloudflare的支持给了它可信度。但当WordPress和经过验证的无头替代品存在时，我不会把客户的主要营销网站放在测试版CMS上。留意2027年的动向。
我能将WordPress用作无头CMS吗？
可以，这实际上是一个真正实用的中间地带。WordPress有一个内置的REST API，WPGraphQL是一个成熟的插件，通过GraphQL暴露你的内容。所以你获得了你的客户已经熟悉的管理界面、庞大的插件生态系统，但你用Next.js或Astro构建前端，获得现代Jamstack设置的性能优势。我们在Seahawk已经用这种方式交付了几个项目，效果很好。
---
2017年那位花店老板至今仍是我的客户。她现在用WordPress了，配了一个靠谱的预订插件和真正能用的活动日历。从那以后她再没有慌张地打过电话来。说到底，目标就是这样——搭建一套东西让它不再成为问题，这样人们才能专心做自己真正的工作。
选择无聊的东西。选择灵活的东西。选择你可以移交出去的东西。