wordpress 空间，网站迁移应准备哪些记录
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /d2561094583a.html
📄
wordpress 空间，网站迁移应准备哪些记录
迁移 WordPress 空间时，真正要先准备的不是压缩包，而是一份能还原现场的记录。假设你把网站从 A 主机迁到 B 主机，迁移后首页正常、内页 404，或者图片全部裂开，此时如果没有迁移前的记录，就只能靠猜。记录的作用是让每一步都可核对：原环境是什么、数据放在哪、改过什么、迁移后哪些现象与预期不符。
先记录原空间的环境与访问信息
在动数据库和文件之前，先把原空间的运行环境写下来。这些信息决定新空间能否直接接管，而不是迁移后才发现版本不兼容。
- PHP 版本、MySQL 或 MariaDB 版本，以及是否启用了
mod_rewrite之类的重写模块。 - 网站根目录的绝对路径，以及 WordPress 是装在根目录还是子目录。
- 原空间的域名、是否使用 CDN、是否强制 HTTPS。
- 数据库主机名、数据库名、用户名，以及表前缀。密码单独存放，不要写进公开文档。
常见错误是只记了数据库名，没记表前缀。很多站点安装时改过前缀，导入新库后如果配置里仍写默认的 wp_，页面就会报数据库连接或表不存在。判断方法很直接：打开原站的 wp-config.php，核对 $table_prefix 的值，再和新库中的实际表名比对。
记录文件与数据库的对应关系
WordPress 由文件和数据库共同组成，两者必须来自同一时间点。只备份文件不备份数据库，或只导出数据库不打包 wp-content，迁移后都会出现内容缺失。
需要记录并核对的项目：
- 文件备份的时间与范围，是否包含
wp-content/uploads、主题、插件。 - 数据库导出的时间，以及导出时网站是否处于可写状态。
- 是否有对象存储或外部图床，媒体文件是否真的在
uploads目录里。 - 是否使用了缓存插件生成静态文件，这些文件迁移后应清理而不是照搬。
这里最容易踩的坑是“文件新、数据库旧”。假设你在晚上十点导出数据库，十一点又上传了几张图片，迁移后数据库里没有这些图片的记录，媒体库就看不到它们。判断结果的方法：对比备份时间戳，并检查迁移后媒体库数量与原站是否一致。
记录域名、URL 与重定向规则
换空间常常伴随换域名或换访问地址。WordPress 把站点地址写进数据库，直接改配置不一定能全部替换。
迁移前要记录：
- 原站点地址和 WordPress 地址，即设置里的两项 URL。
- 是否存在旧域名跳转新域名的规则，规则写在服务器配置还是插件里。
- 固定链接结构，例如是否包含日期、分类或
.html后缀。 - 是否有手写的重定向，例如旧文章路径指向新路径。
如果迁移后内页全部 404，而首页正常，优先检查固定链接规则和重写模块，而不是先怀疑数据库。可以在后台重新保存一次固定链接设置，再访问一个内页验证。若仍然 404，再检查服务器是否允许重写。
记录插件、主题与自定义改动
插件和主题是迁移后最容易出问题的部分，因为它们的配置往往存在数据库里，而代码在文件里。
建议逐项记录：
- 已启用插件清单，以及哪些插件带有必须保留的配置。
- 当前使用的主题及子主题，是否直接改过主题文件。
- 是否添加过自定义代码，例如在
functions.php或代码片段插件中。 - 表单、电商、会员类插件的数据表，是否需要单独确认。
常见错误是只迁移了插件文件，没迁移插件数据。假设一个表单插件把提交记录存在自己的数据表里，你只导入了 WordPress 默认表，迁移后表单能显示，历史提交却消失了。判断方法：在新站提交一条测试数据，再回原站对比数据表是否存在同名表。
迁移后按记录逐项核对
记录的价值在迁移后体现。按下面的顺序检查，能把问题定位到具体环节：
- 首页、文章页、分类页、搜索结果页各打开一个，确认不是只有首页正常。
- 登录后台，检查设置中的两项 URL 是否已改为新地址。
- 打开媒体库，确认图片数量和实际文件一致。
- 检查固定链接，随机点开一篇较早的文章。
- 查看服务器错误日志，区分“可能原因”和“已经定位的原因”。
如果出现 500 错误，可能原因包括 PHP 版本不匹配、文件权限不正确或插件冲突；只有查看日志并逐项排除后，才能说已经定位。不要在没有证据时断言是某一个插件导致。
下一步：先按本文清单在原空间整理一份迁移记录，再执行导出和导入。记录越具体，迁移后越容易判断问题出在文件、数据库还是服务器配置。
