網站搬家不只是複製貼上！資深工程師揭秘 WordPress 匯出匯入的 7 個『魔鬼細節』

嗨，我是浪花科技的 Eric。身為一個天天在跟 WordPress 打交道的工程師，我敢說，「網站搬家」這四個字，絕對是許多人心中的痛。你可能覺得，不就是把檔案跟資料庫打包，然後在新家解壓縮、匯入，大功告成？如果你真的這麼想，那恭喜你，你很可能即將踏上一條充滿 Bug、錯誤訊息和無盡加班的荊棘之路。

說實話，我處理過的網站遷移專案，從小型部落格到大型電商，沒一百也有八十。我看過太多因為輕忽細節而導致的災難：網站直接白畫面、圖片全破圖、後台設定跑掉、甚至是客戶資料亂碼… 這可不是開玩笑的。所以今天，我不是要給你一篇「下一步」教學，那太基礎了。我們之前已經有一篇 WordPress 匯出匯入終極指南，但今天，我要帶你深入那些外掛不會告訴你、新手容易踩坑的「魔鬼細節」。搞懂這些，才能真正稱得上是專業的 WordPress 匯出匯入資料最佳實務。

迷思破解：為什麼 WordPress 內建的匯出/匯入功能根本不夠用？

先從一個最大的誤會開始吧。很多剛接觸 WordPress 的朋友會問：「後台『工具』裡面不是有匯出/匯入功能嗎？為什麼不用那個就好？」

唉，工程師的小囉嗦又要開始了。這個內建功能，它的設計初衷是「內容聯合發佈 (Content Syndication)」，而不是「完整網站遷移 (Full Site Migration)」。它匯出的只是一個 XML 檔案，裡面包含了：

• 文章、頁面與自訂內容類型 (Custom Post Types)
• 留言
• 分類與標籤
• 作者資訊

它沒有包含什麼呢？幾乎是所有重要的東西：

• 佈景主題與外掛本身 (只會記錄你用了哪些，但檔案要自己裝)
• 網站設定 (例如：固定網址結構、閱讀設定等)
• 外掛的設定資料
• 使用者帳號與權限 (只會匯出作者，但不會有密碼和完整權限設定)
• 媒體庫中的圖片與檔案 (它只會記錄檔案連結，不會打包檔案)

所以，如果你想用這個功能來搬家，基本上等於只搬了房子的骨架和文字日記，但所有的裝潢、傢俱、電器（佈景主題、外掛、設定）全部都得重新來過。這不是搬家，這是災後重建。所以，忘掉它吧，讓我們來談談真正專業的做法。

魔鬼細節一：資料庫編碼 (Character Encoding) 的隱形殺手

你一定遇過這種慘劇：網站搬完家，所有中文都變成了「????」或是一堆看不懂的亂碼。這就是資料庫編碼搞的鬼。這個問題在 99% 的情況下，都是因為 `utf8` 和 `utf8mb4` 的混用造成的。

簡單來說，`utf8` 是個比較舊的標準，它沒辦法儲存所有的萬國碼字元，例如 Emoji 或是某些特殊符號。而 `utf8mb4` 才是目前 WordPress 官方推薦的、完整的編碼格式。如果在匯出或匯入的過程中，新舊資料庫的編碼不一致，或是轉換過程出錯，亂碼就產生了。

最佳實務：

在動手之前，務必確認來源和目標資料庫的編碼都是 `utf8mb4_unicode_ci`。你可以用 phpMyAdmin 檢查，或是直接用 SQL 指令來修正：

ALTER DATABASE your_db_name CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci;

在匯出資料庫時，也要確保工具的設定是使用 UTF-8 編碼。一個小小的疏忽，就可能讓你花上數小時來修復亂碼地獄。

魔鬼細節二：URL 搜尋與取代 (Search & Replace) 的藝術與陷阱

網站換了網域，下一步當然是把資料庫裡所有舊網址換成新網址。這時候，千萬、千萬不要做一件蠢事：把 `.sql` 檔案下載下來，用文字編輯器做「全部取代」。

