建站教程网站迁移应准备哪些记录：从假设案例看证据收集与定位
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /f017fc6c6fd4.html
📄
建站教程网站迁移应准备哪些记录：从假设案例看证据收集与定位
网站迁移前应准备一份可核对的迁移记录，至少覆盖域名与DNS、服务器环境、文件与数据库、URL与重定向、账号权限、迁移时间线六类信息。记录的目的不是形式留档，而是当迁移后出现打不开、样式丢失、跳转错误或收录异常时，能快速判断问题出在哪一步。下面用一个假设案例展开，说明该记什么、怎么记、哪些常见错误会让记录失效。
假设案例：一次迁移后首页正常、内页404的排查
假设某站点从旧主机迁移到新主机，迁移后首页能打开，但文章内页返回404。此时若无迁移记录，只能靠猜；若有记录，可按以下顺序核对。
- 查URL与重定向记录：旧站是否使用伪静态规则，新服务器是否同步配置了相同规则。
- 查文件与数据库记录：文章数据是否完整导入，表前缀是否与配置文件一致。
- 查服务器环境记录：新环境的Web服务器类型、PHP版本、重写模块是否开启。
- 查DNS与域名记录：解析是否已全部指向新主机，是否存在部分节点仍解析到旧IP。
这个案例中，首页正常说明域名解析和基础环境大体可用；内页404更可能指向重写规则缺失或数据库未完整导入，而不是DNS问题。注意“更可能”不等于“已定位”，需要逐项验证：访问一条已知存在的内页，若返回服务器级404而非程序级404，通常指向Web服务器重写配置；若返回程序级错误页，则更可能指向数据库或程序配置。
迁移前必须建立的六类记录
记录应在迁移开始前整理，而不是出问题后补。每类记录都对应一种可验证的判断依据。
- 域名与DNS记录：域名注册商、DNS服务商、当前A记录/CNAME记录、TTL值、是否使用CDN。判断依据：迁移后解析未生效或部分生效，多与TTL未到期或CDN缓存有关。
- 服务器环境记录：操作系统、Web服务器及版本、PHP/运行环境版本、数据库版本、已安装扩展、重写模块状态。判断依据：环境不一致会导致程序报错或伪静态失效。
- 文件与数据库记录：站点根目录、文件总大小与文件数、数据库名、表前缀、字符集、导出文件校验值。判断依据：导入不完整或字符集不一致会造成乱码、缺数据。
- URL与重定向记录：旧URL结构、伪静态规则原文、需要301跳转的旧地址清单。判断依据：URL规则未同步是内页404和权重分散的常见来源。
- 账号与权限记录：后台管理员、数据库账号、FTP/SFTP账号、SSL证书信息。判断依据：权限或证书配置错误会导致后台无法登录或HTTPS告警。
- 迁移时间线记录：每一步操作的时间、操作人、执行命令或操作内容、结果。判断依据：出现问题时能定位到具体变更点，而不是全盘回滚。
记录怎么记才有用：可核对优于可阅读
有效的迁移记录应满足三个条件：可核对、可对比、可回溯。可核对指记录的是具体值，例如“PHP 7.4”而不是“较新版本”；可对比指迁移前后各记一份，便于逐项比对；可回溯指每条记录带时间和操作来源。
一个可直接执行的检查项：迁移前导出旧站伪静态规则文件内容，迁移后在新服务器执行同一URL的访问测试，记录返回状态码。若旧站返回200、新站返回404，且文件与数据库均完整，则问题范围可缩小到重写规则或Web服务器配置。适用条件是两站程序版本一致；若程序版本本身升级过，则需先排除程序路由变化，再判断服务器配置。
常见错误：这些做法会让记录失去判断力
- 只记“已迁移完成”，不记具体版本、路径和规则原文，出问题时无法比对。
- 迁移后立即修改DNS并删除旧环境，导致无法回查旧配置。稳妥做法是保留旧环境一段时间，确认稳定后再下线。
- 把搜索引擎收录变化直接当成迁移失败。收录波动涉及抓取与索引周期，与服务器迁移是不同层面的问题，应分开记录和判断。
- 用“页面能打开”作为唯一验收标准，忽略内页、后台、表单、HTTPS和移动端路径的抽查。
- 记录中混入未验证的推测，例如把“可能是缓存”写成结论。记录应区分“观察到的现象”和“推测的原因”。
迁移后的核对顺序与下一步
建议按“解析→环境→文件与数据库→URL与重定向→权限与证书→功能抽查”的顺序核对，每一步记录实际结果与预期结果的差异。若某一步出现差异，先在该层内排查，不要跳层猜测。例如解析未生效时，不必先怀疑数据库。
下一步可以直接做一件事：打开旧站与新站，各取首页、一条内页、后台登录页三个地址，记录HTTP状态码和页面表现，形成一张对照表。这张表就是后续定位问题的最小证据集，也是判断迁移是否真正完成的起点。
