WordPress 网站搬家到新 VPS，最怕的不是首页打不开，而是首页能开、最新订单却留在旧库，或图片和插件配置只搬了一半。本文针对单站点、保留原域名和原 URL、旧服务器与新 VPS 都能 SSH 登录的场景，给出全站备份、文件与数据库同步、切 DNS 前测试、正式切换和失败回滚的顺序。共享主机没有 SSH 时，仍可按相同验收表操作，但文件导出与数据库导出要改用主机面板；多站点网络、改域名和高并发电商站应单独制定迁移方案。
WordPress 官方的迁移说明指出：同域名、同 URL 搬到新服务器时，要复制站点文件和数据库；若数据库名或账号变化，再修改 wp-config.php。只在后台“工具 → 导出”拿到的文章 XML，不等于完整网站备份：主题、插件、上传文件、用户、设置和插件自建表都需要核对。
开工前记录下面几项，保存到服务器外的迁移清单，别把密码贴到工单或聊天里：
| 核对项 | 迁移前要拿到的值 | 漏掉会怎样 |
|---|---|---|
| 站点地址 | home、siteurl、带不带 www、HTTP/HTTPS | 切换后循环跳转或图片混合内容 |
| 数据 | 数据库名与表前缀、全库大小、wp-content/uploads 大小 | 订单、评论或图片丢失 |
| 环境 | PHP、MySQL/MariaDB 版本与扩展，Nginx/Apache 重写规则 | 插件报错、固定链接 404 |
| 外部依赖 | 对象存储、SMTP、支付回调、Webhook、计划任务、CDN | 首页正常但业务功能失败 |
| DNS | A、AAAA、www、代理状态和 TTL | 部分访客仍到旧机器 |
新 VPS 至少要放得下站点文件 + 数据库 + 一份本机临时备份 + 增长余量。小型展示站可从 2 vCPU、4 GB 内存、40 GB SSD 评估，图片多或有 WooCommerce 的站点按实际峰值和存储量加大。这个配置只是估算起点，不是 WordPress 的官方最低规格。先装好 Web 服务、PHP-FPM、数据库和 WP-CLI，并确认新旧 PHP 版本与插件兼容。公网只开放 80/443 和受限来源的 SSH；数据库端口留在内网或本机。若新机器还没有 WordPress 运行环境，可先参考WordPress Docker + Caddy 部署教程准备目标栈；下文命令以原生 PHP-FPM + 本机数据库为例，容器环境需换成对应容器路径和 docker compose exec。
以下示例把旧站目录写作 /var/www/example.com，新站目录写作 /srv/www/example.com，站点域名写作 example.com，新 VPS IP 写作 NEW_IP，两端都使用可 SSH 登录的 deploy 用户。先替换为真实值，再执行命令。已有站点目录、权限和运行方式不一致时，不要照抄覆盖。
先在旧服务器检查实际路径和数据库连接。wp db export 会读取 wp-config.php 中的数据库凭据，并调用 mysqldump；WP-CLI 文档允许传入 --single-transaction 等参数。下面的 SQL 放在部署用户私有目录，绝不能放进网站根目录：
wp core is-installed --path=/var/www/example.com
wp option get home --path=/var/www/example.com
wp option get siteurl --path=/var/www/example.com
du -sh /var/www/example.com /var/www/example.com/wp-content/uploads
umask 077
mkdir -p /home/deploy/wp-migration
wp db export /home/deploy/wp-migration/preflight.sql \
--single-transaction --path=/var/www/example.com
test -s /home/deploy/wp-migration/preflight.sql
tar -C /var/www -czf /home/deploy/wp-migration/files-preflight.tar.gz example.com
tar -tzf /home/deploy/wp-migration/files-preflight.tar.gz | head
sha256sum /home/deploy/wp-migration/preflight.sql \
/home/deploy/wp-migration/files-preflight.tar.gz
把这两个备份文件和校验值复制到独立存储，实际做一次解压和数据库恢复演练；test -s 只能说明文件非空，不能证明可恢复。若站点含 WooCommerce 订单、会员付款或表单提交，还要确认外部服务的写入入口，选定业务低峰窗口。邮件邮箱、DNS 配置和域名注册信息通常不在 WordPress 文件与数据库内，迁移清单里单独处理。
先在新 VPS建空站点目录与空数据库，不在新环境执行 WordPress 安装向导。数据库要允许 utf8mb4；用户名和强密码替换后再运行 SQL，示例 localhost 对应 wp-config.php 的 DB_HOST=localhost。正式迁移前核对目标库是空库，避免导入覆盖已有业务数据。
sudo install -d -o deploy -g www-data -m 2750 /srv/www/example.com
sudo mysql <<'SQL'
CREATE DATABASE wordpress_live CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'wordpress_live'@'localhost' IDENTIFIED BY 'REPLACE_WITH_LONG_RANDOM_PASSWORD';
GRANT ALL PRIVILEGES ON wordpress_live.* TO 'wordpress_live'@'localhost';
SQL
在旧服务器先做一次文件预同步，让停机窗口只承担最后的增量复制。--no-owner --no-group 避免把旧机器的 UID/GID 原样带到新机；这里故意不用 --delete，防止路径写错时删掉目标文件。文件目录很大时，可在网络稳定的维护窗口前多跑一次预同步。切换前先在新机限制站点访问来源，只允许测试人员访问，防止有人绕过旧站提前向新库写入。
rsync -a --no-owner --no-group --exclude='.maintenance' \
/var/www/example.com/ deploy@NEW_IP:/srv/www/example.com/
新机上检查 wp-config.php 是否已同步，然后只修改数据库连接为新库；不要重新生成 WordPress salts，也不要手工替换整个 SQL 中的域名。按新机的 Web 用户设置权限，确保 Web 进程只对上传目录及确有需要的缓存目录有写权限：
sudo chown -R deploy:www-data /srv/www/example.com
sudo find /srv/www/example.com -type d -exec chmod 755 {} \;
sudo find /srv/www/example.com -type f -exec chmod 644 {} \;
sudo chmod 640 /srv/www/example.com/wp-config.php
sudo find /srv/www/example.com/wp-content/uploads -type d -exec chmod 2775 {} \;
sudo find /srv/www/example.com/wp-content/uploads -type f -exec chmod 664 {} \;
以上权限命令以普通单站目录为例。若插件使用 wp-content/cache 或自定义目录，逐项授予写权限；不要执行 chmod -R 777。调整 Web 根目录、PHP-FPM socket 和固定链接重写规则后，先做 Web 服务配置检查，并确保数据库只监听本机或受控网络。
切换的关键是只允许一个数据库接受写入。先停付款回调、外部队列、系统 cron 等可能绕过前台维护页的写入入口，再在旧服务器进入维护模式。WordPress 的维护模式命令可用于操作，但它本身并不能保证外部程序不写库。
wp maintenance-mode activate --path=/var/www/example.com
wp maintenance-mode status --path=/var/www/example.com
umask 077
wp db export /home/deploy/wp-migration/final.sql \
--single-transaction --path=/var/www/example.com
test -s /home/deploy/wp-migration/final.sql
rsync -a --no-owner --no-group --exclude='.maintenance' --exclude='wp-config.php' \
/var/www/example.com/ deploy@NEW_IP:/srv/www/example.com/
scp /home/deploy/wp-migration/final.sql \
deploy@NEW_IP:/home/deploy/wp-migration-final.sql
如站点持续有程序直接写库，先停止这些进程再导出；--single-transaction 不能替你锁住所有业务写入，也不适用于所有存储引擎。保留旧站完整快照，不要立刻删除旧库或旧 VPS。
在新 VPS确认 wp-config.php 已改为新库后导入。wp db import 不会自动建库，因此前一步必须完成。备份文件导入后尽快转移到受控备份存储并从临时目录清理。
chmod 600 /home/deploy/wp-migration-final.sql
wp db import /home/deploy/wp-migration-final.sql --path=/srv/www/example.com
wp db check --path=/srv/www/example.com
wp core is-installed --path=/srv/www/example.com
wp option get home --path=/srv/www/example.com
wp option get siteurl --path=/srv/www/example.com
home 与 siteurl 应仍是原来的正式域名。同域名迁移不要运行全库 URL 替换。只有同时改变域名、协议或安装路径时，才先备份新库、运行 wp search-replace '旧地址' '新地址' --dry-run --skip-columns=guid 查看命中项，再去掉 --dry-run 正式执行；WP-CLI 的替换命令可处理 PHP 序列化数据，直接用 SQL REPLACE() 批量改 URL 容易破坏序列化值。
先核对新机的 PHP 日志、数据库连接、首页、文章页、图片、后台登录和关键业务页面。若新机已通过 DNS-01 等方式获得该域名的有效证书，可以在本机绕过公共 DNS 直连新 IP：
curl -I --resolve example.com:443:NEW_IP https://example.com/
curl -I --resolve example.com:443:NEW_IP https://example.com/wp-login.php
--resolve 只改变这次请求的解析目标，TLS 仍按 example.com 验证。若证书尚未准备好，不能把 curl -k 的成功当成 HTTPS 验收；应先通过 DNS-01 预签证书，或接受切换后申请证书所需的短暂窗口。站点在 CDN/反向代理后时，还需检查源站 HTTPS 和“灵活 SSL”类配置造成的重定向循环。
至少提前一个旧 TTL 周期检查 DNS 记录。DNS-only A/AAAA 记录可按服务商允许的范围降低 TTL；若用 Cloudflare 代理，代理记录的 TTL 为自动 300 秒，不能手动缩短，而且本地缓存可能持续更久。同时检查 www、AAAA 和 CDN 回源地址，不能只改一个 A 记录。切换时：
- 保持旧站维护模式，确认新库是最终 SQL、文件是最终增量版本。
- 把站点 A/AAAA 或 CDN 回源指向新 VPS；不要误改 MX 等邮件记录。
- 在多个网络检查解析和页面：
dig +short example.com A、dig +short example.com AAAA、curl -I https://example.com/。经 CDN 代理时dig返回的是代理 IP，检查 CDN 控制台的回源配置。 - 在新机确认 HTTPS、后台、上传、表单、支付沙盒/真实小额流程及回调，再撤销切换前的新机访问限制并开放业务写入。恢复计划任务前确保旧机上的对应任务已停止，避免重复执行。
DNS 切换不保证“零停机”：递归解析器、浏览器和 CDN 缓存并不同步。旧机至少保留 48–72 小时，以便处理残余流量和回滚。对订单、支付和会员站，迁移窗口内应记录每笔新写入的归属，不要让新旧两套库同时接单。
如果在新站开放写入之前发现故障，保持旧站快照不动，把 DNS/CDN 回源切回旧机、关闭旧机维护模式，重新检查 PHP 扩展、Web 重写和数据库权限即可。如果新站已经产生新订单、评论或上传，先冻结新站写入并导出新库与新上传文件；不能只把 DNS 改回旧机，否则会丢掉切换后的数据。先制定订单/表单/上传的合并或恢复方案，再决定回到旧站还是修复新站。
| 现象 | 优先检查 |
|---|---|
| “Error establishing a database connection” | 新机 wp-config.php 的 DB_HOST、库名、用户、密码与数据库服务状态 |
| 首页能开、文章页 404 | Nginx/Apache 固定链接重写规则；确认旧站的 .htaccess 是否适用于新栈 |
| 图片 404 或不能上传 | wp-content/uploads 是否完整、Web 用户写权限和对象存储配置 |
| HTTPS 无限跳转 | 站点 URL、反向代理传递的 HTTPS 头、CDN SSL 模式和 Web 重定向规则 |
| 插件后台报 500 | PHP 版本与扩展、插件日志、wp-content 权限；不要直接在生产打开错误输出 |
| 邮件或计划任务失效 | SMTP 凭据、DNS 邮件记录、系统 cron 与 WP-Cron 的责任边界 |
完成条件不只是首页返回 200。抽查近期文章和图片、登录与退出、上传、表单与支付回调；比较新旧文章/订单数量和最终 SQL 时间，观察 24 小时的 4xx/5xx、PHP-FPM 与数据库日志。确认备份已在站外且恢复演练可用，再安排旧 VPS 下线。需要更完整的跨服务商迁移检查表，可继续看通用 VPS 低停机迁移指南。
WordPress 搬家要重新安装吗？ 同域名迁移不需要重新运行安装向导；目标机准备兼容的运行栈，复制原文件与数据库，并修改新数据库连接即可。
只备份 wp-content 可以吗？ 不够。至少还需要数据库、wp-config.php、自定义代码和 Web/计划任务配置；外部对象存储、邮件服务也要单独核对。
DNS 改完为什么还有人看到旧站？ 解析器、浏览器或 CDN 可能仍缓存旧目标；同时核查 AAAA 与 www，并保留旧机维护页直到残余流量消失。
迁移后要不要批量改数据库里的 URL？ 原域名、协议和路径都没变时不需要。变更了 URL 才用能处理序列化数据的工具，先 dry-run 并备份。