📍 WDQWDWQD987AAAAA:216.73.216.68
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /d386274ca3cd.html
📄

快速建站网站迁移应准备哪些记录：从观察、判断到复查的清单

网站迁移要准备的记录，核心是三类：迁移前的现状快照、迁移中的变更日志、迁移后的验证结果。缺少任何一类，出问题时都很难判断是数据没搬全、配置没改对，还是外部环境尚未更新。下面按观察、判断、处理、复查的顺序给出可执行清单。

先记录迁移前的现状，作为对照基准

迁移前不记录，迁移后就失去比较依据。建议至少保存以下内容：

• 页面清单：用站点地图或爬虫工具导出现有URL列表，记录每页的标题、状态码、canonical地址。
• 结构与模板：主题、插件、自定义字段、表单、短代码的使用情况，以及哪些是迁移后必须重建的。
• 数据规模：文章数、用户数、媒体文件数量与总体积，用于迁移后核对是否完整。
• 域名与解析：当前DNS记录、TTL值、是否启用CDN，以及SSL证书类型和到期时间。
• 外部依赖：统计代码、支付回调、第三方接口、邮件服务的配置项，这些常被遗漏。

这些记录的作用是“对照”，不是备份本身。备份解决能不能恢复，记录解决恢复得对不对。

判断哪些记录必须随迁移一起带走

并非所有信息都能从旧站自动导出。以下几类需要手动整理：

• 重定向规则：旧URL与新URL的对应关系。若路径结构变化，需提前列出映射表，而不是迁移后临时补。
• 环境配置：数据库连接、缓存设置、伪静态规则、上传目录权限，这些在不同主机上写法可能不同。
• 账号与权限：管理员账号、API密钥、第三方平台的授权信息，注意不要明文存放在公开目录。
• 时间点记录：迁移开始时间、DNS修改时间、缓存刷新时间，用于判断外部更新进度。

判断标准很简单：如果这条信息丢了，你是否需要重新向外部服务方申请或重新配置？如果是，就必须单独记录。

迁移过程中的变更日志怎么写

变更日志不需要复杂格式，按时间顺序记录“改了什么、在哪改的、谁改的”即可。例如：

14:00 修改DNS A记录指向新IP；14:10 刷新CDN缓存；14:30 旧站开启只读。

这样做的好处是，当出现页面打不开或样式错乱时，可以快速定位是解析尚未生效、缓存未刷新，还是文件本身没传完。注意区分“可能原因”和“已确认原因”：解析未生效只是可能原因之一，需通过查询DNS返回结果来确认，不能仅凭现象下结论。

迁移后按清单复查，而不是凭感觉

复查要逐项对照迁移前的记录，建议至少检查：

1. 随机抽取若干URL，确认返回状态码为200，页面内容与迁移前一致。
2. 核对文章数、用户数、媒体文件数是否与记录相符。
3. 测试表单提交、搜索、登录等动态功能。
4. 检查重定向是否按映射表生效，旧链接是否能到达对应新页面。
5. 确认SSL证书有效，页面没有混合内容警告。
6. 观察一段时间内的访问日志和错误日志，看是否有集中报错。

复查结果要写回记录中，形成“迁移前—变更—迁移后”的完整链条。若某项未通过，先判断是数据问题还是配置问题，再决定回滚还是修补。

下一步可以做什么

现在就可以打开一个空白表格，按“迁移前快照、变更日志、复查结果”三列建立记录框架，并在正式迁移前先填入现状数据。记录越早开始，迁移当天的判断就越有依据。