早在 2017 年，一位客户慌张地给我打来电话。她在 GoDaddy 的网站构建器上建了她的花店网站——花了她一个周末，在手机上看起来相当不错，她对此很自豪。后来她想添加一个简单的活动日历。就是一个日历。GoDaddy 做不了。没有某种丑陋的变通方案它做不了，那种方案会让初级开发者感到尴尬。她最后花钱让我把整个网站迁移到了 WordPress，我记得当时在想：为什么有人要从这里开始呢？why do people start here at all?
我理解，真的。GoDaddy 的宣传很有吸引力。注册，选择模板，输入你的公司名称，在午餐前上线。对于从未接触过 CMS 的人来说，这种速度感就像超能力一样。但这是透支的时间。在 Seahawk 构建了 5000 多个网站后，我现在已经数不清为多少客户做过 GoDaddy 迁移了——那些客户增长得比预期快得多，很快就超出了 GoDaddy 的能力。Seahawk, I've now lost count of how many GoDaddy migrations I've done for clients who grew out of it faster than they expected.
那么让我告诉你我实际上把客户（和我自己）转向了什么，以及为什么。
---
GoDaddy 构建器的问题不是速度——是天花板
GoDaddy 的网站构建器确实快速易上手。我不会假装否认这一点。GoDaddy Airo 是他们的 AI 层，可以在你喝完咖啡之前就用徽标和电子邮件活动模板为你搭建一个品牌网站。编辑器简洁直观，对不知道什么是 div 也不想学的人来说没有威胁。The editor is clean, intuitive, and non-threateningfor people who don't know what adivis and don't want to learn.
但是。
你无法自由移动版块。你无法编辑 HTML 或 CSS。除了预设的选项，你无法改变布局。你绝对无法安装一个在他们封闭生态系统中不存在的插件。正如一篇详尽的构建器评测直言不讳地说的那样——设置的便利性是真实的，但一旦你想要超越基本设计之外的东西，你就会撞到一堵墙。one thorough review of the builderputs it bluntly — the convenience of setup is real, but the moment you want anything beyond the basics of design, you hit a wall.
那堵墙才是问题所在。不是构建器本身。
我有个客户——布里斯托的一家物理治疗诊所——已经在 GoDaddy 上三年了。网站看起来不错。然后他们想要在线预约和接待表格、与他们的诊所管理软件集成，以及为锻炼视频库提供的会员区。我们花了两个小时审核 GoDaddy 原生支持什么。答案基本上是这个列表上没有任何东西。三年的内容，他们不得不从架构上重新开始。
这不是关于 GoDaddy 具体的警示故事。这是关于基于你能多快开始而不是能有多远走的选择平台的警示故事。startrather than how far you cango.
---
WordPress：对大多数人来说仍然是明智的默认选择
过去十多年来，人们一直在宣布 WordPress 已死。它仍然为整个网络的大约 40% 提供支持。这不是惯性——这是一种没有任何东西设法撼动的规模的网络效应。around 40% of the entire web. That's not inertia — that's network effect at a scale that nothing has managed to dislodge.
我仍然推荐它的原因
插件生态本身就值得一用（说句公道话，它是免费的）。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 保留为后端——内容存储库、客户端登录的管理界面——但完全解耦前端。"Head"（用户看到的内容）用 Next.js 或 Astro 这样的 JavaScript 框架构建。WordPress 通过其 REST API 或 GraphQL 提供内容。前端获取该数据并按需渲染。means you keep WordPress as the backend — the content repository, the admin interface your client logs into — but you decouple the frontend entirely. The "head" (what users see) is built in a JavaScript framework like Next.js or Astro. WordPress serves content via its REST API or GraphQL. The frontend fetches that data and renders it however it likes.
结果是：页面加载速度极快，没有 PHP 渲染瓶颈，对前端架构有完全的自由度。安全性也提高了，因为 WordPress 管理界面不再以同样的方式公开暴露。
Jamstack CMS 生态
如果你全力采用 Jamstack，你甚至不需要用 WordPress 作为后端。有一个坚实且不断增长的 headless CMS 选项领域，专为这种架构而构建。我在生产中使用过的几个：headless CMS options built specifically for this architecture. A few I've used in production:
- Contentful——成熟、文档齐全、规模化成本略高但非常稳定— mature, well-documented, slightly expensive at scale but rock-solid
- Sanity——内容建模极其灵活、开发体验很好、编辑团队可实时协作— extremely flexible content modelling, great DX, real-time collaboration for editorial teams
- Storyblok——可视化编辑器对想要实时看到变化的非技术客户端来说真的令人印象深刻— the visual editor is genuinely impressive for non-technical clients who want to see changes in real-time
- Strapi——开源、可自托管、基于 Node.js、如果你想降低基础设施成本这很不错— open-source, self-hostable, Node.js-based, good if you want to keep infrastructure costs down
- Directus——被低估了，特别是对于需要适当数据库抽象层的数据量大的项目— underrated, especially for data-heavy projects that need a proper database abstraction layer
这些都不是完美适用于每个项目的。Storyblok 的可视化编辑器对编辑来说很棒，但确实在开发者端增加了复杂性。Sanity 的 GROQ 查询语言有学习曲线。根据实际项目选择，而不是跟风。
---
EmDash：值得关注的新秀（需要留意的问题）
有趣的东西在 2026 年 4 月出现了。EmDash 是由 Cloudflare 支持的新 CMS，定位为 WordPress 的精神继承者——基于现代网络技术构建，通过 Cloudflare Workers 实现插件隔离，内容以结构化数据形式存储，原生可被 AI 工具读取。EmDashis a new CMS backed by Cloudflare, positioning itself as a spiritual successor to WordPress — built on modern web technologies, with plugin isolation via Cloudflare Workers, and content stored as structured data that's natively readable by AI tools.
这个主张确实有意思。WordPress 运行在 PHP 上，虽然管用，但如果从 2026 年的角度从零开始设计，绝不会选择 PHP。EmDash 为边缘计算原生部署、结构化内容，以及人工智能助手日益成为信息获取主要方式的世界而构建。
我还没在生产环境中部署过 EmDash。它以测试版身份推出，我在关注它。有些真正值得注意的疑虑：
- 生态系统完全崭新。WordPress 有 60,000 个插件，而这边...还没有。暂时没有。
- 插件隔离功能只在 Cloudflare 的运行时环境中有效——如果你坚持用那套基础设施，这没问题；如果你不想被绑定，就有限制。
- 这是一个测试版产品。固有的风险。我不会把测试版放在需要稳定性的客户面前。
测试过的人的老实共识是：技术上印象深刻，实际上还不完整。值得在 12-18 个月后重新评估。我会按这个计划做。honest consensusfrom people who've tested it is: technically impressive, practically incomplete. Worth revisiting in 12-18 months. I'll be doing exactly that.
---
如何实际选择这些选项
问题在于——网上大多数"哪个CMS最好"的内容都把这当作规格表对比。打勾。功能矩阵。这不是你为真实项目选择平台的方式。
这是我实际的做法：
- 问客户18个月后会需要什么，而不是今天。如果他们是个体花艺师，WordPress加托管主机可能就够了。如果他们是风投支持的初创企业，预期流量增长10倍，现在就要为此架构。If they're a solo florist, WordPress on managed hosting is probably fine. If they're a VC-backed startup expecting 10x traffic growth, architect for that now.
- 问发布后谁来维护它。无头Jamstack架构很棒，直到客户那位58岁的营销经理得自己更新博客文章。然后就成了待处理的支持工单。技术复杂度要匹配团队水平。A headless Jamstack setup is brilliant until the client's 58-year-old marketing manager has to update a blog post. Then it's a support ticket waiting to happen. Match the technical complexity to the team.
- 问内容是否要发布到多个地方。多个前端（网页+应用+其他），几乎总是指向无头架构。Multiple frontends (web + app + whatever) almost always points toward headless.
- 问关于集成。CRM、预订系统、支付处理器、分析工具——在承诺某个平台之前映射这些，而不是之后。CRM, booking systems, payment processors, analytics — map these before you commit to a platform, not after.
- 问持续维护的预算。自托管的Strapi实例需要人手保持Node.js版本更新。这要花时间或金钱。把它计算进去。A self-hosted Strapi instance needs someone keeping the Node.js version updated. That costs time or money. Factor it in.
---
没人谈论的迁移现实
从 GoDaddy（或任何专有建站工具）迁移出来并不简单。内容通常可以以某种形式导出，但结构往往无法导出。GoDaddy 不提供干净的数据库导出或内容 API。你通常需要自己抓取、复制粘贴，或使用第三方迁移工具，这些工具通常只能完成 70% 的工作，剩余部分需要你手动清理。structureoften isn't. GoDaddy doesn't give you clean database exports or content APIs. You're typically scraping, copy-pasting, or using third-party migration tools that do about 70% of the job and leave you cleaning up the rest manually.
我已经迁移过足够多的这类项目，有了自己的流程，但我不会假装这个流程很优雅。要为此预留真正的时间。并且绝对要仔细检查域名从 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，配合一个合适的预订插件和一个真正有效的活动日历。从那以后她再没为任何问题给我打过惊慌失措的电话。这才是真正的目标——构建一些东西，让它不再成为问题，这样人们就可以继续做他们的实际工作。
选择无聊的东西。选择灵活的东西。选择你可以移交出去的东西。