為什麼不行？因為 WordPress 資料庫裡儲存了大量的「序列化資料 (Serialized Data)」。這種資料格式會把陣列或物件的結構，連同每個字串的長度一起記錄下來。例如 `s:19:”http://old.domain.com”;` 這代表後面接著一個長度為 19 的字串。如果你的新網址 `https://new.domain.com` 長度不是 19，你直接取代後，長度資訊就錯了，導致整個序列化資料崩潰。網站的小工具、選單、佈景主題設定、部分外掛設定就會全部失效。

最佳實務：

一定要使用「序列化感知 (Serialization-aware)」的工具來進行取代。這才是專業的做法。

• WP-CLI (工程師首選): 這是最穩定、最快、最可靠的方式。透過 SSH 連線到主機後，一行指令搞定：

  wp search-replace 'http://old.domain.com' 'https://new.domain.com' --all-tables --precise --dry-run

  那個 `–dry-run` 參數超重要，它會先模擬執行一次讓你看結果，確認沒問題再拿掉它正式執行。這就是專業人士的保險桿。

• 外掛輔助: 如果你沒有主機的 SSH 權限，可以使用 Better Search Replace 這類外掛。它們的運作原理也是序列化感知的。

魔鬼細節三：處理巨型網站 (Large Sites) 的優雅之道

如果你的網站有幾十 GB，或是資料庫有好幾百 MB，想用 All-in-One WP Migration 或 Duplicator 這類外掛來搬家，你很快就會撞到牆：PHP 執行超時、記憶體不足、主機上傳限制… 各種紅色的錯誤訊息會讓你懷疑人生。

這些外掛是透過 PHP 來執行打包、上傳、解壓縮等動作，非常吃主機資源，而且受到層層限制。對於大型網站，這種方法非常不穩定。

最佳實務 (工程師之路)：

繞過 PHP，直接從伺服器層級動手，這才是處理大型網站最穩健的方式。

• 資料庫: 使用 WP-CLI 或直接用 `mysqldump` 指令來匯出/匯入 `.sql` 檔案。

  # 匯出
  wp db export website_backup.sql
  
  # 匯入
  wp db import website_backup.sql

• 檔案: 使用 `rsync` 或 `scp` 指令來同步 `wp-content` 目錄。這比透過 PHP 壓縮再解壓縮快上百倍，而且幾乎不會失敗。

  # 從遠端主機同步到本地
  rsync -avz user@remote_host:/path/to/wp-content/ /local/path/to/wp-content/

這套組合拳，直接繞過了所有 Web 伺服器的限制，無論你的網站多大，都能穩穩地完成遷移。

魔鬼細節四：檔案與目錄權限 (File Permissions) 的災後重建

這又是一個經典問題。檔案跟資料庫都搬好了，網站卻出現 500 Internal Server Error，或是圖片無法上傳、外掛無法更新。這通常是檔案權限跑掉了。

在 Linux 主機上，每個檔案和目錄都有自己的權限設定。WordPress 需要特定的權限才能正常讀寫。如果權限錯了，伺服器會為了安全而拒絕執行或寫入。

最佳實務：

遷移完檔案後，馬上透過 SSH 執行以下指令，將權限設定為 WordPress 的標準值：

• 所有目錄設為 `755`
• 所有檔案設為 `644`

find /path/to/your/wordpress/ -type d -exec chmod 755 {} \;
find /path/to/your/wordpress/ -type f -exec chmod 644 {} \;

特別注意，`wp-config.php` 這個檔案因為包含資料庫密碼等敏感資訊，權限可以設定得更嚴格，例如 `600` 或 `640`，防止其他使用者讀取。

魔鬼細節五：被遺忘的角落：`wp-config.php` 與 `.htaccess`

幾乎所有的遷移外掛，都會刻意忽略這兩個在網站根目錄的關鍵檔案。因為它們跟伺服器環境高度相關。

• `wp-config.php`: 這裡面有資料庫的連線資訊、安全金鑰、記憶體限制等。你不能直接把舊的檔案複製過去，必須根據新主機的資料庫設定來修改。
• `.htaccess`: 這個檔案掌管了固定網址的重寫規則、快取政策等。直接複製舊的也可能因為新主機模組不同而出錯。

最佳實務：

在新站點，`wp-config.php` 最好是拿 WordPress 官方的 `wp-config-sample.php` 來重新填寫新資料庫的資訊。至於 `.htaccess`，最簡單也最保險的做法是，網站搬完後，登入後台，到「設定」>「固定網址」，什麼都不用改，直接按一下「儲存設定」。WordPress 就會為你自動產生一份符合新主機環境的 `.htaccess` 檔案。

