无头 CMS

无头 CMS 是一类只负责存内容、不负责显示内容的管理系统，内容通过接口交给前台程序，前台长什么样由开发者决定^[1]。它适合要把同一批内容投到网站、应用和小程序的团队。选它的好处是前台自由、内容可复用；代价是前台要自己建，网址、缓存和渲染都得自己接上，做 SEO 的人因此多了一层要维护的东西。

架构与组成

无头 CMS 把内容管理和内容呈现拆开。后台负责存内容、管理权限和版本，前台负责把内容渲染成页面。两边通过接口通信，取回来的通常是 JSON 数据^[1]。

组成上少不了三样：内容模型、接口和交付方式。内容模型定义有哪些字段，接口提供读写入口，交付方式决定前台怎么取数据。

内容模型与接口

内容模型是无头 CMS 里最花心思的一步。官方说明，内容模型用来定义和组织站点用到的各种内容类型，把作者、标题、正文、图片说明拆成独立字段，之后才好复用^[1]。

接口分两类：读取内容用交付接口，管理内容用管理接口。前台通常只调前者，构建脚本和自动化流程会用到后者。

结构化内容是复用能成立的前提。内容没有拆成字段、没有统一的分类信息，换一个前台就还得重新整理一遍^[1]。

前台与网址的归属

无头架构里，网址由前台决定，不由 CMS 决定。前台是自建站点，路由怎么排、哪些参数进索引，都写在代码里；前台是静态生成器，网址就在构建时生成。

这一点和传统 CMS 的差别很大。传统系统里改网址在后台点几下就行，无头架构里要改代码并重新部署，改动前得先确认旧地址的 301 由谁来接。

与抓取和收录的关系

无头架构把 SEO 的责任从系统推给了前台，凡是传统系统自动做的事，现在都要自己补：

• 站点地图：要自己在构建流程里生成，再提交给搜索引擎。Google 说明，站点地图用来告诉引擎站内哪些网页比较重要^[2]。
• 规范化：重复地址要依靠 rel="canonical" 或重定向声明主版本。Google 把重定向和 rel="canonical" 都算作强信号，站点地图里的地址算弱信号^[3]。
• 渲染：前台只依靠浏览器执行脚本时，爬虫可能读不到内容，要在服务端或构建阶段先把 HTML 生成出来。
• 结构化数据：要自己在模板里输出，系统不会代劳。

缓存也要自己设计。接口调用有响应时间，前台每次请求都去取数据，页面会变慢；常见的做法是在构建时取好，或者在中间加一层缓存。百度把搜索对网页的处理概括为抓取、建立索引和展现三步^[4]，前台慢了，第一步就走不顺。

适用场景与代价

内容要投到多个渠道时，无头架构的优势明显：同一批内容，网站、应用和小程序各取所需，改一次内容就能全线更新^[5]。

代价落在开发和运维上。前台要自己建、自己部署；内容和呈现分开之后，一个页面的问题可能出在两头，排查要多绕几步。

托管方式也分两种。云服务按内容和请求量计费，省掉服务器维护；自建要自己管数据库和接口服务，成本从订阅费换成了人力。

常见误用

一个误用是把无头架构当默认选择。内容只投一个网站、团队里又没有前端开发，无头架构会平白多出一套要维护的前台。

另一个误用是内容模型先随便定，之后再改。字段一改，调用它的前台代码和构建脚本都要跟着改，改动量比在传统 CMS 里大得多。

还有一个误用是忘了补站点地图和重定向。系统不生成这两样，漏掉之后新页面只能等爬虫自己发现，旧地址则直接断掉。

附录

参见

• 静态站点生成器
• Drupal
• Shopify

参考资料

官方（境外）

1. 《Headless CMS》，Contentful，2024-05-02 更新。
2. 《了解站点地图》，Google 搜索中心，2025-12-18 更新。
3. 《如何使用 rel="canonical" 及其他方法指定规范网址》，Google 搜索中心。

官方（国内）

4. 《百度搜索的工作原理》，百度搜索资源平台，2023-12-21 更新。

第三方

5. 《Headless CMS vs. traditional CMS: Which architecture wins in a composable DXP world?》，Contentful，2026-01-20 更新。

外部链接

无。