WordPress 搬到 Cloudways、啟用 SSL 或更換主要網域後，資料庫內可能仍留有舊 HTTP 網址、臨時網址或舊主機連結。若直接大量替換，可能令序列化資料、圖片、登入和付款流程出錯。本文示範一套先找出問題、建立備份、分段替換、清理快取並驗證的安全流程。所有網域、IP、帳戶、電郵和應用程式名稱均已遮蔽。
先把變更範圍分開
先區分「主要網域切換」、「HTTPS 強制重新導向」及「資料庫 URL 替換」。三者可互相影響，但不應在未備份時一次完成；每一步都要保留可回退的紀錄。
步驟 1：找出舊網址或 Mixed Content
使用瀏覽器主控台、網站健康檢查或頁面原始碼找出仍載入 HTTP 或舊網域的資源。只記錄資源類型、頁面及時間；公開文章不可展示真實網址、Cookie 或使用者資料。
步驟 2：建立完整備份
在改動資料庫、重新導向或快取前建立按需備份，並確認完成狀態。把備份日期和工作目的記錄在本機 Markdown，作為任何替換失敗時的回退基線。
步驟 3：確認目標 HTTPS 網址
確認 SSL 已有效、主要網域正確，並決定是否使用 www。目標網址必須在 DNS 和 Cloudways 的 Domain Management 一致；不要把真實網域寫入截圖，改以「正式 HTTPS 網址」表示。
步驟 4：安全進行搜尋及替換
使用支援序列化資料的工具，先在 Staging 或預覽模式查看會改動的項目。分批處理文章內容、媒體 URL 和設定值，避免直接以 SQL 對整個資料庫作盲目取代。
步驟 5：設定單一 HTTPS 重新導向
只保留一條清晰的 HTTP → HTTPS 與非主要網域 → 主要網域規則，避免 WordPress、Cloudways 和 CDN 同時製造循環重新導向。修改後先測試首頁及登入頁，再測試深層文章。
步驟 6：清理快取並完整驗證
清理 WordPress、伺服器、CDN 和瀏覽器快取，再用無痕視窗測試圖片、表單、登入、付款和 API。觀察錯誤日誌一個高峰週期，確認沒有舊網址或 Mixed Content 重現。
常見問題：替換後圖片仍顯示舊網址？
可能是 CDN 或瀏覽器仍有快取，也可能圖片欄位在自訂資料表。先清理各層快取並檢查該頁實際輸出的網址，再針對性修正。
常見問題：為何出現重新導向循環？
通常是 Cloudways、WordPress、CDN 或外掛同時強制 HTTPS／www。逐一停用重複規則，只保留單一來源控制，並用無痕視窗測試。
總結
網址遷移的安全順序是「找出問題、備份、確認目標、分批替換、保留單一重新導向、清快取後驗證」。每一步可回退，便能減少 HTTPS 和舊網址造成的網站故障。
