搜尋與取代 SQL

變更網站網址，又不會破壞序列化資料

在你的瀏覽器裡執行。什麼都不會被上傳。

要進行的變更

舊 URL 新 URL 資料表前綴請查看 wp-config.php。前綴不一定是 wp_ — 在多站台上更絕對不是。

執行任何東西之前先讀這段

WordPress 將許多選項儲存為 PHP-serialized 字串，而序列化字串會記錄自身的位元組長度 — s:19:"http://old-site.com"。單純的 SQL 取代只會更改文字、卻不會更改長度，於是 PHP 再也無法對該列進行反序列化。它並不會報錯。那個值只會悄悄變成空白。

你會失去的東西：小工具設定、佈景主題自訂調整，以及大部分的外掛設定。通常要到幾天後才會發現，而到那時候，你原本能拿來還原的備份也已經沒了。

這就是為什麼下方的查詢刻意不去動 wp_options。

你要搬移的是什麼？

文章內容與摘要post_content 與 post_excerpt 都是純文字，處理起來安全。一併改寫 GUID 欄位除非你清楚為何需要，否則請勿勾選。GUID 是永久的唯一識別碼，不是 URL — 更動它會讓每個 feed 閱讀器把每一篇舊文都當成全新文章。文章自訂欄位（可能是序列化資料 — 有風險）postmeta 經常含有序列化資料。勾選後會顯示對應查詢，並附上明顯的警告。

search-replace.sql

請先備份資料庫。不是「考慮要不要備份」——就是要備份。UPDATE 沒有復原這回事。

關於搜尋與取代 SQL

在 WordPress 資料庫上直接用 SQL 尋找取代，會破壞它所觸及的每一個序列化選項，因為儲存的字串長度不再相符。這個工具會產生安全的查詢語法，並清楚說明哪些做法並不安全。

相關

你可能還需要的其他工具

wp-config.php 產生器

產生正確的 wp-config.php，不必再從 2014 年的部落格文章複製貼上

常見問題

我可以用 SQL 尋找取代來更改我的 WordPress 網站 URL 嗎？

不能安全地做到，而這是 WordPress 界最多人分享的爛建議。許多選項是以 PHP 序列化字串的形式儲存的，這種字串會記錄它自己的位元組長度。單純的 SQL 取代改了文字，卻沒改長度，所以 PHP 會悄悄地無法反序列化那一列，那個值就這麼消失了——連帶帶走小工具設定、佈景主題調整和外掛設定。

那我該改用什麼？

用 WP-CLI：先跑「wp search-replace old new --all-tables --dry-run」，然後再拿掉 --dry-run 跑一次。它懂得序列化，會正確地改寫長度前綴。如果你沒有 CLI 存取權，Better Search Replace 這個外掛能從後台做到同樣的事。

我該更新 GUID 欄位嗎？

不該。GUID 是一篇文章永久的唯一識別碼，不是連結，而且訂閱閱讀器（feed reader）是靠它來辨識的。改寫它會讓每個訂閱者都把每一篇舊文章看成是全新的。WordPress 說明文件明確表示不要更改它。