Headless CMS（无头 CMS）是一种内容管理系统，用来存储页面、文章、产品信息和图片等内容，但不决定内容如何展示。网站、App 和其他渠道通过 API 获取内容，再按各自的设计显示。“头”指访客看到的前端；Headless CMS 把前端和编辑人员使用的后台分开。
传统 CMS 与 Headless CMS
- 传统（耦合式）CMS：内容编辑、页面模板和对外网站都在同一个系统里。典型的 WordPress 类网站就是这样：编辑撰写页面，主题决定版式，再由 CMS 生成页面。
- Headless CMS：CMS 只管理内容，并通过 API 提供内容。独立的前端，例如网站、手机 App 或自助终端屏幕，向 CMS 请求内容，并自行负责布局和设计。
- 混合方式：一些传统 CMS 也提供 API，一些 Headless 产品则加入了预览或页面搭建功能，比较时应看实际功能。
内容如何从 CMS 到达屏幕
编辑人员用结构化字段创建内容，比如一个产品条目包括名称、简介、价格、图片和分类，而不是写成一整页。前端向 CMS 的 API 请求所需条目，再把各字段放进自己的设计。很多网站会预先生成页面，在内容变更时重新生成（通常由 CMS 发出的 Webhook 触发），并通过 CDN 提供给访客。
内容不绑定版面，同一条内容可以用在网站、手机 App 或 PWA 中，也可以通过系统集成传到其他系统。
多语言内容
同时用英文、繁体中文和简体中文发布内容的企业，可以把每种语言存为同一条内容的不同版本，各自有标题、正文、URL slug 和 SEO 字段。选型时要确认：缺少翻译时怎么处理，替代文本能否按语言设置，编辑人员能否看到哪些语言还没完成。
优点
- 设计更灵活。前端不受主题模板限制。
- 多个渠道共用一个内容源。网站和 App 可以使用同一批内容，只需更新一次。
- 性能方面选择更多。预先生成并缓存的页面有助于提升速度，但实际效果取决于前端如何开发。
- 前后端分离。对外网站不直接暴露编辑系统，以后也可以只重做其中一端。
缺点
- 需要开发人员。前端需要有人开发和维护；增加新的页面类型通常要做开发。
- 预览和编辑更复杂。编辑人员在表单中填写，而不是直接在页面上修改；要看草稿的实际效果，需要在 CMS 和前端之间配置预览。
- 开发成本较高。内容模型、前端、预览和部署都需要规划和开发。
- 环节更多。CMS、前端和托管服务可能来自不同供应商，各有自己的套餐和限制。
中小企业什么时候适合，什么时候不适合
如果内容需要在多个渠道展示，网站需要主题模板做不到的设计，多种语言需要保持同步，或者网站本身是较大 Web 应用的一部分，Headless CMS 通常更合适。前提是有持续的开发支持。
如果只是一年更新几次的简单企业网站，上线后没有开发人员跟进，或者编辑人员希望自己拖拽调整版面，Headless CMS 未必值得。维护良好的传统 CMS 或在线建站平台可能更简单。也可以参阅建网站前需要确认的 5 件事。
以下为说明用例子：一家培训机构在网站和会员 App 上展示课程信息。员工只需在 Headless CMS 修改一次课程日期，两边就会同步显示。
选择 Headless CMS 前的检查清单
- 现在和未来几年，哪些渠道会使用这些内容？
- 有哪些内容类型，每种需要哪些字段？
- 需要支持几种语言？每种语言由谁审核？
- 编辑人员是否需要可视化预览？修改如何在预发布环境（Staging）中测试？
- 上线后由谁维护前端？
- CMS 套餐的限制包括什么（用户数、API 请求、存储空间）？以后能否导出内容？
- 是否需要对接预约、支付或 CRM 系统？
- 前端应该是网站、Web 应用还是手机 App？可以参阅Web App 与手机 App 的比较。
可以参阅我们的网站与 Web 应用开发服务，或手机 App、Web App 及微信小程序开发页面。
常见问题
Headless CMS 比 WordPress 更好吗？
不能一概而论。简单网站由编辑人员自己管理，传统方式通常更快；Headless 方式对设计和渠道的控制更多，但需要开发支持。
WordPress 能当作 Headless CMS 使用吗？
可以。WordPress 自带 REST API，独立前端可以通过它获取内容，但会失去部分主题功能，前端也需要自己开发。
Headless 网站对 SEO 有利吗？
取决于前端。搜索引擎看的是它收到的页面，前端需要输出正确的标题、描述和语言标记，并保证加载速度。
现有网站可以迁移到 Headless CMS 吗？
通常可以，但要作为一个项目来做：内容要映射到新字段，原有网址要保留或设置跳转，前端也要重新开发。