如何降低 WordPress 网站搬家风险？这篇文章不再只按工具名称做横向对比，而是从停机时间、数据一致性、服务器权限和回滚能力出发，帮助你先判断风险，再选择 Duplicator、All-in-One WP Migration 或手动迁移。选错方案可能让迁移时间从 10 分钟拉长到 1 小时，也可能因为域名替换、上传限制或序列化数据处理不当，导致图片丢失、后台打不开、订单数据不同步。
先给结论：小型展示站和个人博客可以考虑 All-in-One WP Migration；中型企业站、开发环境到生产环境迁移可优先评估 Duplicator；超过 5GB、包含会员或电商数据的站点，建议手动迁移并配合 WP-CLI 校验。如果你还在规划 WordPress 运行环境，可以先参考 WordPress 相关文章，再结合本文选择迁移路径。
先判断：你真正要迁移的是什么
WordPress 迁移不是简单复制文件。完整站点通常包含 4 类内容：数据库、主题与插件文件、媒体库上传文件，以及服务器侧配置。数据库保存文章、用户、订单和插件设置；文件目录保存主题、插件和图片；[服务器配置](https://cn.hostease.com/blog/server/)包括 PHP 版本、伪静态规则、缓存规则、SSL（安全传输协议）证书和计划任务。
因此，选择 WordPress 迁移工具前，建议先做一次迁移盘点。
- 站点总大小：如果 `wp-content/uploads` 超过 2GB，一键导入类插件容易受 `upload_max_filesize` 和 `post_max_size` 限制影响。
- 数据库大小：如果 SQL 文件超过 500MB，phpMyAdmin 导入可能超时，WP-CLI 或命令行导入更可靠。
- 业务变化频率：普通博客可以接受 30 分钟维护窗口，商城站迁移前则要冻结订单或安排低峰时段。
- 服务器权限：有 SSH 权限时可用 `rsync`、`mysqldump` 和 WP-CLI；只有后台权限时更适合插件迁移。
这也是为什么同一款工具在不同站点上体验差别很大。300MB 企业展示站，用 All-in-One WP Migration 可能 10 分钟完成；12GB WooCommerce 站点，则可能卡在上传、导入或序列化替换环节。
Duplicator：适合中型站点和环境切换
Duplicator 的核心逻辑是“打包、上传、安装”。它会把源站数据库和文件打成归档包，并生成 `installer.php`。上传到目标服务器后，通过浏览器访问安装脚本，填写数据库信息，再完成解压、导入和域名替换。
它最适合的场景，是从开发环境迁移到生产环境、从旧主机迁移到新主机，或者把完整 WordPress 站点复制到全新目录。和后台导入型工具相比，Duplicator 不要求目标站点提前安装好 WordPress，这一点对新服务器部署很方便。
一个常见流程是：在源站创建 Package，下载归档包和 `installer.php`，上传到目标服务器根目录，创建空数据库，访问 `https://example.com/installer.php`，填写数据库名、用户和密码，执行安装，再登录后台保存固定链接。中小型站点通常可以在 10-20 分钟内完成。
但它也有边界。归档包生成和解压依赖服务器资源，站点超过 5GB、图片目录过大或 PHP 执行时间设置较低时，打包阶段可能失败。常见需要检查 `max_execution_time`、`memory_limit` 和磁盘剩余空间。
All-in-One WP Migration：适合小型站点和非技术用户
All-in-One WP Migration 的核心逻辑是“后台导出、后台导入”。源站通过插件导出 `.wpress` 文件，目标站安装全新 WordPress 和同一插件后，直接上传导入文件即可。它最大的价值是降低操作门槛：不需要 FTP（文件传输协议）、数据库工具或命令行，普通站长也能按后台按钮完成迁移。
如果你的站点是个人博客、企业展示页、活动官网，文件总量在几百 MB 到 1GB 左右，并且迁移目标已装好 WordPress，这类工具通常效率很高。迁移后保存一次固定链接，就能刷新伪静态规则，避免文章页出现 404。
它的主要限制来自上传大小和服务器资源。很多主机默认 `upload_max_filesize` 只有 64MB 或 128MB，插件免费版也可能存在导入大小限制。即使购买扩展，大文件上传仍会受网络、PHP 超时和磁盘空间影响。
另一个容易忽略的问题是目标站必须先装好 WordPress。也就是说，它不是裸机迁移工具，而是站点后台迁移工具。如果目标环境的 PHP、数据库版本或文件权限本身有问题，导入成功后也可能出现插件冲突或白屏。正式导入前，建议先确认目标环境能正常安装主题、上传图片并访问固定链接。
手动迁移：适合大站点和复杂业务
它通常分为 6 步：导出数据库、复制文件、创建目标数据库、导入 SQL、修改 `wp-config.php`、替换域名并检查固定链接。每一步都能单独验证，出了问题也更容易定位。
典型命令可以这样理解。数据库导出使用 `mysqldump`，文件复制使用 `rsync`，域名替换使用 WP-CLI：
mysqldump -u db_user -p old_database > backup.sql rsync -avz public_html/ user@new-server:/var/www/site/ wp search-replace 'old-domain.com' 'new-domain.com' --skip-columns=guid wp option get siteurl
其中 `wp search-replace` 很关键。WordPress 数据库里有不少序列化数据，直接用普通 SQL 替换域名，可能破坏字符串长度记录，导致主题设置、小工具或页面构建器内容异常。WP-CLI 会按 WordPress 数据结构处理替换，更适合生产站点。
手动迁移的代价是技术门槛更高。你需要知道数据库名、数据库用户、文件权限、PHP 版本和 Web 服务器配置。如果站点启用了缓存插件，还要迁移后清理页面缓存、对象缓存和 CDN（内容分发网络）缓存。很多[共享主机](https://cn.hostease.com/web-hosting/)没有 SSH 权限，这一步会更不方便。
但对于 WooCommerce 商城、会员站、课程站、多站点网络（Multisite）或数据库超过 1GB 的站点，手动迁移通常更可靠。你可以先同步大文件，再在维护窗口内导最后一次数据库，减少停机时间。迁移完成后，还可以用 `wp post list –post_type=shop_order –format=count` 这类命令快速核对订单数量。
按风险清单选择迁移方式
很多迁移失败不是工具不好，而是工具和场景不匹配。我们建议用下面这套风险清单判断，而不是只看插件评分。
- 站点小于 500MB、只需要后台操作：优先 All-in-One WP Migration，迁移前确认上传限制至少大于导出文件大小。
- 站点 500MB-5GB、目标环境是新服务器：优先 Duplicator，提前准备空数据库和足够磁盘空间。
- 站点超过 5GB 或数据库超过 1GB：优先手动迁移，使用命令行工具分阶段复制和校验。
- 有订单、会员或表单提交：安排低峰维护窗口，并在迁移前后核对关键数据条数。
- 只有 WordPress 后台权限、没有主机面板权限：先选后台迁移插件，不要强行设计复杂手动流程。
如果你正在评估新环境，[服务器性能](https://cn.hostease.com/blog/server/)也会影响迁移体验。文件解压、数据库导入和图片目录同步都需要稳定 I/O（输入输出性能）和足够内存。关于主机方案的基础选择，可以参考 服务器配置相关内容；如果目标站是 WordPress，可以结合 Hostease WordPress 主机方案 评估是否需要预装环境与迁移支持。
迁移前后的检查清单
工具选好后，真正决定迁移质量的是检查。建议迁移前先完成备份，迁移后再按功能逐项验收，不要只看首页能打开就结束。
- 迁移前：导出数据库和 `wp-content`，保留至少 1 份离线备份，记录当前 PHP 版本、数据库版本和固定链接结构。
- 迁移中：暂停缓存预热、定时任务和表单提交，商城站建议开启维护模式，避免迁移过程中产生新订单。
- 迁移后：检查首页、文章页、后台登录、媒体库、表单提交、支付回调和邮件发送。
- 域名切换后：确认 DNS（域名系统）解析生效，检查 SSL（安全传输协议）证书，清理缓存并观察 24 小时错误日志。
如果你使用的是 [VPS](https://cn.hostease.com/vps/)（[虚拟专用服务器](https://cn.hostease.com/vps/)）或独服（[独立服务器](https://cn.hostease.com/dedicated-server/)），还要检查文件所有者和权限。例如 WordPress 目录常见权限是目录 `755`、文件 `644`，但具体还要根据 Web 服务运行用户调整。权限设置不当时，后台可能无法上传图片，也可能出现插件更新失败。更多服务器侧排障思路，可以阅读 网站性能与服务器优化指南。
总结与行动建议
总结来看，All-in-One WP Migration 适合小站点和非技术用户，Duplicator 适合中型站点和新环境部署，手动迁移适合大站点、复杂业务和精细控制。稳妥做法不是追求某个“万能工具”，而是先评估站点大小、服务器权限、业务停机成本和失败恢复方式。
我们建议你按三个步骤执行：先在源站做完整备份，再用测试域名或临时目录跑一遍迁移，最后在低峰时段切换正式域名。小型站点可以直接从插件迁移开始；中大型站点建议准备命令行方案作为兜底。如果你需要更省心的 WordPress 运行环境，可以考虑带预装环境和中文支持的托管方案，同时保留数据库与文件备份，确保下次迁移或回滚有可靠基础。