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

自建网站排名：网站迁移应准备哪些记录？一份面向多人协作的交付清单

网站迁移要准备的记录，核心是让接手的人不看聊天记录也能独立完成上线、验证和回滚。建议把资料分成五类：现状清单、变更记录、权限与账号、验证证据、回滚方案。每一类都指定负责人，并在迁移前完成一次“空手交接”演练：由未参与前期工作的人按记录操作，能复现结果才算交付清楚。

先定交付结果，再倒推需要哪些记录

迁移的交付结果不是“文件传完了”，而是新环境能稳定提供与原站一致的内容和访问体验，并且出问题时能退回原状。围绕这个结果倒推，记录至少要回答四个问题：原来有什么、这次改了什么、谁有权操作、怎么证明没问题。

• 原来有什么：页面清单、URL 结构、跳转规则、静态资源目录、数据库表结构。
• 这次改了什么：域名解析、服务器配置、目录路径、模板或主题、插件或依赖版本。
• 谁有权操作：域名注册商、DNS 服务商、服务器、数据库、对象存储、CDN、统计工具的管理入口与账号归属。
• 怎么证明没问题：抓取对比结果、状态码抽查、关键页面截图、表单与支付等功能的测试记录。

这四类信息缺一项，协作中就会有人凭记忆补位，返工往往发生在最不该出错的环节。

迁移前必须冻结的现状记录

现状记录的作用是提供对照基准，必须在动手改动之前完成，改完再补就失去了比对意义。

1. URL 全量清单：从站点地图、服务器访问日志、数据库文章表三条来源分别导出，合并去重。只依赖站点地图会漏掉未提交的页面，只依赖日志会漏掉长期无访问的页面。
2. 跳转与重写规则：记录服务器配置中已有的 301、302 规则和伪静态规则，注明每条规则的来源和添加原因。
3. 目录与文件结构：记录网站根目录、上传目录、缓存目录的实际路径，以及哪些目录由程序自动生成、哪些存放人工上传的内容。
4. 数据库快照说明：记录导出时间、字符集、表前缀、数据量级。多人协作时，这份说明要写明由谁导出、存放在哪里、校验值是多少。
5. 外部依赖清单：统计代码、字体库、地图接口、短信或邮件服务、第三方登录，逐项记录调用位置和配置项名称，不记录密钥明文。

判断现状记录是否合格，可以问一个具体问题：只拿这份记录，能否在另一台机器上还原出一个可访问的副本？能，就说明颗粒度够用。

权限、账号与责任人的交接记录

多人协作中最容易断链的不是技术，而是“谁能改”。建议用一张表把权限和责任人对应起来，而不是把密码散落在聊天记录里。

• 域名与 DNS：注册商账号归属、解析记录当前值、TTL 设置、修改权限在谁手上。
• 服务器与部署：登录方式、部署脚本位置、发布流程由谁执行、是否需要双人确认。
• 数据库与存储：读写账号、备份任务、备份保留周期、恢复演练由谁负责。
• 统计与验证工具：站点验证文件或验证记录的位置、数据查看权限、历史数据是否需要保留。

密码本身不要写进迁移文档，文档里只写“在哪个密码管理器的哪个条目下”，并确保接手人已被授权访问该条目。这样既满足交接需要，也避免文档扩散带来的风险。

迁移后的验证记录与判断标准

验证记录要能回答“凭什么说迁移成功”。建议按下面的顺序执行，并把每步结果记下来，而不是只看首页能不能打开。

1. 状态码抽查：从 URL 清单中按栏目分层抽样，检查是否返回 200；旧地址是否按预期返回 301 并指向新地址；不存在的地址是否返回 404 而不是 200。
2. 内容一致性：对比迁移前后关键页面的标题、正文首段、图片数量，确认没有出现空白页或模板错位。
3. 功能可用性：表单提交、搜索、登录、评论、支付等按业务重要性排序，逐项测试并记录测试账号和结果。
4. 抓取与索引状态：查看抓取工具对新环境的响应，确认没有因防护规则误拦正常抓取。这里只记录观察到的事实，不对收录速度作承诺。
5. 性能与错误日志：记录首屏响应时间的大致范围，检查服务器错误日志中是否出现迁移后才有的报错类型。

如果某项验证失败，记录中要区分“可能原因”和“已经定位的原因”。例如页面返回 500，可能原因包括数据库连接配置错误、文件权限不正确、依赖版本不匹配；只有在看到具体错误堆栈后，才能写成已定位的原因。把两者混写，会让接手人误以为问题已经查清。

回滚方案必须写成可执行的步骤

回滚不是一句“恢复备份”，而是一组有顺序、有判断条件的动作。记录中至少包含：触发回滚的判断条件、回滚顺序、每步的执行人、回滚后如何确认已恢复。

• 判断条件：例如关键页面持续返回错误、核心功能不可用、数据出现不可逆差异。写成可观察的现象，而不是“感觉不对”。
• 回滚顺序：一般先切回旧环境或旧解析，再处理数据，最后清理新环境，避免两边同时写入造成数据分叉。
• 确认方式：回滚后重新执行验证清单中的关键项，并记录执行时间和结果。

回滚方案要在迁移前实际演练一次。演练中暴露出的缺失记录，比上线后才发现要划算得多。

协作交付的最小检查项

把上面的内容压缩成一份可勾选的清单，交付前逐项确认：URL 清单是否合并了多个来源；跳转规则是否注明来源；数据库快照是否有校验值和存放位置；权限表是否写明责任人而非只写账号；验证记录是否包含失败项和未决项；回滚步骤是否有人实际走过一遍。

下一步建议做一次“空手交接”演练：找一位没有参与迁移的同事，只给他这份记录，让他在测试环境完成一次部署和验证。他卡住的地方，就是记录还需要补充的地方。