多年来我测试过几个 WordPress 迁移插件，包括 All in One WP Migration 和 UpdraftPlus。两者都能用，但在较大网站上都撞到同一堵墙：文件大小上限（免费方案）、服务器超时，或恢复过程中途卡住。运行几次 WordPress 网站迁移后，Migrate Guru 成为我的默认选择。在这个 Migrate Guru 教程中，我会带你完成我的确切流程，以及没人提到、直到你的网站开始在新服务器抛致命错误才显现的清理步骤。
为什么 Migrate Guru 更好处理大型网站
大多数迁移插件通过你自己的服务器 PHP 进程运行整个传输。这意味着你的主机执行时间限制、内存限制和上传大小限制都适用于迁移本身。如果你的网站有大型媒体库或臃肿数据库，迁移可能在完成前就超时。由 BlogVault 构建的 Migrate Guru 工作方式不同。一旦你启动迁移，繁重工作发生在 BlogVault 自己的服务器上，而不是你的托管账户。正因如此，你可以看着网站迁移穿过数万文件，而源或目标服务器不窒息。它也解释了为什么插件不需要你整个迁移时间守着一个打开的浏览器标签页。
开始前：快速迁移前检查清单
不要跳过这部分。这里花几分钟，以后省几小时。
- 对源网站做完整备份（文件和数据库），虽然 Migrate Guru 不碰或删除源网站任何东西。这只是保险；
- 确认目标托管账户就绪，意味着 WordPress 已安装，或至少 PHP 和 MySQL 已配置，你有 wp-admin 访问权；
- 检查目标服务器上的 PHP 版本匹配或超过源网站最低要求，尤其如果网站依赖有最低 PHP 要求的页面构建器或插件；
- 记下域名当前 DNS 记录（A 记录、使用托管邮箱的话 MX 记录、子域名的任何 CNAME 记录），在碰任何东西之前。你以后会需要这些；
- 尽量在迁移前一两天降低 DNS TTL（生存时间）。更低的 TTL 意味着你把域名指向新服务器时传播更快；
- 确保迁移窗口内没有其他人活跃编辑网站，因为迁移开始后做的内容更改不会带过来。
第 1 步：在两个网站都安装 Migrate Guru
在源网站（你要迁出的）和目标网站（你要迁入的）安装并激活 Migrate Guru 插件。在两个网站都点击”Yes, I’ve installed it（是的，我已安装）”。
在两个网站都安装并激活插件后，Migrate Guru 仪表盘会确认，显示绿色”Installed on both sites（已在两个网站安装）”状态。
第 2 步：从目标网站复制迁移密钥
这是最常绊倒人的步骤，所以注意你在哪个网站。在目标网站上，查看 Migrate Guru 界面顶部，复制迁移密钥。
插件会显示弹窗确认”我们假设这是你要迁移到的网站”，以及警告：不要在该网站的第 2 步粘贴相同的密钥。
这个警告存在是有原因的。如果你不小心从错误网站拿密钥或粘贴到错误字段，Migrate Guru 会反转网站、试图朝相反方向迁移。切换到源网站，把密钥粘贴到迁移密钥字段，点击”验证密钥”。验证后，插件用绿色对勾确认密钥，进入第 3 步。
第 3 步：承诺前审查迁移概览
这一步比看起来更重要。点击”发起迁移”前，Migrate Guru 显示迁移概览面板，有两个框：”从（Migrating From）”（你的旧网站）和”到（Migrating To）”（你的新网站），各自显示对应域名或临时 URL。
仔细阅读两个框。仔细检查”从”域名确实是你的源网站，”到”域名是你预期目标，无论是线上域名还是像 .cpanel.site 地址这样的临时暂存 URL。这是任何数据移动前抓住反转连接的最后机会。确认看起来正确后，输入邮箱地址（Migrate Guru 在这里发送状态更新），点击”发起迁移”。
第 4 步：让迁移运行
迁移开始后，你会看到实时进度：总传输文件大小、表数和运行文件计数器（类似”迁移网站（复制文件 5000 / 17726）”）。
根据网站大小和连接，这可能需要几分钟到一小时以上，尤其带大型媒体库的较大网站。你不需要全程保持标签页打开，因为迁移运行在 Migrate Guru 的基础设施上，但我通常让它在后台运行，以便立即捕捉任何错误。
第 5 步：确认迁移完成并测试临时 URL
迁移完成时，你会看到”迁移成功完成！”确认，包含源 URL、箭头、目标 URL 和”访问网站”按钮。
点击进入，在碰 DNS 前实际浏览临时 URL 上的新网站。检查首页、几个内页、联系表单，以及任何动态的东西（购物车或会员登录）。这是问题往往浮出水面的地方，通常以两种方式之一：白屏、致命 PHP 错误，或加载但视觉损坏的网站（样式缺失、图片损坏、混合内容警告）。
第 6 步：先修复致命错误和插件冲突
如果网站抛出致命错误或临时/目标 URL 上白屏，罪魁祸首几乎总是与新服务器环境配合不佳的插件，无论是不同 PHP 版本、不同 Web 服务器（Apache 对比 LiteSpeed 或 Nginx），还是试图写入新主机上不存在路径的缓存插件。修复方法：
- 登录目标服务器的 cPanel 或自定义仪表盘；
- 打开 Softaculous 插件管理器（或用文件管理器，或 FTP/SFTP），一次停用所有插件。如果 Softaculous 不可用，批量重命名插件文件夹或单个插件文件夹有效；
- 如果停用插件不能恢复 wp-admin 访问，用 WordPress 的链接恢复模式。WordPress 检测到插件引起致命错误时会自动发送带恢复链接的邮件，该链接让你直接从仪表盘停用问题插件，即使网站其他方面不可访问；
- 能正常登录 wp-admin 后，逐个重新激活插件，每次激活后重新加载网站。破坏网站的插件会立即显现。记下它，更新它、用替代品替换，或保持停用直到能与插件开发者排查。
第 7 步：碰 DNS 前清理数据库
这是容易搞反顺序的部分，顺序搞错正是导致”正常”临时网站在你把真实域名指向它时崩溃的原因。当你的迁移网站还住在临时 URL 上时，浏览它、测试它、重新激活插件可能导致一些插件和页面构建器把临时域名写入数据库，要么是缓存页面数据、小组件设置，要么是存储绝对 URL 而不是相对 URL 的主题选项。如果你跳过清理、直接做 DNS 切换，你会得到一个在真实域名上的线上网站，仍有指向旧临时 .cpanel.site 地址的失效链接、图片或脚本。所以顺序应该是：
- 安装搜索替换插件（如果有 shell 访问，用 WP-CLI 的 search-replace 命令，对大型数据库更快更可靠）；
- 运行一次搜索替换，捕捉测试期间写入数据库的任何暂存或临时 URL 片段，用你真实、最终域名替换它们，而不是临时域名。搜索你能想到的每个变体：http:// 和 https:// 版本、带和不带 www、原始临时域名本身；
- 检查目标网站 wp-config.php 是否有硬编码的 WP_HOME 或 WP_SITEURL 常量。如果定义了任一，它会覆盖数据库中的任何内容，仅搜索替换不会修复。手动更新为你的真实域名；
- 搜索替换后清除任何缓存插件的缓存（WP Rocket、LiteSpeed Cache、Breeze，无论你运行哪个），否则带旧 URL 的缓存版本页面会继续提供陈旧内容。
在网站仍隔离在临时 URL 上时做这个清理。你想要数据库在那个域名实际上线、接收真实流量前完全指向正确的最终域名。
第 8 步：更新 DNS 指向新服务器
网站干净、在临时 URL 上测试后，更新域名 DNS 记录（通常是 A 记录）指向新服务器 IP。如果你也在完全更换主机（不只是同一主机内换服务器），根据新主机如何管理 DNS，你可能需要更新 nameserver 而不是只更新 A 记录。更新后，等待完全传播再进入下一步。传播可能需要几分钟到 24-48 小时，取决于你之前的 TTL 设置和访客的 DNS 解析器。你可以用 DNS 查找工具检查传播状态，看看新 IP 是否在全球解析，再假设切换在所有地方完成。
第 9 步：重新安装或重新签发 SSL 证书
许多主机在检测到域名解析到他们服务器时自动配置免费 SSL 证书（通常 Let’s Encrypt），但这通常只在 DNS 传播后发生。传播确认后检查目标主机的 SSL 状态，如果没有自动发生，手动触发证书签发。不要跳过这步。HTTPS 不工作就上线的网站会立即抛出浏览器安全警告。
第 10 步：只在 DNS 完全传播后添加 CDN
如果你计划在 Cloudflare、QUIC.cloud 或类似 CDN 后面运行网站，只在 DNS 传播确认、SSL 在新服务器上正常工作后添加它。在域名完全指向新服务器前，或 SSL 签发前添加 CDN，往往会制造自己的一层 SSL 和缓存麻烦，更难诊断，因为你在同时排查 DNS、SSL 和 CDN 缓存问题，而不是一次一个。
第 11 步：最终迁移后 QA 和 SEO 检查清单
域名带着 SSL 和 CDN（如适用）在新服务器上线后，在认为迁移完成前过一遍这个检查清单：
- 在真实域名上浏览网站（不是临时 URL），检查浏览器控制台中的混合内容警告；
- 确认表单（联系表单、新闻通讯注册）仍正确提交，因为表单插件有时存储需要匹配当前域名的端点 URL；
- 检查你的 SEO 插件（Rank Math、Yoast 等）配置正确、站点地图在新位置正常生成；
- 如果域名或 URL 结构有任何变化，在 Google Search Console 重新提交站点地图；
- 验证 robots.txt 没有意外阻止搜索引擎，如果暂存配置带过来，有时会发生；
- 上线后头 24-48 小时设置在线率监控，及早捕捉任何间歇性 DNS 或服务器问题；
- 确认迁移稳定后，从两个网站停用并删除 Migrate Guru 插件，之后没有理由让它保持激活。
关于 Migrate Guru vs UpdraftPlus vs All in One WP Migration 的快速说明
根据我的测试，UpdraftPlus 对定时备份和较小恢复很扎实，但在共享主机上用它做完整网站迁移时，我遇到过上传大小限制和超时。All in One WP Migration 在免费版撞到文件大小上限前效果很好，移除上限的高级扩展如果你只是偶尔迁移，成本会累积。Migrate Guru 无论网站大小都免费，因为它在自己服务器上处理传输而不是你的，它一直是我在带大量媒体文件或重数据库的较大网站上最可靠的选择。
最后的想法
Migrate Guru 可靠处理实际文件和数据库传输，但迁移本身只是工作的一半。真正的风险在清理中：新服务器上的插件冲突、数据库中遗留的暂存 URL，以及顺序搞错的 DNS 或 SSL 步骤。把顺序做对（在临时 URL 测试、修复插件冲突、清理数据库，然后切换 DNS，再添加 CDN），迁移应该能顺利上线，不让客户或你自己的网站察觉到任何变化。
常见问题解答（FAQ）
Migrate Guru 免费吗？比别的迁移插件强在哪？
免费，而且不限网站大小。大多数迁移插件用你自己服务器的 PHP 跑传输，大网站容易撞上执行时间、内存和上传大小限制；Migrate Guru 把重活放在 BlogVault 自己的服务器上，所以几万文件也能扛住，不用守着浏览器等。
迁移密钥到底从哪个网站复制、粘到哪个网站？
从目标网站（要迁入的）复制密钥，粘到源网站（要迁出的）的密钥框里。这是最常绊倒人的一步，搞反了插件会反过来迁移，所以粘贴前一定看清楚你正在操作的是哪个网站。
迁移完打开网站白屏或者报致命错误怎么办？
十有八九是插件和新服务器环境不兼容，比如 PHP 版本不同、Web 服务器类型变了，或者缓存插件写不进去。先登录后台把插件全部停用，再逐个重新激活，破坏网站的那个会立刻现形。
为什么 DNS 切换前非得先清理数据库？
因为你在临时 URL 上测试、重新激活插件时，插件和页面构建器可能把临时域名写进数据库。不清理直接切 DNS，线上网站会残留一堆指向旧地址的失效链接和图片。用搜索替换插件把临时 URL 全部换成正式域名，再检查 wp-config.php 有没有硬编码的 WP_HOME 和 WP_SITEURL，最后清一遍缓存。
迁移要多久？中途能关浏览器吗？
看网站大小，几分钟到一小时以上都有可能。迁移跑在 Migrate Guru 的基础设施上，不用一直开着标签页，不过作者的习惯是让它后台跑着，方便第一时间发现报错。
迁移完成后插件还要留着吗？
不用。确认网站稳定后，把源网站和目标网站上的 Migrate Guru 都停用删除就行，留着没有意义。
