靜態網站發佈出錯時，通常不會一開始就很誇張。首頁還能開，但活動頁變成 404；桌機看起來正常，手機版卻少了 CSS；圖片或 PDF 的路徑改掉了；客戶預覽連結還出現沒確認過的文案。
真正麻煩的是，團隊開始在 production 上邊猜邊修。
對靜態網站來說，更穩的做法常常很簡單：先還原到上一個確認可用的版本，讓公開連結先回到正常狀態；再回頭查這次發佈到底哪裡壞了。
不是每個小錯都要還原
還原不是用來取代一般編輯流程的。如果只是很小的錯字，而且不影響理解，直接上傳修正版可能就夠了。
它比較適合已經影響公開存取的壞版本。
| 問題 | 為什麼還原有用 |
|---|---|
| 發佈後頁面空白 | 先讓訪客回到可用版本，團隊再檢查壞掉的 build。 |
| CSS、圖片或字型遺失 | 上一版的資源結構通常比在 production 裡猜路徑可靠。 |
| 子頁面或 QR Code 連結 404 | 已經發出去的連結可以先救回來。 |
| 登陸頁文案或價格寫錯 | 先回到已確認內容，再準備修正版。 |
| AI 生成網站還留著佔位內容 | 沒完成的內容不需要繼續公開。 |
| PDF 或下載檔錯誤 | 公開連結先不要繼續指向錯的檔案。 |
判斷標準可以很務實：如果目前公開版本正在影響信任、審閱、投放、求職、課堂作業或客戶交付，先還原通常比邊修邊上線更好。
為什麼靜態網站特別適合回到舊版本
靜態網站本質上就是一組檔案：HTML、CSS、JavaScript、圖片、字型、PDF 和其他靜態資源。如果每次成功發佈都保留完整狀態，就可以把某個舊版本重新設成目前版本。
這和直接覆蓋伺服器目錄不同。覆蓋式做法很容易混出一個中間狀態：舊 HTML、新 JS、遺失圖片、瀏覽器快取全部一起出現。版本化發佈比較清楚，每次部署都應該代表一個完整的網站狀態。
一個可還原的靜態發佈模型，至少要保留這些資訊：
| 層級 | 應該保留什麼 | 為什麼重要 |
|---|---|---|
| 檔案輸出 | 某次發佈的 HTML、CSS、JS、圖片、PDF | 不需要靠記憶重建舊網站。 |
| 發佈記錄 | 哪個版本什麼時候上線 | 可以挑已驗證過的穩定版本。 |
| 網域對應 | 公開 URL 目前服務哪個版本 | 還原可以直接切換目前版本。 |
| 變更上下文 | 誰發佈、改了什麼 | 公開影響先控住，再查原因。 |
Cloudflare Pages 把 rollbacks 描述成回到先前的 production deployment。Vercel 的 Instant Rollback 會把 production domain 指回前一個 deployment。Netlify 也能把過去的 deploy 重新發布成 production。做法不同，但模式一致：舊發布必須還是可服務的目標。
事故中不要臨時重建舊版本
如果所謂還原是「找舊 ZIP、在本機重新 build、再上傳一次，希望它跟舊版一樣」，那其實比較像緊急重發，不是可靠的還原。
緊急重發有時會成功，但它會在最需要降低風險的時候加入新變數：
- 舊原始碼不一定等於當時上線的靜態輸出。
- 依賴、建置工具或環境變數可能已經變了。
- 圖片、PDF 或字型可能放在另一個目錄裡。
- 團隊成員可能選錯
dist、build或out。 - 新上傳可能又製造另一個壞狀態。
更穩的方式是保留以前成功的部署，直接切換目前公開版本。對小型靜態網站來說，發佈記錄不是儀表板裝飾，而是發佈安全的一部分。
什麼時候還原，什麼時候往前修
還原不應該變成長篇討論。可以用幾個問題快速決定：
| 問題 | 如果是 | 如果不是 |
|---|---|---|
| 目前公開網站是否真的影響訪客？ | 還原到上一個穩定版本。 | 可以考慮直接上傳修正版。 |
| 只是很小的文案問題嗎？ | 快速修正後重新發佈可能就夠了。 | 繼續評估影響範圍。 |
| 上一版是否已確認可用？ | 當成還原目標。 | 找最近一次驗證過的版本。 |
| 這次變更是否依賴 API 或外部資料？ | 還原前後都要檢查相容性。 | 靜態檔案還原大概率已足夠。 |
| 正在進行廣告、客戶驗收、求職或課堂作業嗎？ | 先控制公開影響。 | 可以有更多時間排查。 |
目標不是證明還原永遠正確，而是在公開版本明顯變差時，不把時間浪費在猶豫上。
還原後立刻檢查什麼
按鈕顯示成功，不代表使用者體驗真的恢復了。還是要打開真實公開連結確認。
- 用無痕視窗打開首頁。
- 打開最重要的子頁面與已經分享出去的連結。
- 檢查 CSS、JavaScript、圖片、字型、PDF 和下載檔。
- 如果同時使用自訂網域和預覽連結，兩邊都要看。
- 確認 HTTPS 在目前 hostname 上仍然有效。
- 查看統計資料或近期請求，確認流量正在到達恢復後的版本。
- 告訴團隊或客戶，目前 live 的是哪一個版本。
如果事故和網域切換有關，還要檢查 DNS 和憑證。靜態檔案還原不會修好錯誤的 DNS 紀錄，也不會自動處理無關的憑證問題。DeployPages 提供 DNS 查詢 與 SSL 檢查，適合拿來做這類上線前後檢查。
還原不能解決什麼
靜態網站還原回來的是靜態發佈狀態，不會把網站周圍的所有依賴一起倒回去。
| 依賴 | 為什麼還原可能不夠 |
|---|---|
| 外部 API | 舊前端可能依賴已經變動的 API 回應。 |
| 資料庫 | 靜態網站還原不會撤銷資料寫入或 migration。 |
| CMS | 如果頁面執行時讀取外部內容，舊檔案也可能顯示新內容。 |
| 第三方 script | 廣告、統計、聊天工具異常可能同時影響新舊版本。 |
| DNS / SSL | 檔案還原不會修復網域設定。 |
| 瀏覽器快取 | 部分訪客短時間內仍可能拿到快取資源。 |
這個邊界要說清楚。還原對前端和靜態資源事故很有用，但它不是資料庫、API 或後端服務的完整恢復方案。
瀏覽器上傳、Git、CLI 的原則都一樣
靜態網站可以透過不同方式上線，但還原原則一致。
瀏覽器上傳
HTML 資料夾、作品集、AI 生成網站、PDF 頁面、一次性的登陸頁、客戶預覽，常常從瀏覽器上傳開始。風險是，上一版可能只留在某個人的下載資料夾裡。
如果平台保存發佈歷史，舊版本就留在專案裡，不是依賴某台電腦。
Git 發佈
Git 歷史很有幫助，但 commit 不等於當時上線的 artifact。之後重新 build 同一個 commit，依賴、建置設定或環境變數不同，輸出也可能不同。
所以對靜態網站來說，保留「成功部署本身」仍然有價值。
CLI 部署
CLI 讓發佈更容易重複，尤其適合從本機 build 或 CI 發佈。但可重複不等於沒風險。通過建置的版本仍可能包含錯誤路徑、缺圖、舊 PDF 或不該上線的文案。
能重複發佈和能快速還原，是兩層不同的安全能力。
DeployPages 在這個流程裡的位置
DeployPages 更接近「發佈靜態版本」的工作流，而不是手動編輯 live 目錄。
你可以先上傳 HTML 檔案、資料夾、ZIP、PDF、AI 生成網站或框架靜態輸出，拿到 HTTPS 公開連結。專案開始變得重要之後，再繼續使用 還原到先前版本、統計資料、自訂網域、密碼保護 和 CLI 部署。
關鍵很簡單：每一次重要更新都應該留下回去的路。新版本破壞公開 URL 時，團隊不應該一邊讓訪客等待，一邊臨時拼回昨天的網站。
下次發佈前的簡單 playbook
發佈前可以用這張表做輕量檢查：
| 步驟 | 負責人 | 完成標準 |
|---|---|---|
| 幫這次變更命名 | 發佈者 | 團隊知道改了什麼、為什麼改。 |
| 檢查預覽 | 審閱者 | 首頁、關鍵子頁面、資源和行動版都看過。 |
| 保留上一個穩定版本 | 專案負責人 | 有可還原目標。 |
| 發佈到 production | 發佈者 | 公開 URL 顯示預期版本。 |
| 觀察第一批信號 | 負責人 | 統計資料、近期請求和手動檢查沒有明顯異常。 |
| 必要時還原 | 有權限的人 | 公開 URL 回到確認可用版本。 |
| 還原後再排查 | 建置者 | 壞版本不再 live，修復可以從容進行。 |
這個流程不複雜。公開頁面出問題時，複雜流程反而容易讓人更慢。
什麼時候還原變成必需品
如果只是明天就會刪除的臨時預覽，還原可能沒那麼重要。
但只要出現這些情況，就應該保留可還原版本：
- 網站已經綁定自訂網域。
- 連結已經發給客戶、老師、招募方或活動受眾。
- 多個人都能更新同一個專案。
- 網站影響作品展示、履歷、投放、支援或商業轉換。
- 發佈 AI 生成輸出或交接來的靜態檔案，需要審閱。
- 更新夠頻繁，手動 ZIP 歸檔已經不可信。
靜態網站進入真實工作流以後，發佈就不能是一扇單向門。能還原，團隊才敢持續更新。