Static Frontend 開發紀錄：打造可持續更新的 WordPress 靜態發布系統
WordPress 是一套成熟且容易使用的內容管理系統。無論是企業網站、部落格，還是作品展示網站，都能透過 WordPress 快速建立內容，並持續進行維護。
然而，對許多以資訊展示為主的網站而言，訪客真正需要的，往往只是已經完成編輯的網頁內容。
既然如此，WordPress 是否一定要同時負責內容管理與公開網站的動態執行？
這個問題，成為我們開始規劃 Static Frontend 的起點。
我們希望保留 WordPress 在內容管理方面的優勢，同時讓公開前台採用更精簡的靜態 HTML 架構。
但在研究與規劃過程中，我們逐漸發現，真正的挑戰並不是將 WordPress 網頁轉換成 HTML，而是如何讓轉換後的網站，仍然可以安全、可靠且持續地更新。
這篇文章將分享 Static Frontend 的開發理念、主要架構，以及我們正在解決的幾個重要技術問題。
一、為什麼決定開發 Static Frontend？
將 WordPress 網頁轉換成靜態 HTML，並不是一個全新的概念。
目前已經有一些工具可以擷取 WordPress 網頁，產生靜態檔案，再部署到其他伺服器或靜態網站託管平台。
這些工具證明了 WordPress 靜態化具有實際可行性。
不過，我們希望更進一步思考：對一般網站管理者而言，靜態化應該只是一次性的網站匯出，還是一套能長期運作的網站架構？
假設網站管理者今天將整個 WordPress 網站轉成 HTML，並成功發布到主網域。
隔天，他修改了一篇文章。
接著，他又更換首頁圖片、調整網站選單，或更新了某個共用頁尾區塊。
這時會出現幾個問題：
- 如何知道哪些靜態頁面需要重新產生？
- 修改文章後，相關分類頁、首頁與其他引用內容是否也需要更新？
- 如果部分檔案產生失敗，應該繼續發布還是停止？
- 如果新版本發布後出現問題，能不能回到前一個正常版本？
- 網站管理者是否需要每次都手動重新匯出整個網站？
這些問題，才是讓 WordPress 靜態化能否成為長期解決方案的關鍵。
因此，我們決定將 Static Frontend 定位為一套 WordPress 靜態 HTML 前端建置與發布系統，而不只是單純的 HTML 匯出工具。
二、核心理念：讓 WordPress 專注內容管理
Static Frontend 的基本構想其實很簡單：
後台繼續使用 WordPress，前台改由靜態 HTML 提供內容。
網站管理者仍然透過熟悉的 WordPress 後台編輯文章、建立頁面、上傳圖片及維護選單。
當內容準備完成後，再由靜態發布系統產生公開網站需要的檔案。
訪客瀏覽網站時，則直接讀取已發布的靜態內容，不需要為一般頁面請求執行完整的 WordPress 動態系統。
我們希望透過這種架構，讓不同工作由最適合的環境負責。
WordPress CMS：負責內容管理
WordPress 保留原本的編輯功能，包括文章、頁面、分類、選單、媒體庫及相容的內容管理外掛。
網站管理者不需要因為採用靜態前端，就全面改變原本的編輯習慣。
靜態發布系統：負責內容轉換與發布
Static Frontend 負責將公開內容轉換成適合瀏覽器使用的檔案，並規劃建置檢查、發布管理與後續更新流程。
這個部分是我們開發工作的核心。
靜態前端：負責提供訪客瀏覽
公開網站主要由 HTML、CSS、JavaScript、圖片與其他靜態資源組成。
在正確隔離的架構下，訪客不需要直接連接 WordPress CMS，就能瀏覽公開內容。
這樣的分工讓 WordPress 不必同時承擔所有工作，也讓網站管理者可以依照需求選擇公開前台的部署環境。
三、為什麼靜態網站需要完整的發布流程？
一般網站管理者可能認為，只要成功產生 HTML，就已經完成靜態化。
但實際上，產生檔案與正式發布網站，是兩件不同的工作。
以一個具有數百篇文章的 WordPress 網站為例，轉換過程可能涉及：
- 文章與獨立頁面。
- 首頁、分類頁與文章彙整頁。
- 導覽選單與內部連結。
- 圖片及不同尺寸的媒體檔案。
- CSS、JavaScript 與字型資源。
- 分頁、重新導向與特殊網址。
如果只有部分檔案成功產生，就直接覆蓋公開網站，訪客可能遇到圖片無法顯示、連結失效，甚至部分頁面不存在的情況。
因此，我們認為靜態發布至少需要區分四個主要步驟。
第一步：建置（Build）
從 WordPress 取得需要公開的內容，轉換成靜態 HTML 與相關資源。
建置過程需要記錄處理結果，並辨識成功、失敗或需要進一步檢查的項目。
第二步：檢查（Quality Check）
在正式發布前，檢查產生的靜態內容是否符合預期。
例如：
- 必要的 HTML 頁面是否存在？
- 內部連結是否能找到對應頁面？
- 圖片與其他資源是否成功取得？
- 是否有不應公開的內容被納入輸出？
- 是否存在可能影響瀏覽的重大錯誤？
品質檢查不代表能保證網站完全沒有問題，但可以降低未經驗證的檔案直接進入正式環境的風險。
第三步：發布（Publish）
當建置結果通過預定檢查後，再將靜態檔案部署到公開網站。
這個步驟需要考慮部署權限、檔案完整性，以及如何避免訪客看到不完整的網站版本。
第四步：回復（Rollback）
如果新版本發布後發現問題，應該有機會回到先前保存的正常版本。
對正式營運的網站來說，能否安全回復，往往與能否成功發布同樣重要。
這四個步驟，是我們希望 Static Frontend 逐步建立的核心發布流程。
四、最大的技術挑戰：如何讓靜態網站持續更新？
對一次性的靜態網站匯出工具來說，每次重新產生全部內容，可能是最容易理解的作法。
但如果網站包含大量文章與媒體資源，每次修改一小段文字都重新建置整個網站，就可能造成不必要的資源消耗。
因此，我們正在規劃更有效率的內容更新機制。
偵測 WordPress 內容變更
當網站管理者編輯文章、更新頁面或修改相關設定時，系統需要知道哪些內容發生變化。
在設計上，我們希望利用 WordPress 提供的事件與更新機制，記錄需要重新處理的內容，而不是每次都從頭比較整個網站。
判斷受影響的頁面
內容變更不一定只影響單一網頁。
例如，修改一篇文章，除了文章本身，還可能影響：
- 首頁的最新文章區塊。
- 文章所屬的分類彙整頁。
- 作者文章列表。
- 引用該篇文章的其他頁面。
- 網站地圖與相關導覽資訊。
如果只重新產生被修改的文章，公開網站其他位置就可能保留舊內容。
因此，系統除了記錄內容變更，還需要理解頁面之間的關聯。
選擇性建置與發布
我們規劃讓靜態發布系統逐步支援兩種主要建置方式。
完整建置（Full Site Build）
重新產生網站需要的全部公開內容，適合初次建置或較大範圍的更新。
選擇性建置（Selective Build）
只處理指定或受影響的頁面，並將新結果整合到既有發布版本中。
這種方式可以減少不必要的重複處理，但也會增加系統在版本管理與頁面關聯判斷方面的複雜度。
我們希望優先確保建置結果正確，再逐步提高自動化程度與處理效率。
五、為什麼要建立發布版本與紀錄？
如果網站只是將新產生的 HTML 直接覆蓋舊檔案，短期內可能可以正常運作。
但當網站持續更新，就很難回答一些重要問題：
「現在公開網站是哪一次建置的結果？」
「這次更新修改了哪些檔案？」
「如果新版本有問題，上一個版本還在嗎？」
為了解決這些問題，Static Frontend 的架構設計將建置工作與正式發布版本分開管理。
簡單來說：
建置結果不等於正式發布版本。
一次建置可能只是為了檢查部分頁面，也可能因為錯誤而無法繼續。
只有符合發布條件的結果，才應該成為可供部署的正式版本。
我們也規劃為每個發布版本保存對應的檔案清單與必要資訊，讓系統能追蹤當時應該包含哪些頁面與資源。
這些設計有幾個重要目的：
- 降低未完成建置結果直接影響正式網站的機會。
- 讓每次發布具有可追蹤的版本紀錄。
- 支援後續的選擇性更新與資源管理。
- 為發布失敗處理及版本回復提供基礎。
這些看似屬於系統內部的工作，但最終目的，是讓網站管理者能更放心地更新公開網站。
六、Static Frontend 規劃的三種應用情境
並不是所有使用者都有相同的 WordPress 網站架構。
有些人已經有正式營運的 WordPress 網站，有些人準備建立新站，也有些網站設計公司需要協助客戶轉換既有網站。
因此，我們將 Static Frontend 的開發規劃分成三個階段。
第一階段：將現有 WordPress 網站輸出為靜態檔案
這個階段主要讓既有 WordPress 網站管理者評估靜態化的可行性。
系統將網站前台轉換成 HTML 與相關資源，並輸出到與原 WordPress 網站分開的安全目錄。
原本的 WordPress 網站不需要立即被取代。
網站管理者可以先檢查靜態結果，確認網頁、圖片、選單及其他內容是否符合預期。
我們認為，這是降低靜態化導入風險的重要第一步。
第二階段：WordPress CMS 子網域與公開靜態主站
這是 Static Frontend 最希望推動的主要架構。
例如：
cms.example.com：WordPress 內容管理系統。example.com：公開靜態 HTML 網站。
網站從一開始就將 CMS 與公開前台分開規劃。
管理者在 WordPress 編輯內容，完成建置與發布後，再由主網域提供訪客瀏覽。
這樣的架構有助於減少公開前台對 WordPress 動態執行環境的依賴。
不過，使用不同子網域並不會自動完成安全隔離，仍然需要適當的存取控制、檔案權限與主機設定。
第三階段：將既有 WordPress 主站轉換成前後台分離架構
對已經在主網域運作的 WordPress 網站而言，改採 CMS 子網域與靜態主站的架構，通常不只是輸出 HTML 那麼簡單。
還可能需要處理：
- WordPress 網站搬遷。
- 網址與內部連結調整。
- DNS 與 HTTPS 設定。
- 原有網站的 SEO 與重新導向。
- 靜態網站發布環境的建立。
- 正式切換與必要的回復計畫。
因此，我們將這類遷移工作規劃為較後期的進階能力。
我們希望讓使用者依照網站現況，選擇合適的導入方式，而不是要求所有網站一次完成全面改造。
七、靜態化不代表所有 WordPress 功能都能直接轉換
在規劃 Static Frontend 時，我們也必須面對一個現實問題：
不是所有 WordPress 網站功能，都適合直接轉換成靜態 HTML。
一般文章、企業介紹、作品集與公開展示頁面，通常比較適合靜態化。
但其他功能可能需要額外處理。
例如，WooCommerce 的購物車與結帳、LMS 的課程進度、會員個人化內容，以及需要伺服器處理的互動功能，都不能只靠輸出 HTML 就保留完整運作方式。
即使是聯絡表單，也可能需要另外串接表單處理服務或 API。
因此，我們不希望讓使用者誤以為安裝 Static Frontend 後，所有 WordPress 外掛都能自動變成靜態版本。
產品設計上，我們希望清楚區分適合靜態化的內容，以及仍需要動態後端支援的功能。
對於無法完整轉換的項目，也應盡可能提供明確的檢查結果與說明。
我們更重視可預期的相容性，而不是過度承諾所有功能都能靜態化。
八、開發過程中，我們最重視什麼？
Static Frontend 仍在持續開發中。對我們而言，比起快速堆疊功能，更重要的是先建立穩定的系統基礎。
目前的架構規劃，特別重視以下幾個方向。
可追蹤的建置與發布流程
建置、檢查、發布與回復應具有明確的工作狀態。
當工作失敗時，系統應能記錄發生問題的階段，協助管理者了解處理結果。
可恢復的長時間工作
大型 WordPress 網站可能包含大量頁面與資源。
因此，建置流程不適合完全依賴一次 HTTP 請求完成。
我們正在規劃工作佇列、分批處理與中斷續跑等機制，降低長時間作業因逾時或資源限制而失敗的風險。
安全的管理操作
建置、部署、回復及網站遷移，都可能對網站狀態產生影響。
因此，這些操作需要明確的使用者授權、權限驗證與執行條件檢查。
系統不應只因為收到一個普通的公開請求，就執行可能修改正式網站的工作。
可靠的版本管理
正式發布的網站內容應該具有可辨識的版本資訊。
當建置或部署結果不符合預期時，也需要有安全停止及回復的設計。
這些基礎能力，會影響 Static Frontend 能否從靜態 HTML 產生工具，逐步發展成可靠的發布系統。
九、我們希望 Static Frontend 最終成為什麼樣的工具？
Static Frontend 的目標，不是取代 WordPress，也不是重新發明另一套內容管理系統。
我們希望讓 WordPress 繼續做好它原本擅長的工作：管理網站內容。
而將公開網頁的產生、檢查、部署與維護，交由更適合的靜態發布流程處理。
對一般網站管理者而言，理想的操作方式是：
在 WordPress 編輯文章或頁面，完成內容確認後，讓系統依照設定處理需要更新的靜態網頁。
對網站設計公司而言，則希望能使用 WordPress 完成客戶網站，再將公開內容部署到適合的主機環境，降低交付後公開網站的動態維護需求。
對技術管理者而言，我們希望提供更清楚的建置紀錄、發布狀態與品質檢查資訊，而不只是產生一個壓縮檔案。
這些目標需要分階段實現。
因此，我們會持續依照開發進度確認功能可行性，並透過實際網站測試不同 WordPress 佈景主題、區塊及外掛的相容情況。
十、真正的挑戰不是靜態化，而是持續維護
將 WordPress 網頁轉換成靜態 HTML，只是整個流程的開始。
一個能長期運作的靜態網站，還需要解決內容更新、資源管理、品質檢查、正式發布及錯誤回復等問題。
這也是我們決定開發 Static Frontend 的原因。
我們相信，對許多以內容展示為主的網站來說，WordPress 不需要消失，也不一定需要持續在公開前台執行。
它可以退居幕後，繼續扮演熟悉且成熟的內容管理角色。
而公開網站，則可以採用更精簡的靜態架構。
後台繼續用 WordPress，前台改為 HTML 靜態網頁
保留熟悉的 WordPress，讓公開網站採用更安全快速的運作方式。
