Headless CMS 是只負責管理內容、不負責輸出頁面的內容管理系統：編輯者照樣在後台撰寫文章、上傳圖片，但系統不套用佈景主題產生網頁，而是透過 API 把內容交給另外開發的網站、App 或其他介面呈現。好處是同一份內容可以供多個前台使用，前台技術也能依需求選擇；代價是前台要另外開發與維護，預覽、網址、標題與結構化資料這些在傳統 CMS 由系統或外掛處理的功能，要由開發團隊自己補上。內容只用在一個官網、行銷人員需要自行調整版面時，傳統 CMS 的維護負擔比較輕。
Headless 的意思：把內容和呈現層拆開
「Head」指的是負責呈現的前台，也就是訪客看到的網頁版面。傳統 CMS 把後台和前台綁在一起，文章存好，佈景主題就把它套進版型輸出成網頁；Headless 則拿掉這一層，系統只保存結構化的內容，例如標題、摘要、內文、圖片、作者、分類，再由其他程式取用。
因為內容不綁定版型，同一篇產品介紹可以同時出現在官網、App 與門市的螢幕上，各自用適合的方式排版。這也代表內容要先規劃成欄位，而不是一整塊排好版的文字，否則換到其他前台時，格式就很難重新運用。CMS 本身的功能與類型，可以先看CMS 是什麼。
運作方式：內容庫、API 與前台分開部署
- 編輯者在後台建立內容：依事先定義好的內容欄位填寫並發布。
- 內容透過 API 提供：前台以 HTTP 請求取得 JSON 格式的資料。
- 前台組成頁面：網站可以在伺服器端產生頁面、在建置時預先產生，或在瀏覽器端組合；App 則直接取用資料顯示。
- 各自部署：後台與前台可以放在不同主機，分開更新。
以 WordPress 為例，官方文件說明 REST API 讓應用程式以 JSON 格式與網站收送資料，可以用來打造全新的前台，或把 WordPress 的內容帶進完全獨立的應用程式，區塊編輯器本身也建立在它之上。網站上公開的內容一般可以透過 REST API 公開讀取；私人內容、受密碼保護的內容、內部使用者、自訂文章類型與中繼資料，要經過驗證或特別設定才能取得。驗證方式方面，Cookie 驗證只適用於在 WordPress 裡已登入的使用者，外部應用程式可以在 HTTPS 請求中使用應用程式密碼，或透過外掛支援其他方式。
Headless CMS 和傳統 CMS 的差別
| 比較項目 | 傳統 CMS | Headless CMS |
|---|---|---|
| 頁面由誰產生 | CMS 套用佈景主題輸出 | 另外開發的前台程式 |
| 版面調整 | 編輯者可在後台改版型、區塊 | 要請前台開發者修改 |
| 預覽 | 內建 | 要另外串接草稿預覽 |
| 外掛與佈景主題 | 直接套用 | 影響前台畫面的外掛要重做 |
| 標題、描述、網站地圖 | 佈景主題或外掛輸出 | 由前台產生 |
| 內容供應對象 | 以單一網站為主 | 網站、App 等多個前台 |
| 維護人力 | 一套系統、一組更新 | 後台、前台與 API 各自維護 |
外掛要重做，是因為表單、相關文章、SEO 欄位這類外掛原本在佈景主題裡輸出畫面，換成獨立前台後，這些畫面要由前台開發者自己實作。
適合用 Headless CMS 的情境
- 同一份內容要供應多個前台：官網、App、會員系統或店內螢幕共用產品資料與公告，由一處更新。
- 前台需要高度客製的互動：產品選配、即時查詢這類介面，用前端框架開發比在佈景主題裡修改更有彈性。
- 多個網站共用內容：集團官網、品牌站與多語網站共用同一套內容庫，各站自行決定版型。
- 已有長期配合的開發團隊：前台、API 與主機都有人負責更新與除錯。
判斷的重點不在技術新不新，而在內容是否真的要給多個前台用，以及有沒有人力長期維護兩套系統。
不適合的情境與容易低估的成本
- 頁面不多的形象官網：內容只在一個網站呈現，拆成兩套系統的維護成本沒有對應的效益。
- 行銷人員要自己排版：活動頁常改區塊與版面時，每次都得等開發者修改，反而變慢。
- 沒有固定的開發人力：前台的框架、套件與主機都要持續更新，沒人維護就會累積資安與相容問題。
- 依賴大量外掛功能：表單、會員、電商等原本靠外掛完成的功能，都要在前台重新串接。
評估成本時，除了初次開發，也要把預覽功能、權限設定、快取與重新建置、兩套系統的更新與監控一起算進去。
SEO 要注意的轉譯問題
Headless 架構的 SEO 結果，取決於前台怎麼產生頁面。Google 處理 JavaScript 網頁分成檢索、轉譯與建立索引三個階段，並建議採用伺服器端轉譯或預先轉譯，因為不是所有漫遊器都能執行 JavaScript。前台若完全在瀏覽器端組合內容，就要確認 Google 轉譯後看得到內文，各種轉譯方式的比較見CSR 與 SSR 的差別。上線前逐項檢查：
- 每頁有獨特的標題與描述；Google 建議標準網址寫在 HTML 裡，用 JavaScript 設定時要和原始 HTML 一致。
- 找不到的內容回傳有意義的狀態碼，單頁應用程式要避免軟性 404 錯誤。
- 用 History API 切換網址，不用片段（井字號）載入不同內容。
- 內部連結使用帶 href 屬性的 a 元素，Google 只會找到這種連結。
- 網站地圖、結構化資料與轉址規則由前台或建置流程產生，不再由 CMS 外掛代勞。
完成後用 Search Console 的網址檢查工具，確認 Google 看到的頁面和使用者看到的一致。
常見問題
WordPress 可以當 Headless CMS 使用嗎？
可以。WordPress 官方文件說明 REST API 能讓外部應用程式以 JSON 收送資料，用來打造全新前台。但原本由佈景主題與外掛輸出的功能，要在前台重新實作。
Headless CMS 對 SEO 比較有利嗎？
不一定。搜尋引擎看的是前台輸出的頁面，架構本身不會加分；前台能在伺服器端或建置時產生完整內容，並處理好標題、網址與狀態碼，SEO 條件才和傳統網站相當。
改成 Headless 架構，原本的網址會變嗎？
取決於前台的路由設計，可以沿用舊網址，也可能改變。網址有變動時，要逐一設定轉址，並在上線後用 Search Console 追蹤索引與錯誤頁。
編輯者還能在發布前預覽文章嗎？
要看前台有沒有做草稿預覽。傳統 CMS 內建預覽，Headless 架構需要開發團隊串接未發布的內容與預覽網址，規劃時就要列進需求。
Headless CMS 和 API 是什麼關係？
API 是內容從後台交給前台的管道。Headless CMS 沒有自己的前台，所有內容都經由 API 提供，因此 API 的權限、快取與穩定度，會直接影響網站能否正常顯示。
本文由京采數位科技整理。我們自 2005 年起提供官網設計、系統開發與 Google SEO 服務，實際案例可見成果與案例。
想直接討論你自己的網站狀況，或需要一份初步的搜尋機會評估？
相關主題
下一步
考慮 Headless 架構前，先列出內容要供應哪些前台、誰負責更新版面、有沒有長期維護前台的人力。京采的網頁設計服務可以協助評估傳統 CMS 或 Headless 哪種較適合，規劃內容欄位、前台轉譯方式與網址結構，並在改版上線前檢查標題、轉址與網站地圖。想討論網站架構，歡迎與我們聯繫。
