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

网站建设中_网站迁移应准备哪些记录：从准备到验证的完整清单

网站迁移前最该准备的不是服务器，而是一份能对照核验的记录清单。它至少要覆盖四类内容：迁移前的现状快照、迁移中的操作日志、迁移后的验证结果，以及回滚与维护依据。缺少任何一类，出问题时都只能靠猜。

准备阶段：先把“迁移前长什么样”记下来

迁移最容易踩的坑是改完之后没人记得原来是什么样。所以准备阶段的核心动作是留一份可回查的基线记录。

• 页面清单：把现有可访问的URL逐条列出，包含首页、栏目页、内容页、标签页、分页，以及返回404或301的历史地址。用站点地图加爬取工具交叉核对，避免只依赖后台导出。
• URL与跳转关系：记录每条URL当前的HTTP状态码、是否有跳转、跳向哪里。这是迁移后判断“有没有掉链子”的唯一对照物。
• 标题与描述快照：批量导出每个页面的<title>和<meta name="description">，迁移后逐条比对，防止模板替换时被覆盖。
• 目录与权限结构：记录文件目录层级、上传目录位置、数据库表前缀、伪静态规则文件内容。换环境后路径不一致是常见故障来源。
• 环境参数：程序版本、数据库版本、PHP或其他运行环境版本、已装扩展。版本差异会直接影响页面能否正常渲染。
• 统计与验证工具归属：记录当前使用的统计代码、站长验证文件、第三方脚本位置。迁移后要确认这些是否仍然生效。

这些记录建议存成一份表格加一份原始导出文件，两者互相印证。表格方便比对，原始文件防止表格填错。

实施阶段：操作日志比结果更重要

迁移实施时，每做一步就记一行，包括时间、操作内容、执行人、影响范围。重点记录：

• 数据库导出与导入的时间点、文件大小、是否完整导入；
• 文件打包与解压的路径变化，尤其是绝对路径改成新路径的地方；
• 域名解析或hosts指向的切换时间；
• 跳转规则的新增、修改、删除明细；
• 配置文件中被改动的项，例如数据库连接、缓存路径、上传目录。

如果迁移分多次进行，日志要能区分“哪一次改了什么”。否则验证阶段发现异常时，无法定位是哪一步引入的。

验证阶段：按记录逐项核对，而不是凭感觉

验证要拿准备阶段的基线做对比，关键检查项如下：

1. 抽样访问：从页面清单里按栏目各抽若干条，确认返回200且内容正确。
2. 跳转核对：旧URL是否按记录跳到对应新URL，是否存在跳转链或跳向首页的情况。
3. 状态码扫描：批量检查是否出现新的404、500，以及本应跳转却直接返回200的地址。
4. 标题与描述比对：抽查若干页，确认与快照一致，没有被模板默认值替换。
5. 功能回归：表单提交、搜索、登录、分页、图片加载逐项走一遍。
6. 统计与验证文件：确认统计代码仍在页面中，验证文件可访问。

这里要区分“可能原因”和“已经定位的原因”。比如某页返回404，可能是文件没上传、可能是跳转规则写错、也可能是大小写不一致，在没查日志前不要断定是某一个原因。逐项排除后，记录下确认的结论。

维护阶段：把记录变成长期可用的依据

迁移完成后，把基线记录更新为“迁移后版本”，作为下一次调整的对照物。同时保留旧URL与跳转关系的记录，因为外部链接和用户收藏仍会访问旧地址，跳转规则不宜过早删除。

最关键的一步其实是准备阶段的URL与跳转记录。它同时决定了验证阶段能不能查、出问题时能不能回滚。没有这份记录，后面的验证和维护都缺参照。

下一步可以做的：打开当前站点，导出全部URL及其状态码，存为一份带日期的表格。这份表格就是你这次迁移的起点记录。