直接答案：Headless CMS 把「管內容」和「決定網頁長怎樣」拆開：編輯在內容系統改稿，網站／App 等前端透過 API 取資料再呈現。好處是多渠道重用內容、前端技術可獨立升級；代價是架構更複雜，預覽、權限、快取與故障排查都要設計。對多數香港中小企單一官網，傳統一體 CMS（例如 WordPress）通常更務實；Headless 是有明確多渠道或產品化需求時的工具，不是預設榮耀徽章。
相關概念可併讀甚麼是 CMS、Jamstack、靜態網站 vs 動態 CMS，以及前端React／Astro／Next.js。
Headless 是甚麼（比喻）
傳統 CMS 像「印刷廠＋排版部」綁在一起：改稿與出報紙同一系統。Headless 像「中央稿庫」：稿件存好，報紙、App、電子看板各自排版取用。
- 內容層：CMS／內容 API
- 呈現層：網站前端、App、落地頁
- 連接方式：HTTP API、有時加上建置時拉取
為甚麼有人採用
- 同一內容服務官網、App、夥伴網站
- 前端要用地板級自訂互動（React／Vue 等）
- 希望內容團隊與前端團隊可較獨立發版
- 部分性能策略（CDN、預渲染）較好落地
代價與常見坑
- 編輯預覽不好做，容易「後台看到與前台不一」
- 出問題時難判斷是 CMS、API 還是前端
- 工程與託管帳單可能高於一體 CMS
- SEO 若渲染不當，會出現空白或延遲內容風險
與傳統 CMS 的分別
- 傳統：改稿、主題、預覽路徑短，香港供應商熟
- Headless：彈性高，責任鏈長，需要明確的擁有者
- 混合：部分 CMS（WordPress、Drupal、Umbraco）可傳統也可 API 化
何時適合／不適合
較適合
- 多渠道內容策略已真實存在（不只是想像）
- 有前端＋內容雙邊維護能力
- 產品化體驗無法用主題誠實完成
通常不必
- 單一品牌官網、改稿要簡單
- 團隊人數少、沒有工程值班
- 核心問題其實是文案與轉換，不是架構名詞
找供應商要問甚麼
- 編輯預覽與草稿流程如何驗收？
- API 限額、快取、故障備援？
- 前端與 CMS 分開報價與維護嗎？
- SEO／社交預覽誰負責？
- 若要退回傳統主題，遷移成本？
下一步
先確認你是否真的有「多頭部」需求。沒有的話，把傳統 CMS 用好通常投資報酬更高。現站診斷見免費網站診斷。
