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

网站制作中，网站迁移应准备哪些记录：先整理可核对的迁移档案

网站迁移前最该准备的，不是一句“我要换服务器”，而是一套能说明原站状态、迁移动作和迁移后结果的记录。判断标准很简单：如果迁移后首页打不开、文章 404、表单收不到邮件，你能靠这些记录快速区分是 DNS、服务器、程序、数据库还是权限问题。没有记录，排查只能靠猜。

观察：先记录迁移前的基线状态

迁移前要留下原站的可核对信息，重点包括以下几类：

• 域名与 DNS 记录：A 记录、CNAME、MX、TXT 的当前值，以及 TTL 设置。不要只截图，最好导出为文本。
• 服务器信息：原主机商、服务器 IP、操作系统、Web 服务软件及版本、PHP 或运行环境版本、数据库类型与版本。
• 站点结构：栏目数量、页面总数、文章总数、固定链接规则、是否有伪静态规则。
• 程序与插件：CMS 名称与版本、主题名称、已启用插件清单。迁移后功能异常时，这份清单能帮助判断是否缺少依赖。
• 数据库信息：数据库名、字符集、表前缀、大小。导入失败时，字符集和表前缀是常见检查项。
• 证书与邮件：SSL 证书类型和到期时间、发信方式、表单收件地址。

这些记录的作用是建立“迁移前正常状态”的参照。没有参照，迁移后出现异常时，你无法判断是迁移造成的，还是原本就存在。

判断：迁移中要留下操作记录

迁移过程本身也要留痕，否则复查时说不清哪一步改变了什么。建议记录：

1. 备份时间、备份方式、备份文件存放位置和校验值。
2. 数据库导出命令或导出方式，以及导入目标库的时间。
3. 文件上传方式，例如压缩包上传解压还是逐目录同步。
4. DNS 修改时间、修改了哪条记录、改前值和改后值。
5. 如果使用了 CDN 或反向代理，记录回源地址和缓存刷新时间。

判断记录是否够用的方法：假设迁移后某篇文章打不开，你能从记录里查到这篇文章在原站的固定链接、数据库里是否存在、新站是否导入了对应数据。查不到，说明记录不足。

处理：迁移后按清单逐项复查

迁移完成后不要只看首页。按下面顺序检查，并把结果写进同一份记录：

• 首页、栏目页、文章页各打开一个，确认返回状态码正常。
• 检查固定链接是否与迁移前一致，旧链接是否还能访问。
• 登录后台，确认数据库连接、上传目录权限、插件功能是否正常。
• 提交一次测试表单，确认邮件能收到；没有收到时，记录发信方式和报错信息。
• 检查 SSL 证书是否生效，浏览器是否提示混合内容。
• 用 dig 或在线 DNS 查询工具核对解析结果是否已指向新服务器。

如果某项检查失败，先记录现象和发生时间，再对照迁移前基线。例如图片不显示，可能是文件没同步，也可能是上传目录权限不对；两种原因处理方式不同，不能直接断定是某一种。

复查：把记录变成可追溯的迁移档案

一份合格的迁移记录，最后应能回答三个问题：迁移前是什么状态，迁移中改了什么，迁移后哪些功能已验证。适用条件是：只要涉及服务器、域名、程序或数据库变更，就应保留这份档案。判断结果是：出现故障时，你能在几分钟内定位到相关记录，而不是重新翻找聊天记录或凭记忆操作。

下一步，把上述内容整理成一个固定模板，每次迁移前复制一份填写。模板里至少保留“迁移前基线”“迁移操作”“迁移后检查”三栏，后续排查会省去大量重复确认。