魔鬼細節六：SSL/HTTPS 混合內容 (Mixed Content) 的清理

你可能已經用序列化工具把 `http://` 都換成 `https://` 了，但瀏覽器網址列旁邊還是顯示「不安全」的警告。這就是混合內容 (Mixed Content) 問題。

這通常是因為有些資源（圖片、CSS、JS 檔案）的 URL 是被寫死在佈景主題或外掛的檔案裡，或是被儲存在某些非標準的資料表欄位中，導致搜尋取代工具沒找到它們。瀏覽器在一個 HTTPS 的頁面載入了一個 HTTP 的資源，就會發出警告。

最佳實務：

• 打開瀏覽器的「開發人員工具」(F12)，切換到「主控台 (Console)」，它會明確告訴你是哪個檔案造成了混合內容問題。
• 針對找到的 URL，再次使用 Better Search Replace 或 WP-CLI 進行搜尋取代。
• 如果 URL 是寫死在佈景主題檔案裡，那就得動手改程式碼了。這也是為什麼我們常說，寫 Code 時要用相對路徑或 WordPress 提供的函式來產生 URL，而不是寫死絕對路徑。

魔鬼細節七：匯出匯入前的「健檢清單」

一個稱職的工程師，從來不打沒準備的仗。在開始遷移之前，花十分鐘做個健檢，可以省下你後面十個小時的除錯時間。

遷移前健檢清單：

• 終極備份: 在做任何事前，先用你最信任的方式（例如 UpdraftPlus 或主機商功能）做一次完整的檔案與資料庫備份。這是你的最後一道防線。
• 保持最新: 將來源網站的 WordPress 核心、所有外掛與佈景主題都更新到最新版本。這可以最大程度地減少新舊環境的相容性問題。
• 資料庫瘦身: 刪除不必要的文章修訂、草稿、垃圾留言和資料庫暫存 (Transients)。可以使用 WP-Optimize 這類外掛。一個乾淨、輕量的資料庫，遷移起來更快、更不容易出錯。
• 環境對標: 確認新舊主機的 PHP 版本和 MySQL 版本盡量一致。PHP 5.6 的網站直接搬到 PHP 8.1 的環境，不出錯才怪。
• 暫時停用: 在打包匯出前，暫時停用所有快取外掛 (e.g., WP Rocket, LiteSpeed Cache) 和資安外掛 (e.g., Wordfence)。它們的檔案寫入和防火牆規則有時會干擾遷移過程。

總結：像個專業工程師一樣思考遷移

看到這裡，你應該明白，WordPress 的匯出匯入遠非「複製貼上」這麼簡單。它是一項需要細心、知識和正確工具的系統工程。從資料庫編碼、序列化資料、伺服器權限到環境設定，每一個環節都可能成為引爆災難的地雷。

我的囉嗦總結是：不要盲目信任一鍵遷移外掛，尤其是在處理重要或大型的網站時。去理解它背後運作的原理，學會使用像 WP-CLI 這樣的專業工具，並在動手前做好萬全準備。這不僅能確保你的網站遷移過程順利無痛，更是區分業餘玩家與專業工程師的關鍵所在。

當然，如果你看完這篇文章覺得頭昏腦脹，只想專注在你的業務上，把這些複雜的技術問題交給專業的來。這也是一個明智的選擇。畢竟，時間就是金錢，對吧？

延伸閱讀

• 你的 WordPress 網站有保險嗎？終極自動備份與還原策略，從 UpdraftPlus 到 WP-CLI 全解析
• 終結滑鼠手！資深工程師的 WP-CLI 神兵利器，讓你的 WordPress 管理效率原地起飛！
• 告別FTP手動上傳惡夢！資深工程師手把手搞定 WordPress CI/CD，從 GitHub Actions 到資料庫遷移全攻略

如果您的團隊正在尋找一個專業、可靠的技術夥伴來處理 WordPress 網站的各種疑難雜症，從網站遷移、效能優化到客製化開發，浪花科技都擁有豐富的實戰經驗。歡迎點擊這裡填寫表單，與我們的技術顧問聊聊您的需求，讓我們為您的數位事業保駕護航。