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

网站建设时间-网站迁移应准备哪些记录：别把备份当完整档案

网站迁移需要准备的记录，不只是数据库和文件备份。真正决定迁移能否回退、排查和对账的，是一份能说明“原站当时是什么状态”的档案：域名与解析、服务器环境、程序与插件版本、数据库结构、页面与链接、访问统计口径、账号权限和变更时间。只有备份、没有这些记录，迁移后出现问题往往无法判断是数据缺失、配置差异还是链接规则变化。

常见误解：有完整备份就能随时还原

备份解决的是“数据还在不在”，不解决“原站为什么这样运行”。例如同一套程序，原服务器使用旧版 PHP，新服务器使用更高版本，页面可能正常打开，但某些表单或计划任务会报错。若没有记录原环境版本，就只能逐个猜测。再如伪静态规则、重定向、CDN 缓存、邮件发送配置，这些通常不在普通数据库备份里，却直接影响迁移后的访问与收录。

因此，迁移前应把“可还原”拆成两层：一层是数据与文件，另一层是运行环境与规则。两层都留下记录，才算具备基本回退条件。

迁移前必须整理的记录清单

• 域名与解析记录：当前 DNS 服务商、A 记录、CNAME 记录、MX 记录、TXT 记录及 TTL 值。迁移前截图或导出，避免切换后邮件或子域名失效。
• 服务器环境记录：操作系统、Web 服务器、PHP 或运行环境版本、数据库版本、时区、磁盘占用、计划任务。若使用面板，记录面板类型和关键配置项，不记录密码明文。
• 程序与扩展记录：内容管理系统、主题、插件或依赖包的名称与版本号。不要只写“已安装常用插件”，要能对照原站逐项恢复。
• 数据库记录：数据库名、字符集、表前缀、备份时间、备份方式，以及是否包含存储过程、触发器等对象。
• 文件与媒体记录：网站根目录、上传目录、伪静态文件、证书文件、自定义脚本的位置和大小。迁移后可用文件数量与总容量做初步核对。
• 链接与页面记录：原站主要栏目 URL、带参数 URL、已设置的 301 规则、站点地图地址、robots 文件内容。迁移最容易出问题的是旧链接没有对应新地址。
• 账号与权限记录：管理员账号数量、角色权限、API 密钥用途、第三方服务授权范围。只记录用途和归属，不把密钥写入普通文档。
• 统计与验证记录：统计工具类型、验证方式、目标转化设置、搜索资源平台验证文件。迁移后要能确认数据是否仍归到同一站点。
• 变更时间线：最后一次改版、换服务器、换域名、调整链接规则的时间。出现异常时，时间线能帮助缩小排查范围。

用检查项判断记录是否够用

可以做一个假设场景：迁移后首页能打开，但某个栏目页返回 404，同时后台收不到表单邮件。若记录中有旧 URL 清单和重定向规则，就能先判断是链接映射遗漏；若有邮件发送方式和第三方服务配置，就能判断是环境差异还是授权失效。若这些记录都没有，只能从零排查。

判断记录是否够用，可以问三个问题：第一，能否在不询问原维护人的情况下重建运行环境；第二，能否把旧链接逐条映射到新链接；第三，能否在迁移失败后按记录回退到原状态。三个问题有一个答不上来，就应补记录后再迁移。

执行顺序与适用条件

1. 先冻结变更：迁移前一段时间停止改模板、装插件、改链接规则，避免记录与现场不一致。
2. 导出数据与文件，并记录导出时间、文件大小和校验值。
3. 整理域名、环境、程序、数据库、链接、权限六类记录，集中放在可离线保存的位置。
4. 在新环境按记录逐项恢复，先验证后台、数据库连接和静态资源，再验证栏目页与表单。
5. 切换解析前保留旧环境可访问，切换后按旧 URL 清单抽查，确认重定向和状态码符合预期。

这套做法适用于自主迁移或委托他人迁移的普通网站。若网站使用封闭托管平台、无法导出数据库或环境配置，记录重点应转向可导出的内容、域名解析和外部链接，而不是强行记录无法获取的服务器参数。

下一步

先打开原站后台和服务器管理界面，按上面的清单建立一份迁移档案，标出缺失项。缺失项补齐之前，不要开始切换域名解析或删除旧环境。