書店要上架一本新書，沒有人會為此把整間店重新裝潢，把書擺上書架就完成了。網站的內容更新本來也該是這種程度：改一段文字、換一張圖片、多發一篇文章，都只是「擺上書架」的動作。讓網站做到這件事的軟體，就是 CMS（Content Management System，內容管理系統）。
沒有 CMS 的網站，每一頁都是一份獨立的檔案，改一個字就得打開檔案修改，再重新上傳到伺服器。這也是為什麼從公司官網、部落格到網路商店，很多網站背後都有一套內容管理系統在運作。
不過 CMS 管的範圍，其實比名稱聽起來更窄一些。它管的是內容，而不是整個網站。
CMS 是什麼？
CMS 是 Content Management System 的縮寫，中文稱為內容管理系統。根據 MDN 的詞彙表，它是一種讓使用者發佈、整理、修改與刪除各種內容的軟體，而這裡說的內容不只有文字，也包含嵌入的圖片、影片、音訊和互動程式碼。
換句話說，使用者在日常操作時，面對的是一個編輯畫面，而不是一堆程式碼。內容怎麼存、頁面怎麼組出來，由系統在背後處理。至於網站長什麼樣子，仍要靠版面與樣板另外決定，CMS 負責的是內容的發佈與整理。
從逐頁手寫 HTML 到後台編輯的轉變
在沒有 CMS 的年代，網站的每一頁都是一份獨立的 HTML 檔。IBM 說明，手動維運網站時，個人或組織得從頭寫程式或靜態 HTML 檔，再把每個網頁分別上傳到伺服器，不但耗費大量時間與精力，之後還得定期更新。假設龐果設計要在網站上新增一頁作品介紹，就得先寫好一份新的檔案，再上傳到伺服器；如果選單也寫在每個檔案裡，每一頁都得跟著改一次。
CMS 把這段工序搬到了瀏覽器的後台。IBM 指出，改用 CMS 平台後，系統的後端與前端都已經建好，網站建立者面對的只是一個能用簡化方式修改內容的介面；使用 CMS 不需要寫程式的知識，介面通常簡單到初學者也能上手。所以 CMS 省掉的是「寫檔案、傳檔案」那一段，而不是「寫內容」那一段，內容本身還是得有人撰寫。
CMS 與 DAM、ECM 等近親詞的分界
搜尋 CMS 的人，很容易同時看到幾個長得很像的縮寫。DAM 是數位資產管理，IBM 說明它的作用是把組織的數位檔案集中存放；CMS 則是建立並管理品牌網站的內容。兩者互補，但不能互換。如果組織有特定的音訊、圖片或影片檔案儲存需求，IBM 認為企業內容管理（ECM）可能更適合。
另外，CMS 這個詞本身就被用在兩種場合：一種是企業內容管理，整合文件管理、數位資產管理與紀錄保存；另一種是網站內容管理，也就是協作建立與維護含文字、圖片、影片的網站。還有一種以元件層級管理內容的 CCMS，常見於技術文件。一般人建立官網、部落格、網路商店時說的 CMS，指的就是網站內容管理這一種。
內容存在資料庫，樣板負責組出頁面
CMS 之所以能讓人只管內容，是因為內容與版面是分開存放的。在後台輸入的每一段文字，系統存起來的是資料，而不是一張已經做好的頁面。
訪客打開網站的那一刻，系統才從資料庫取出對應的內容，填進事先備好的樣板，組成他眼前的頁面。這個分工，是整個 CMS 最核心的設計。
訪客開啟頁面時，系統才把內容填進樣板
要看懂這件事，先對照靜態網站。MDN 說明，靜態網站每次收到某個資源的請求，伺服器都會從檔案系統取出被請求的那份文件，回傳一模一樣的固定內容。每一頁都事先做好，訪客來了就原封不動地送出去。
動態網站則是有需要時才產生回應。MDN 指出，這類網站的 HTML 網頁通常是先從資料庫取得資料，再填進 HTML 範本的佔位符產生出來。流程是瀏覽器先發出 HTTP 請求，伺服器端的程式處理請求後，從資料庫讀取所需的資訊，與 HTML 範本結合，最後送回一份已經組好的 HTML。
這種做法對內容量大的網站幾乎是唯一選擇。MDN 提到，商品或文章數量龐大的網站，為每一件各建一份靜態網頁並不切實際；改把資訊存進資料庫，才能動態建構並回傳 HTML。以 WordPress 為例，系統會依訪客的網址判斷他要看的是哪一類頁面，例如搜尋頁或分類頁，再從目前佈景主題的樣板中挑出對應的那一個來組頁。
編輯端與輸出端合起來才是完整的 CMS
IBM 把 CMS 拆成兩個部分。第一部分是內容管理應用（CMA），讓使用者新增與修改網站內容，同時整合 HTML、CSS、JavaScript，讓內容符合組織的品牌風格；第二部分是後端的內容傳遞應用（CDA），把輸入 CMA 的內容存在幕後，讓所有訪客都看得到。兩者合作，組織便不必手動處理程式碼與資料庫查詢。
這也回答了一個常見的疑問：CMS 和網站後台是不是同一件事？嚴格來說不是。後台只是編輯端，也就是 CMA 的那一塊；CMS 還包含負責存放與輸出內容的那一塊。
內容從撰寫到上線的一般流程，就發生在這兩塊之間。依 IBM 的描述，作者建立內容後，可以在數分鐘內完成預覽、審核與核准；核准後的內容可以排程發佈，或直接自動上線，訪客看到的就是已經發佈的版本。
同一份樣板套用到所有頁面，改版只動一處
共用同一套樣板，是 CMS 另一項不太起眼的好處。打開網路商店的幾個商品頁，會發現它們的結構與版面幾乎一樣，只有商品名稱、圖片與說明不同，這些不同的部分就是從資料庫取出來的內容。MDN 指出，使用資料庫可以有效率地儲存與共享資訊，並讓資訊的呈現只在一個地方控制。
假設龐果設計想調整所有文章頁的標題字級，只需要改一次文章頁的樣板，所有文章就會一起套用，不必逐篇處理。這種內容與呈現綁在同一套系統裡的設計，是傳統 CMS 的特徵，也是後面 Headless CMS 要拆開的那一層。
多數 CMS 共通的權限、版本與內容型別功能
CMS 的功能清單可以列得很長，但真正和「多人、長期管理內容」直接相關的，是三個機制：誰能做什麼、改錯了能不能回頭、內容有沒有固定的資料結構。
這三個機制是多數 CMS 的共通底座，不論軟體是自己架設、由供應商代管，還是只管內容、不管前台，大多都具備，各類型之間的差別並不在這裡。
角色權限與發佈審核流程
網站只有一個人維護時，權限問題不明顯；一旦有多人發佈內容，誰可以改、誰可以上線就必須分清楚。IBM 指出，組織通常有多人發佈內容，所以需要發佈控制與權限，作者可能有不同角色、需要不同程度的存取權限；建立清楚的發佈工作流程，並防止使用者或作者自動發佈，能讓組織避免代價高昂的錯誤。
WordPress 預設有六個角色：Super Admin、Administrator、Editor、Author、Contributor 與 Subscriber，可以拿來看權限分級長什麼樣子。其中四個和內容發佈最相關：
- Editor：可以發佈並管理所有文章，包含他人寫的文章。
- Author：可以發佈與管理自己的文章。
- Contributor：可以撰寫並管理自己的文章，但不能發佈。
- Subscriber：只能管理自己的個人資料。
這些角色的差別是職責，而不是資歷高低。假設王小明是剛加入龐果設計的內容撰寫者，他可以先以 Contributor 的身分寫稿，由 Editor 審閱後才發佈，錯字或不當的內容就不會直接出現在網站上。
版本紀錄、預覽與排程發佈
第二組機制是版本紀錄、預覽與排程，三者都在降低出錯的成本。內容首次發佈之後仍會繼續更新與編輯，版本控制讓每一次變更都能被追蹤，看得出是誰對內容做了什麼修改。以 WordPress 為例，它的修訂版本（Revisions）功能會在每次儲存草稿或更新已發佈的內容時留下一筆紀錄，可以逐版比對改了什麼，改錯時也能還原到先前的版本。
預覽與排程管的則是上線前的那一段。IBM 提到，內容更新可以先預覽、審核與核准，也可以排程發佈或自動上線；此外還有測試（staging）環境，讓使用者在不改動公開內容的情況下，試驗新的內容設計。這些機制的共通點，是讓「改動」和「上線」之間多一道緩衝，錯誤在被訪客看到之前就有機會被攔下來。
內容型別讓同類資料有固定欄位
第三組機制和資料結構有關。許多 CMS 會用結構化內容模型來組織資訊，而不是把每一頁都當成自由格式的文件。做法是先定義內容型別，像是文章、商品、活動、作者，每種型別由預先定義好的欄位與中繼資料組成。例如商品這個型別，可能固定有名稱、規格與圖片這幾個欄位。
結構化內容的好處，在於資訊能一致地跨網站、行動應用程式、搜尋服務等數位平台重複使用，也有利於自動化、個人化與全通路發佈。這正是 Headless CMS 能把同一份內容送到多個出口的基礎。WordPress 也有自訂內容型別，可以在文章、頁面之外再定義自己需要的類型。
CMS 依部署方式與架構分成 3 類
CMS 可以從兩條軸來分類。第一條看誰架設、誰負責主機，也就是安裝在自己的伺服器，還是由供應商的雲端環境代管；第二條看前台是否綁在 CMS 裡。傳統（耦合式）CMS 把內容編寫、儲存與呈現整合成單一應用程式；解耦式 CMS 把後端管理與呈現層拆開，但仍提供專用的發佈環境；Headless CMS 則完全移除呈現層，以 REST 或 GraphQL 這類 API 輸出內容。
實務上最常遇到的選項，可以整理成三類：開源自架、SaaS 建站平台、Headless。這三類不是按軟體名字分的，同一套軟體可能出現在兩類，WordPress 就是例子，它可以自架，也有 WordPress.com 的託管版。三類通常都具備上一節提到的權限、版本與內容型別機制，差別在於由誰負責基礎設施，以及前台怎麼輸出。各類型下提到的平台名稱都只是舉例，不代表排名，也不是推薦。
開源自架 CMS 的軟體免費，主機與維護自行負責
自架型 CMS 的特徵很直接，軟體可以免費取得，但主機要自己找，網域也要另外準備。IBM 列為開源 CMS 的例子有 WordPress、Drupal 與 Joomla。WordPress.com 的支援文件說明，WordPress.org 可以免費下載原始碼並上傳到自己選擇的主機，這種做法稱為自架（self-hosting）。自架不含主機，得另外找主機並付費，要有效建置與維護網站，在技術面也得投入較多。
換來的是高度的技術自由。同一份文件提到，自架可以加入複雜的客製程式碼、調整 PHP 環境，也讓使用者選擇主機的類型與品質，以及決定自己要承擔多少技術維護。代價也就很明確：更新、安全與備份的責任，都落在自己身上。
所以「WordPress 是不是 CMS」這個問題，答案是肯定的，但它屬於哪一類要看使用方式。WordPress.com 的支援文件指出，兩種形式使用的是同一套 WordPress 軟體，主要差別在主機。自行安裝的屬於這一類，由 WordPress.com 代管的版本則比較靠近 SaaS 建站平台。
SaaS 建站平台把編輯、主機與更新交給供應商
SaaS 建站平台的特徵，是編輯、主機、更新與安全都由同一家供應商處理，使用者用帳號登入後台編輯，不必碰伺服器。Wix 與 Squarespace 是這一類常見的例子；Shopify 則偏向電商，同樣把內容編輯和網路商店整合在同一個服務裡。這類平台通常也把網域和基本工具整合在同一處，伺服器佈建、系統維護、應用更新與備份都在供應商的環境裡完成，使用者不必自己管理底層的軟體堆疊。
方便的另一面，是網站必須跑在供應商的基礎設施上。Wix 的說明中心指出，Wix 是雲端的 SaaS 技術，網站必須代管在 Wix 的伺服器上才能正常運作；無法改用其他主機，是因為這套 SaaS 架構使用 Wix 的專有技術，也依賴 Wix 的服務。這也是 SaaS 建站平台共同的取捨，換到省心的同時，也接受了供應商劃定的範圍。
Headless CMS 只管內容，前端以 API 接上
Headless CMS 把「管內容」和「顯示內容」徹底拆開。AWS 的說明是，無周邊（headless）CMS 是一個內容儲存器，能把內容傳送到任何前端或使用者介面；組織用它把內容的管理、儲存與呈現分開，並在各種媒體與數位通道之間重複使用內容。它由三個元件構成：
- 內容儲存器：可以是資料庫、檔案系統或雲端儲存，內容存放在這裡。
- API：可以是 GraphQL 或 RESTful，前端透過它取得內容。
- 前端應用程式：可用任何技術建置，獨立於 CMS，由開發人員呼叫 API 並撰寫呈現內容所需的程式碼。
它和前面提到的解耦式 CMS 容易被混為一談。AWS 的區分是，解耦 CMS 仍保有預設的呈現層，同時透過 API 把內容送到其他平台，所以和前端技術還有一部分綁在一起；Headless CMS 則完全沒有對應的呈現層，前端必須先另外建好，內容才看得到。也因為沒有綁定前台，同一套 Headless CMS 可以拿來管理電商的產品型錄，也可以把內容傳給聊天機器人、語音助理、物聯網（IoT）裝置與 AI 應用。
供應型態上，AWS 分成三種：內容即服務（透過瀏覽器使用，內容存放在供應商那裡）、由使用者自己提供環境的自我託管 CMS，以及全自訂的解決方案。以 Strapi 為例，它是開源的 Headless CMS，開發者可以用它建構自訂的應用程式，再透過內建角色式存取控制的管理後台管理內容。Strapi 可以部署在傳統主機或自己選定的主機供應商上，屬於自我託管這一型；不想自己架設的話，Strapi 另外也提供代管服務 Strapi Cloud。
WordPress 也提供 REST API，以 JSON 讓外部應用程式與站台互動，所以能當作 Headless 架構的內容來源，不過這屬於進階用法。REST API 手冊也提到，站台如果已經正常運作，並不需要勉強改用 REST API。Headless 的共同代價，是前端得有人另外開發。
挑選 CMS 時要對照的實際條件
三類 CMS 沒有誰一定比較好。挑選時要對照的每個條件，都對應到前面三類的某個特徵；條件變了，合適的類型也跟著變。
從最影響自己網站的那一項開始對照，就能很快縮小範圍。
內容出口越多，前端開發人力越重要
內容只發佈到官網一處時，傳統 CMS 或 SaaS 建站平台通常已經夠用。要同時送到網站、App、聊天機器人與其他系統，才有理由考慮 Headless，因為它的設計本來就是為了多出口。
不過出口數量只是其中一個變數，另一個是有沒有開發人力。前面 AWS 的說明已經提到，Headless 的前端要由開發人員呼叫 API、撰寫呈現程式。有些產品的技術文件也直接以開發者為主要讀者，例如 Strapi 的文件就註明，API、設定與開發這幾個部分主要寫給開發者，內容可能預設讀者已具備 JavaScript 生態系的基礎知識。所以 Headless 不是越新越好，出口有幾個、身邊有沒有人能把前端做出來，兩件事要一起看。
更新、備份與資安的維運責任歸屬
三類 CMS 最實際的差別，是維運責任落在誰身上。自架型要自己找主機，並處理更新、備份與資安；WordPress.com 的支援文件也說明，WordPress.org 的主機需要自行尋找並付費，條件依供應商與方案而定。
託管型則把一部分交給供應商。同一份文件提到，WordPress.com 附有針對速度、安全與效能優化的代管主機，並自動處理更新、備份與網域的免費 SSL。代價是使用者要接受供應商設定的範圍，能調整的東西不如自架來得多。
這是責任歸屬的差別，而不是好壞的差別。自架換到的是控制權，託管省下的是維運的時間，選哪個要看自己有沒有人手、願意負責到哪個程度。
日後搬家，能帶走的只有平台允許匯出的部分
選 CMS 時，多數人先看好不好上手，很少先問「以後想換平台，能帶走什麼」。這個問題在 SaaS 平台上特別需要先弄清楚，因為站點本身不一定能搬，匯出的內容也不一定完整。
Wix 的說明中心指出，站點需要在 Wix 的伺服器上運作，但在 Wix 上建立的內容依使用條款屬於使用者，網域也可以向其他供應商購買與管理，再連接到 Wix 站點。Squarespace 則可以把部分站台內容匯出成 .xml 檔，再匯入 WordPress；Squarespace 的說明中心也提到，因為許多功能依賴平台的 JavaScript 與 CSS，部分內容無法匯出。會匯出的包含：
- 版面頁
- 一個部落格頁及其所有文章，每篇文章最多 1,000 則留言
- 文字區塊與圖片區塊
不會匯出的則包含音樂專輯頁、作品集頁、商店頁等其他頁面類型，頁面專屬的頁首、頁尾與側欄，多於一個的部落格頁，下拉選單，音訊、商品與影片區塊，草稿，以及樣式設定與自訂 CSS。另外，Squarespace 站台的匯出檔無法匯入另一個 Squarespace 站台，匯入自架的 WordPress 時，圖片也可能不會一起搬過去。
自架型的搬遷彈性高得多，因為檔案與資料庫都在自己手上。WordPress.com 的支援文件指出，任何 WordPress 站台都能搬進或搬出 WordPress.com，不論原本的主機在哪，兩種形式的內容也都歸使用者所有。這些差異只關乎搬遷範圍，並不代表哪一類比較差。比較務實的做法，是在選定平台之前，先查清楚它的匯出範圍。
網址、Sitemap 與標題設定的後台控制範圍
網址結構、Sitemap、頁面標題與描述，是搜尋曝光的基礎設施。有些 CMS 內建處理，有些要自己建，選型時值得確認這幾項能不能在後台直接控制。Google 搜尋中心指出，如果網站使用 WordPress、Wix 或 Blogger 這類 CMS，系統很可能已經建立好 Sitemap 並提供給搜尋引擎；大部分的 CMS 也會產生 RSS 或 Atom 動態消息。
網址數量一多，這件事就更重要。Google 指出，Sitemap 收錄的網址如果多於幾十個，就需要由系統自動產生。Headless 的前台不在 CMS 裡，這些基礎通常要在前端另外建置；網址規則與 Sitemap 能不能隨著內容一起更新，選型時也要先確認。
內容很少變動的小站，可能不需要 CMS
挑選之前還有一個很實際的前提，並非每個網站都需要 CMS。如果內容固定、很少更新，而且只有一個人維護，靜態網站就已經足夠。前面提過，靜態網站的頁面事先做好，伺服器每次回傳的都是同一份檔案，不經過資料庫，也省下了後台與資料庫的維護。
CMS 真正發揮價值的場合，是需要頻繁更新、多人協作、內容長期累積的時候。選 CMS 之前，先確認自己的網站真的有這些需求，會比一開始就挑功能最多的系統更實際。
先確認內容會不會常常變動、有幾個人要編輯、內容要送到幾個地方，再從三類 CMS 中挑出對得上的那一類，通常比先看哪個產品名氣最大更接近答案。日後搬家時能帶走什麼，也最好在動手建站之前就問清楚。