开始检查前,最需要准备的不是服务器密码,而是一份能还原“原站运行条件”的信息清单。常见误解是:只要拿到 WordPress 后台账号和数据库导出文件,就能顺利迁移。实际上,主机迁移检查要回答的是“新环境能否接住旧站点的全部依赖”,因此域名解析、PHP 与数据库版本、文件路径、插件依赖、邮件与定时任务等信息缺一不可。准备得越完整,越容易在正式切换前判断哪些方案可行。
WordPress 主机迁移通常有两种处理方式:整站备份还原,或手动迁移文件与数据库。两者不是谁更高级,而是适用条件不同。
判断依据是:如果新主机无法识别旧备份格式,整站还原就会失败;如果旧站使用了自定义路径、符号链接或非标准端口,手动迁移又容易遗漏。检查前先把这些条件写清楚,再决定用哪种方案。
迁移检查离不开域名解析。需要准备:当前 DNS 服务商、域名注册商、A 记录与 CNAME 记录、TTL 值、是否使用第三方 CDN 或代理。若原站启用了 HTTPS,还要准备证书类型、签发机构、到期时间,以及证书是否绑定特定 IP 或负载均衡。
这里容易出现的误解是:把 DNS 改到新主机 IP 就等于迁移完成。实际上,DNS 传播受 TTL 影响,旧解析可能仍指向原服务器;如果原站有邮件解析、子域名或验证记录,也不能只改 A 记录。检查时应逐条列出所有解析记录,并标注哪些必须保留、哪些需要指向新主机。
新主机能否运行旧站,取决于环境是否兼容。检查前要准备以下信息:
mysqli、curl、gd、imagick、opcache。.htaccess 或需要转换伪静态规则。判断结果是:如果新主机 PHP 版本低于旧站要求,或缺少关键扩展,迁移后可能出现白屏、上传失败或图片无法处理。此时要么调整新主机环境,要么先降级插件与主题,不能直接假设“上传完就能用”。
数据库不只是文章和用户表。检查前要确认:是否修改过表前缀、是否使用多站点、是否有自定义表、是否开启了对象缓存、是否使用 Redis 或 Memcached。文件方面要确认:上传目录总大小、是否包含软链接、是否有定时任务脚本、是否有邮件发送记录或队列。
短例子:假设原站使用 Redis 对象缓存,迁移检查时只导出了数据库和 wp-content,没有记录 Redis 连接地址与端口。新主机上线后,缓存插件仍尝试连接旧地址,页面可能加载缓慢或报错。这不是迁移文件损坏,而是配置依赖未准备。适用条件是:站点启用了持久对象缓存、CDN 或外部搜索服务时,必须把这些连接信息一并列入检查清单。
下一步建议:把上述信息整理成一张迁移检查表,按“原站信息、新主机信息、差异项、处理方案”四列填写;差异项未清零前,不要切换正式域名。