Headless CMS 是什麼？WordPress、Joomla + Astro 與 AI 網站管理

真正麻煩的不是「新增文章」

網站一旦正式營運，很快就會需要更多功能：

再繼續做下去，還要自己處理 XSS、CSRF、SQL Injection、
登入保護、權限驗證、API 驗證與資料回復。

WordPress + Astro 怎麼運作？

WordPress 本身提供 REST API。

Astro 可以在建置網站時取得文章資料，再產生文章列表、 分類頁、文章頁與作者頁，最後輸出 HTML。

如果資料結構較複雜，也可以透過 GraphQL 等方式取得內容。

WordPress 發布文章後怎麼更新 Astro？

三種網站架構比較

※ 自製 CMS 並不是一定不好。
如果後台本身就是企業核心流程， 例如 ERP、CRM、案件管理或特殊權限流程，客製開發仍然有必要。

AI 也可以每週主動告訴我網站排名發生什麼事

網站管理另外一個很浪費時間的地方，就是報表散在不同系統。

這些資料可以透過 API 統整，再交給 AI 每週分析。

這樣就不需要每天打開 Search Console、GA4，再自己把數字拼在一起。

如果把 GSC、GA4、網站內容與 AI 串在一起，
就可以從單純的報表變成持續優化流程。
這也是 AI SEO 自動化 解決的問題。

Headless CMS + Astro 對 SEO 有什麼好處？

這裡要講清楚：

Astro 的優勢主要是網站技術層比較容易控制，例如：

但 Headless 架構拆開後，
也代表 CMS 裡設定的 SEO 資料 必須真的同步到 Astro。

如果 WordPress 或 Joomla 裡設定了 Canonical、Meta、Schema， 但 Astro 沒有輸出，正式網站上一樣不存在。

前後端分離為什麼可以縮小攻擊面？

傳統 WordPress 或 Joomla 網站，前台和後台基本上是同一套 PHP 系統。
網站首頁、文章頁、搜尋頁、登入頁、API、外掛、Theme，
都可能暴露在公開網路上。

攻擊者會持續探測登入入口、公開 API、已安裝外掛與佈景主題的已知弱點，
以及其他對外暴露的 CMS 端點，例如：

或 Joomla 的管理入口、API 與擴充元件。
這些端點本身不代表漏洞，/wp-json/ 是 WordPress REST API 的正常路徑，
也是很多外掛與前端整合仰賴的功能。
真正決定風險高低的是端點暴露程度、 有沒有已知版本漏洞，以及權限與速率限制有沒有設定好。

但如果前台改成 Astro 靜態網站，
公開給訪客的主要內容會變成 HTML、CSS、JavaScript 與圖片，
沒有必要每一次瀏覽文章， 都啟動 WordPress 或 Joomla。

就算有人持續掃描正式網站首頁，他碰到的主要是靜態檔案，
而不是 CMS 的 PHP 執行環境。
這並不能讓網站「不可能被駭」，但可以把主要 CMS 從公開流量路徑中移開。

靜態前台是不是完全沒有程式？

也不是。
Astro 可以保留需要互動的功能，例如搜尋、表單、 會員登入、即時資料、購物車或其他互動元件，
只是不用讓整個網站每一頁都變成動態程式。

Astro 的 Islands 架構可以只讓真正需要互動的元件載入 JavaScript，
其餘內容仍然維持靜態 HTML。
比較接近「90% 靜態內容加上 10% 必要互動」，
而不是整站每一次請求都啟動完整 CMS。

Joomla／WordPress 當 Headless 後台，至少要做哪些防護？

我會把後台分成幾層處理。

1. CMS 核心與外掛一定要更新

   最基本但也是最常被忽略的一項，
   需要持續更新 WordPress／Joomla 核心、Plugin／Extension、Theme／Template、
   PHP、Database、Server 套件與 ImageMagick／Ghostscript 等圖片處理元件。
   2026 年 WordPress 7.0.3、7.0.4 的安全更新 就包含 XSS、SSRF 與特定條件下的遠端程式碼執行問題，
   只把 WordPress 藏在後台並不代表可以停止更新。

2. 後台最好不要直接公開給所有人

   例如原本的 www.example.com/wp-admin/ 可以改成 cms.example.com，
   但子網域本身只是換了一個名字，公開 DNS 仍然查得到，
   不會讓攻擊者找不到入口。
   真正有效的是讓 CMS 不再成為一般訪客的主要公開入口，
   並限制只有授權管理者 與必要服務可以存取，
   例如 Cloudflare Access、VPN、 IP Allowlist、Zero Trust 或 Reverse Proxy 驗證，
   再搭配 2FA 與 WAF。

3. 管理員帳號一定要開 MFA／2FA

   只有帳號密碼不夠，尤其 AI、API、自動化開始接進來之後，
   更不能所有服務共用一組 Administrator 密碼。
   人員帳號需要 2FA，AI／API 則使用獨立 Token，
   兩種權限分開管理。

4. AI 不要拿 Administrator 權限

   如果 AI 只需要新增文章、修改文章、上傳圖片、
   讀取 SEO 資料，就只給這些權限，不要因為方便，
   直接給它 Administrator 或 Super User。
   更不要讓 AI 可以安裝外掛、修改 PHP、新增管理員、
   修改伺服器設定、改資料庫或刪除備份。
   原則就是 Minimum Privilege，最低必要權限。

5. CMS API 也要驗證

   API 不應該變成另一個公開漏洞入口，
   建議至少具備 HTTPS、API Token、權限控管、Rate Limit 與 IP 限制，
   必要時可以讓 Astro Build Server 或 AI Server 才能呼叫寫入 API，
   一般訪客只需要讀靜態網站， 不需要碰 CMS API。

6. 發布與修改最好保留人工確認

   例如 AI 想修改文章，
   流程可以是「AI 建議 → 建立 Draft → LINE 通知 → 人工確認 → Publish」，
   而不是 AI 判斷不好就直接改正式網站。
   這不只是避免 AI 判斷錯誤，也能減少帳號被濫用時的影響。

7. 每一次修改都要留紀錄

   至少要知道誰改的、什麼時間、改哪篇、修改前後的內容、
   是哪個 AI Agent、用了哪個 API Token，這樣出事才能追。
   最好 CMS 本身的版本控制，加上 API Audit Log 都留著。

8. 上傳檔案要特別限制

   檔案上傳一直是 CMS 的高風險區域，建議限制 MIME Type、
   副檔名、檔案大小，並將圖片重新編碼、禁止 PHP／Script、
   Upload Folder 不可執行程式、加上病毒掃描，
   尤其不要讓 AI 可以任意把不明檔案丟進 CMS。

9. 備份一定要獨立

   不能只把 Backup 放在同一台主機，建議正式環境每日備份，
   存到異地或 Object Storage，並保留資料庫、Uploads、
   設定、Astro 原始碼、Git 與 CMS 設定。
   被駭真正可怕的不是「網站掛了」，
   而是沒有乾淨版本可以還原。

10. CMS 和正式前台最好分開主機或至少分開環境

    如果條件允許，可以讓 www.example.com
    走 Astro／CDN，cms.example.com
    走 Joomla／WordPress，這樣就算 CMS 主機正在維護、
    PHP 出問題，已經 Build 好的 Astro 前台仍然可能正常服務，
    前台不一定跟著後台一起掛。

Headless CMS 的代價是什麼？

前面談了不少 Headless 的優點，但代價也要說清楚。

所以 Headless 最適合已有成熟 CMS、內容量大、前台準備重構的網站，
而不是所有 5 頁企業官網都要改成 Headless。

如果今天重新選一次，我會怎麼做？