Headless CMS 是一種內容管理系統，用來儲存頁面、文章、產品資料和圖片等內容，但不決定內容的外觀。網站、App 和其他渠道透過 API 取得內容，再按各自的設計顯示。「head」指訪客看到的前端；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 內，也可以透過系統整合送到其他系統。
多語言內容
以英文、繁體中文和簡體中文發佈內容的企業，可以把每種語言儲存為同一項內容的不同版本，各有標題、內文、網址 slug 和 SEO 欄位。選擇時應了解：缺少翻譯時如何處理、替代文字能否按語言設定，以及編輯人員能否看到哪些語言仍未完成。
好處
- 設計較自由。前端不受佈景主題範本限制。
- 多個渠道共用一個內容來源。網站和 App 可以使用同一批內容，更新一次即可。
- 效能上有更多選擇。預先生成並快取的頁面有助提升速度，但實際效果視乎前端的建構方式。
- 前後分開。公開網站不會直接暴露編輯系統，日後亦可只重建其中一方。
缺點
- 需要開發人員。前端要有人建立和維護；新增頁面類型通常要經開發。
- 預覽和編輯較麻煩。編輯人員在表格中填寫，而非直接在頁面上修改；要看草稿的實際效果，須在 CMS 與前端之間設定預覽。
- 建置成本較高。內容模型、前端、預覽和部署都需要規劃和建立。
- 涉及的部分較多。CMS、前端和寄存服務可能來自不同供應商，各有自己的方案和限制。
中小企何時適合，何時不適合
如果內容要在多於一個渠道出現、網站需要佈景主題做不到的設計、多種語言要保持同步，或網站本身是較大型 Web App 的一部分，Headless CMS 通常較合適。前提是有持續的開發支援。
如果只是一年更新幾次的簡單公司網站、推出後沒有開發人員跟進，或編輯人員希望自行拖放調整版面，Headless CMS 未必值得。維護得當的傳統 CMS 或網上建站平台可能更簡單。另可參閱整網頁前必須知道的 5 個概念。
以下為說明用例子：一間培訓中心在網站和會員 App 上顯示課程資料。職員只需在 Headless CMS 修改一次課程日期，兩邊便會同步顯示。
選擇 Headless CMS 前的檢查清單
- 現在和未來幾年，哪些渠道會使用這些內容？
- 有哪些內容類型，每種需要甚麼欄位？
- 需要多少種語言？每種語言由誰審批？
- 編輯人員是否需要視覺預覽？修改會如何在 Staging 環境測試？
- 推出後由誰維護前端？
- CMS 方案的限制涵蓋甚麼（用戶數目、API 請求、儲存空間）？日後能否匯出內容？
- 是否需要連接預約、付款或 CRM 系統？
- 前端應該是網站、Web App 還是手機 App？可參閱Web App 與手機 App 的比較。
可參閱我們的網站及 Web App 開發服務，或手機 App、Web App 及微信小程序開發頁面。
常見問題
Headless CMS 是否比 WordPress 好？
不能一概而論。簡單網站由編輯人員自行管理，傳統做法通常較快；Headless 做法對設計和渠道有更大控制權，但需要開發支援。
WordPress 可以用作 Headless CMS 嗎？
可以。WordPress 內置 REST API，獨立的前端可以透過它取得內容，但會失去部分佈景主題功能，前端亦要自行建立。
Headless 網站對 SEO 有利嗎？
視乎前端。搜尋引擎看的是它收到的頁面，所以前端必須輸出正確的標題、描述和語言標記，並讓頁面快速載入。
現有網站可以轉用 Headless CMS 嗎？
通常可以，但要當作一個項目處理：內容要對應到新欄位，網址要保留或設定轉址，前端亦要重建。