2017年,一位客户打电话来找我帮忙。她在GoDaddy网站建设器上建立了花店的网站——花了一个周末,在移动设备上看起来还不错,她为此感到骄傲。然后她想添加一个简单的活动日历。仅仅是一个日历。GoDaddy做不到。除非采用某种丑陋的解决方案,连初级开发者都会感到尴尬。最后她付费让我把整个网站迁移到WordPress,我当时就在想:为什么人们一开始就要用这个?WordPress, and I remember thinking:why do people start here at all?
关键要点:GoDaddy建站器比竞争对手更激进地用简便换取灵活性;WordPress、Webflow和Squarespace都在相似成本下提供更大的发展空间。GoDaddy's builder trades flexibility for simplicity harder than its rivals; WordPress, Webflow, and Squarespace all offer more headroom at comparable cost.
我能理解，说实话。GoDaddy 的宣传很诱人。注册、选择模板、输入业务名称、午餐前上线。对于从未接触过 CMS 的人来说，这种速度感觉像超能力。但这是暂借的时间。而在 Seahawk 建立了 12,000 多个网站后，我已经数不清为那些增长速度超出预期的客户进行过多少次 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 的网站构建器启动速度确实很快。我不会装作不知道。他们的 AI 层 GoDaddy Airo 可以在你喝完咖啡之前，用徽标和电子邮件活动模板搭建一个品牌化网站。编辑器简洁、直观，对不知道 div 是什么也不想学的人来说没有威胁感。The editor is clean, intuitive, and non-threatening for people who don't know what a div is and don't want to learn.
但是。
你无法自由移动分块。你无法编辑HTML或CSS。你无法改变预设选项之外的布局。你当然也无法安装他们封闭生态中不存在的插件。正如一份详尽的建站器评测直言不讳地指出的——初始设置的便利是真实的,但一旦你想要超越设计基础知识,就会碰壁。one thorough review of the builder puts 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 的警示故事。这是关于根据你能多快开始而不是能走多远来选择平台的警示故事。start rather than how far you can go.
---
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托管无法满足需求。Core Web Vitals scores. Content served across multiple surfaces -- web, app, maybe a kiosk screen in a retail environment. Traditional WordPress hosting wasn't going to cut it.
那时我们开始更深入地采用无头架构。
无头架构实际上意味着什么（不用术语讲解）
Headless WordPress意味着你保留WordPress作为后端——内容存储库、你的客户登录的管理界面——但完全解耦前端。"头"(用户看到的内容)用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 工具读取。EmDash is 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 consensus from 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% 工作的第三方迁移工具，然后手动清理其余部分。structure often 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，配备了一个合适的预订插件和一个真正能用的活动日历。从那以后她再也没有慌张地给我打过电话。这就是目标，真的——构建一些不再是问题的东西，这样人们就能继续做他们真正的工作。
选择无聊的东西。选择灵活的东西。选择你可以移交出去的东西。