全球每十個網站，四個以上是用 WordPress 架起來的。根據 W3Techs 的統計，WordPress 在全球所有網站中的市占率是 41.2%，若只看能辨識出所用內容管理系統的網站，占比更高達 59.1%，遠遠拋開其他系統。這麼大規模、也運作超過二十年的系統，照理不該再有什麼新的架構爭論，但這一兩年，「headless WordPress」這個詞卻愈來愈常被提起，不少開發者開始討論要不要把 WordPress 原本負責把內容組成網頁的那一層整個拿掉。
headless WordPress 是什麼，乍聽容易讓人以為是要把整套系統打掉重練。其實這波討論會被重新掀起，不是單純的技術流行，而是這一兩年裡，WordPress 核心團隊、市場需求、使用者體感，甚至 AI 工具的發展，同時把這件事往前推了一把。
先把 headless WordPress 這個詞白話講清楚，搞懂它跟一般在用的 WordPress 差在哪，再一件一件拆這波討論是怎麼起來的。
Headless WordPress 是什麼？
headless WordPress 裡的 WordPress，還是原本那個 WordPress，這件事得先講清楚。後台登入畫面一樣，寫文章、傳圖片、管理使用者的方式也一樣，資料庫裡存的內容一個字都沒少。真正被拿掉的，是把資料庫裡的內容套上佈景主題的版型、直接輸出成一整頁完整 HTML 網頁、送到訪客瀏覽器這件事。
在 headless 架構裡，這件事被切開來做。WordPress 只管內容，不管長相；前台畫面改由另一套獨立的程式負責，通常是用 React、Vue、Next.js 這類前端技術寫成的應用程式。這套程式不會直接去讀 WordPress 的資料庫，而是透過 API 跟 WordPress 要資料。WordPress 官方的《REST API Handbook》說明，REST API 讓外部程式能以 JSON 格式查詢、修改、建立 WordPress 裡的內容，拿到的不是一個現成的網頁，而是一包結構化的原始資料，畫面要交給前端程式自己組裝。
「headless（無頭）」這個名字，指的正是把顯示網頁的那顆「頭」拿掉，只留下負責管理內容的「身體」。WordPress 沒有被拿掉，只是不再負責前台的長相。
跟一般在用的 WordPress，有什麼差異？
把兩種模式並排看，差異會更清楚。一般在用的 WordPress，收到訪客打開網頁的請求後，是在同一套系統裡一次做完三件事：查資料庫、套上佈景主題的版型、輸出一整頁完整的 HTML，直接送到瀏覽器顯示。這個流程從 WordPress 誕生就是這樣運作，也是多數人熟悉的樣子。
headless 模式把這個流程拆成兩段。前端的那套程式（不管是用 React 還是 Next.js 寫的）先透過 API 跟 WordPress 要資料，WordPress 官方文件《REST API Handbook》的〈Key Concepts〉裡，把這套 API 拆成 Routes（路由）、Endpoints（端點）、Requests（請求）、Responses（回應）幾個部分，講的就是外部程式怎麼用結構化的方式跟 WordPress 要到指定的資料。資料以 JSON 格式回傳之後，才輪到前端程式自己把畫面組裝出來，顯示在使用者面前。除了 REST API，想走 GraphQL 這條路的話，WPGraphQL 這款外掛也提供了另一種查詢方式，讓開發者可以更精準地指定要哪些欄位，避免多要或少要資料。
對寫文章、管理內容的人來說，這個轉變幾乎感覺不到。後台操作方式基本沒變，登入、編輯、發布的流程都一樣。真正變的，是訪客打開網頁之後、頁面出現在眼前之前的那一段流程，原本一套系統包辦到底，現在拆成兩套系統接力。
2026 年，Headless WordPress 為什麼又被拿出來討論？
這波討論不是憑空冒出來的，背後有具體的事件在推。最直接的引信是 2026 年 5 月 20 日，WordPress 核心開發團隊正式釋出了代號「Armstrong」的 WordPress 7.0，把過去幾年陸續鋪好的 headless 相關基礎建設，收攏成一條更完整的路線。這個版本更新是這波討論背後最直接的一股力量，除此之外，還有另外三股趨勢，一起把這個架構選項推上檯面。
WordPress 核心團隊親自下場，headless 不再只靠外掛拼裝
時間軸拉出來看，這件事一步一步走了將近兩年。2024 年 10 月，WordPress.org 把 WPGraphQL 這款外掛列為「canonical plugin（官方認可外掛）」，等於官方出面替 GraphQL 這條查詢路徑背書，不再只是第三方湊出來的方案。接著 Abilities API 先在 WordPress 6.9 登場，提供一套標準介面，讓外部程式能發現、呼叫 WordPress 開放出來的功能；到了 2026 年 5 月釋出的 WordPress 7.0，又補上了前端（JavaScript）那一側的 Abilities API，讓開發者在瀏覽器端，也能用同一套邏輯執行導覽、插入區塊這類操作。
這條時間軸說明的是，原本要靠開發者自己找外掛、東拼西湊才能做出來的 headless 架構，現在核心團隊直接把地基一塊一塊鋪好了。這不是行銷詞彙炒作出來的熱度，是版本更新紀錄裡看得到的具體進度。
同一份內容，愈來愈需要同時發到不同管道
內容需要同時出現在網站、App，甚至其他數位管道的需求，這幾年持續在成長。這正好是 headless 架構「內容和顯示分開」的價值所在。同一批內容只要在後台存一次，換一個前端的「頭」就能送到不同地方顯示，不必為每個通路各自複製一份內容。
這股需求擴大不是憑感覺講的。市場研究機構 Future Market Insights 的報告估算，2026 年全球 headless CMS 軟體市場規模約 11.939 億美元，預估到 2036 年會成長到 91.594 億美元，年複合成長率達 22.6%。這份報告也指出，雲端部署與大型企業採用是主要的成長動能，反映出愈來愈多組織把「內容能不能靈活發到不同管道」當成架構選擇的重要考量，不只是把網站做出來就好。
使用者對網頁載入速度，愈來愈沒耐性
效能與載入速度，是選擇 headless 架構時最常被提到的動機之一。前端框架可以把頁面預先產生成靜態檔案，直接從 CDN 送出，不必每次都現場查詢資料庫、現場組版，載入速度容易壓得比傳統架構低。
這件事背後有明確的數據支撐。Google 與 SOASTA 合作的一份研究發現，行動網頁的載入時間從 1 秒拉長到 3 秒，訪客跳出的機率就上升 32%。速度變慢流失的不只是使用者體感，也牽動搜尋排名，Google Search Central 的官方文件說明，Core Web Vitals 這類頁面體驗訊號，已經被正式列入影響搜尋排序的考量之一。換句話說，快不快，現在同時是使用者要不要留下來的問題，也是內容找不找得到的問題。
AI 工具開始能直接讀寫網站內容
這是這波討論裡比較新的一個角度。WordPress 核心團隊在 Abilities API 的基礎上，再做了一層 MCP（Model Context Protocol）轉接層，讓 Claude、Cursor 這類 AI 工具可以直接發現、呼叫網站上開放出來的功能，包括讀取內容，甚至建立與發布內容。開發者只要註冊一次功能，這套轉接層就會自動把它轉換成 AI 工具聽得懂的格式，不必為每個 AI 應用另外寫一套串接。
這件事呼應的正是 headless 架構原本就有的特性，內容透過 API 對外開放，本來就不限定誰來讀。過去這個「誰」通常是另一套前端程式，現在多了一種新的使用者，是 AI 代理程式。AI 工具能做到這件事，靠的是同一套本來就存在的 API，只是多了一顆會直接跟網站對話的頭。
選擇 headless，等於同時維護兩套系統
前面幾節鋪陳的都是 headless 架構愈來愈熱的原因，但熱度不代表它是免費的升級，而是一個要付出對應代價的架構決定。
第一個代價是團隊組成。前台要另外找地方架設，也要另外找人維護。懂 WordPress 後台與 PHP 的人，不一定懂 React 或 Next.js 這類前端框架；反過來，擅長寫前端應用的工程師，對 WordPress 的資料結構跟外掛生態也未必熟悉。原本一組人就能包辦前後台的架構，換成 headless 之後，通常需要兩種不同背景的能力同時到位。
第二個代價是外掛功能要重做。WordPress 生態裡許多好用的外掛，像是表單建置、會員系統、頁面編排工具，都是設計來直接搭配 WordPress 自己的佈景主題運作，這些外掛的前台顯示部分，是靠 WordPress 內建的樣板系統輸出的。換到 headless 架構後，顯示層已經交給另一套前端程式負責，這些外掛原本的前台功能不會自動搬過去，多半得用前端程式重新做一次，不是裝了外掛就能直接用。
第三個代價比較容易被忽略，是內容預覽。一般在用 WordPress 時，編輯者寫到一半，點一下「預覽」就能看到頁面實際長相，這是編輯日常很依賴的功能。到了 headless 架構，後台跟前台是兩套獨立系統，這種即時預覽不會憑空存在，需要額外搭建一套機制，讓後台的草稿內容能即時傳到前端程式那邊組裝、顯示出來。
這三件事沒有一個是裝外掛就能解決的小麻煩，而是要有人力、有時間持續投入的維護工作。
什麼樣的網站，適合認真考慮 headless？
把前面的討論收攏起來，可以整理出幾個比較站得住腳的判斷方向，而不是簡單一句「看情況」帶過。
第一個判準是通路數量。如果內容除了網站，還要同時餵給 App、其他螢幕，甚至其他系統使用，headless 架構「內容和顯示分開」的優勢就會直接反映在開發效率上，不必為每個通路各自維護一份內容。
第二個判準是規模與效能的邊際效益。網站規模與流量大到一定程度，傳統架構能做的效能優化（快取、圖片壓縮、精簡外掛）開始碰到天花板，這時候把顯示層整個換成能預先產生靜態頁面、直接從 CDN 送出的前端框架，能拿到的效能提升幅度才夠明顯，值得花力氣去換。
第三個判準是團隊本身的維運能量。前面提過，headless 架構等於同時維護兩套系統，團隊要有能力長期支撐前後台各自的開發與除錯，而不是換架構的當下有人手，半年後這套前端系統就沒人維護。
反過來，如果只是一般的商用網站，內容更新頻率不高，也沒有多通路發布的需求，傳統架構搭配好的效能優化，多數情況已經夠用，不必為了追這波討論而換架構。
headless WordPress 之所以在 2026 年變成一個常被提起的詞，是因為 WordPress 核心團隊真的把地基鋪得更完整，讓這個架構選項從過去只能靠外掛拼裝，變成一條有官方支援、風險更可控的路線。但地基鋪好，不代表每個網站都該走這條路，它從頭到尾都是一個架構選擇，不是非跟不可的趨勢。
隨著愈來愈多 AI 工具開始直接透過 API 跟網站對話，內容以結構化資料的形式存在，只會愈來愈重要。但要不要連前台顯示也一併拆開，仍然是先看自己的需求，再回頭選架構的問題。