WordPress 搬家加换域名（2026 实操）：用 WP-CLI 替换地址，别再用 SQL 硬怼

站点从一台服务器搬到另一台，顺手把域名也换掉，看着就是复制文件加改数据库的事，真做起来最容易卡在两个地方：数据库里那些硬编码的旧地址，以及切了 DNS 才发现的后台异常。我第一次做的时候就栽在序列化数据上，用 SQL 一把 replace 完，主题设置面板直接白屏。

下面这套流程我后来搬过好几次站，核心是让 WP-CLI 去做地址替换。它走 PHP 而不是纯 SQL，遇到序列化字段会重算长度，光这一条就能省掉八成的翻车。

动手前的准备清单

• 旧站能 SSH，或者面板里带终端，服务器上能用 wp 命令
• 新机的 Nginx/Apache、PHP、MySQL 已经就绪，PHP 版本跟旧站保持一致
• 两边磁盘都留得下一个完整备份的空间
• 域名解析权限在手上，提前把 TTL 调到 600 秒，切换时生效快，回滚也快

旧站没装 WP-CLI 的先装一个：

curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod +x wp-cli.phar
mv wp-cli.phar /usr/local/bin/wp
wp --info   # 能打印 PHP 和 WP-CLI 版本就说明装好了

第一步：旧站导出文件和数据库

cd /www/wwwroot
tar -czf site-files.tar.gz www.old.com      # 整站文件打包

cd /www/wwwroot/www.old.com
wp db export ../site-db.sql --add-drop-table

没装 WP-CLI 的用 mysqldump 顶上，--single-transaction 保证 InnoDB 表在导出期间是一致的，不会拿到半截数据：

mysqldump -u 你的用户 -p --default-character-set=utf8mb4 --single-transaction 数据库名 > site-db.sql

宝塔面板里点「网站 → 备份」和「数据库 → 备份」也行，注意备份文件默认躺在旧机上，得手动下载或者传过去。

第二步：传到新服务器并还原

rsync -avz -e "ssh -p 22" /www/wwwroot/site-files.tar.gz /www/wwwroot/site-db.sql root@新服务器IP:/www/wwwroot/

新机上解包、建库、导入：

cd /www/wwwroot
tar -xzf site-files.tar.gz
mysql -u 你的用户 -p --default-character-set=utf8mb4 新数据库名 < site-db.sql

接着改 wp-config.php 里的 DB_NAME、DB_USER、DB_PASSWORD、DB_HOST，这四个必须对齐新机上的库。文件属主顺手改掉，宝塔的 PHP-FPM 跑在 www 用户下：

chown -R www:www /www/wwwroot/www.new.com
find /www/wwwroot/www.new.com -type d -exec chmod 755 {} \;
find /www/wwwroot/www.new.com -type f -exec chmod 644 {} \;

第三步：替换域名，这一步千万别手抖

先 dry-run，只出报告不写库，看清楚要改哪些表、多少行：

wp search-replace 'https://www.old.com' 'https://www.new.com' \
  --all-tables --precise --skip-columns=guid,user_email \
  --report-changed-only --dry-run

几个参数值得单独说清楚：

1. --all-tables：不只处理 $wpdb 注册的表，插件自建的表也一起扫，不然某些统计插件里还留着旧地址
2. --precise：强制用 PHP 处理，序列化字段会被正确重算长度，不加这个，主题选项里的数组结构迟早坏掉
3. --skip-columns=guid,user_email：guid 是文章的永久标识，改掉会让订阅你 RSS 的读者收到一堆重复文章；顺带跳过用户邮箱列，免得误伤数据
4. --report-changed-only：只输出有改动的表，省得刷屏

报告没问题，去掉 --dry-run 再跑一遍。跑完核对一下站点地址选项（--all-tables 通常已经覆盖，这里是兜底）：

wp option get siteurl
wp option update siteurl 'https://www.new.com'
wp option update home 'https://www.new.com'

最后清缓存，再把固定链接规则重写一次：

wp cache flush
wp rewrite flush --hard

站点挂了 Redis 对象缓存的（比如 Object Cache Pro），记得把 Redis 里的旧键一起清掉，不清的话前台读到的还是缓存里那份旧 URL。

第四步：DNS 先别动，本机验证

改解析之前，用 hosts 把域名临时指到新机 IP：

echo "新服务器IP www.new.com new.com" | sudo tee -a /etc/hosts

或者用 curl 绕过 DNS 指定解析地址：

curl -I --resolve www.new.com:443:新服务器IP https://www.new.com/

要确认的几件事：首页返回 200、文章页里的图片路径指向新域名、后台能正常登录、随便翻一篇早几天发的文章看伪静态有没有 404、HTTPS 证书链完整。全过了再动解析，这一步省不得。

第五步：切 DNS 和收尾

A 记录指向新机 IP，等 TTL 过期，用户陆续切过来。

旧服务器别马上关，留一两周，这段时间它就是你的回滚方案：真出问题，把解析改回旧 IP，TTL 提前调到 600 秒的话几分钟就恢复。旧机的数据库备份 site-db.sql 也留着，别顺手删了。

域名换了的话，旧域名上挂个 301 把权重和流量带过去，别让 Nginx 直接报错：

server {
    listen 443 ssl;
    server_name www.old.com old.com;
    return 301 https://www.new.com$request_uri;
}

踩过的坑

导完库前台全是旧域名、后台却正常，基本是 home 和 siteurl 没同步改，或者缓存没清干净。图片裂开先分辨是存在本地还是走了图床 CDN，走 CDN 的要在那边一起换域名，文章里用了 阿里 ESA 这类加速服务的，去控制台把新域名加进去。

白屏或者主题设置丢失，八成是没加 --precise 直接 SQL replace 干的，序列化字符串长度对不上，PHP 反序列化直接失败。这种情况只能从导入前的备份重来，所以第二步导完库、动手替换之前，先把 site-db.sql 复制一份出来。

后台提示「无法安装插件，请输入 FTP 信息」，是文件属主不对，回到第二步那条 chown。

新旧机环境不一样的话，还有一类很隐蔽的坑：PHP 扩展缺失导致图片处理、webp 转换异常，宝塔下装 ImageMagick 那次踩的就是这个。

搬完之后建议顺手把监控补上，新机器上的访问异常不该等用户来告诉你，用 Uptime Kuma 搭个告警也就十分钟，Web 服务和证书到期日都能盯着。

整个流程真正花时间的不是敲命令，是切换前后那两天的验证和等待。你在哪一步卡住过，评论区说一声，我看看是不是我踩过的那个坑。