WordPress搬家：网站迁移应准备哪些记录
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /ca5ac4ce1327.html
📄
WordPress搬家：网站迁移应准备哪些记录
WordPress搬家前最该准备的，不是“一键迁移”按钮，而是一份可核对的记录清单。这份清单要能回答三件事：原站有什么、新站要承接什么、迁移后拿什么判断是否成功。缺少记录时，最容易漏掉的是固定链接结构、用户与权限、定时任务、表单收件地址和外部服务回调地址——这些往往在页面能打开之后才暴露问题。
先记录原站的结构与内容边界
迁移前，把原站的“骨架”写下来，而不是只导出数据库。重点记录以下项目，并注明适用条件：
- 固定链接结构：在设置中查看并截图或抄录，例如是“日期+文章名”还是“分类+文章名”。如果新站要改结构，必须同时准备重定向规则。
- 文章、页面、分类与标签的数量：用后台列表的计数作为迁移前后的对比依据。数量对不上，说明导入不完整。
- 媒体文件总量与目录位置：记录上传目录的路径和大致体积，便于判断是整站打包还是只迁移必要文件。
- 菜单、小工具与主题设置：这些常存在数据库的选项表里，单独导出内容不一定带走。
判断结果的方法很直接：迁移后逐项对照记录，数量、路径、结构一致才算通过。如果原站有自定义文章类型或自定义字段，要额外记录它们由哪个插件或主题注册，否则新站可能出现内容存在但前台不显示的情况。
记录用户、权限与登录方式
用户表是迁移中最容易被忽略的部分。需要记录：管理员账号数量、各角色权限分配、是否开启了强制强密码或两步验证、是否使用了第三方登录。适用条件是：只要新站要继续让原班人马登录，这些记录就必须保留。
这里有一个常见取舍：如果原站用户很多但多数是订阅者，可以考虑只迁移管理员和编辑，其余用户按需重建。代价是评论归属可能丢失，需要提前决定是否接受。判断依据是评论和作者页对业务是否重要。
记录插件、主题与外部服务依赖
不要只记插件名称，要记录它承担的功能和配置位置。例如缓存插件、表单插件、SEO插件、备份插件、电商插件，各自的关键设置分别在哪里。假设原站用表单插件收集询盘，收件地址和自动回复模板写在插件设置里，迁移后如果只装了插件没导入设置，表单可能能提交但收不到通知。
同时记录外部服务：域名解析、CDN、邮件发送服务、支付回调地址、统计代码。这些通常不在WordPress数据库里，需要单独在新环境重新配置。适用条件是任何依赖外部接口的站点；纯展示站可以适当简化，但仍要记录统计代码。
迁移执行与验证的记录步骤
把记录变成可执行的顺序，能减少来回返工：
- 在原站完整备份文件和数据库，记录备份时间与存放位置。
- 在新环境安装同版本或兼容版本的WordPress，记录新站地址和数据库信息。
- 导入数据库和上传目录，按记录逐项核对文章数、页面数、媒体数。
- 检查固定链接、菜单、表单收件地址、定时任务是否恢复。
- 用未登录浏览器和登录浏览器各访问一遍关键页面，记录异常项。
验证时区分“可能原因”和“已经定位的原因”。页面打不开可能是固定链接未刷新，也可能是主题文件缺失，不要一上来就断定是数据库问题。逐项排除，记录每一步的结果，才能把问题缩小到具体环节。
什么情况下需要更完整的记录
如果站点有电商、会员、多语言或大量自定义字段，记录清单要相应扩展，并优先在测试环境演练一次。代价是多花时间，收益是正式迁移时停机更短。如果只是少量页面的展示站，可以精简记录，但备份和固定链接这两项不能省。
下一步：在正式迁移前，先按上面的清单在原站逐项填写一份记录表，并做一次本地或测试环境的导入演练，确认记录足够支撑还原，再安排正式切换。
