宁波网站开发 - 网站迁移应准备哪些记录：一份可核对的清单
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /57583d1dfe9b.html
📄
宁波网站开发 - 网站迁移应准备哪些记录：一份可核对的清单
网站迁移前要准备的记录，核心是三类：原站现状记录、迁移操作记录、迁移后验证记录。它们的作用不是走流程，而是当迁移后出现打不开、跳错页、收录异常或表单失效时，能快速判断问题出在哪一步。下面用一个假设例子展开，说明该记什么、怎么记、哪些记录最容易被漏掉。
假设例子：一次从旧主机迁到新主机的迁移
假设你负责一个宁波本地企业的展示站，原站在旧虚拟主机上，程序是常见的内容管理系统，有产品页、新闻页和在线留言表单。现在要换到新服务器，并顺便把域名解析从旧服务商转到新服务商。迁移后第二天，有客户反馈部分产品页打开是空白，新闻列表页正常。这时如果没有迁移前记录，就只能靠猜；如果有记录，排查会快很多。
下面按迁移前、迁移中、迁移后三个阶段列出应准备的记录。
迁移前：先把原站状态固定下来
迁移前记录的目标是留下一个“对照基准”。没有基准，迁移后无法判断某个现象是迁移造成的，还是原本就存在。
- 页面清单：用站点地图或爬取工具导出所有可访问网址，记录每个网址的标题和状态码。重点标记返回 200 的正常页、返回 301/302 的跳转页、返回 404 的死链。
- 跳转规则：记录原站已有的重定向关系，例如旧产品页跳到新分类页。迁移后这些规则若丢失，会直接产生大量 404。
- 表单与交互记录：记录留言表单提交后跳转到哪个页面、是否发邮件、是否写入数据库。迁移后表单失效往往不会立刻被发现。
- 域名与解析记录：记录当前域名解析到的 IP、使用的 CDN 或解析服务商、TTL 值。TTL 越短，切换生效越快。
- 数据库与文件备份记录：记录备份时间、备份方式、备份文件存放位置和校验值。不要只写“已备份”，要能证明备份可恢复。
- 环境信息：记录程序版本、依赖组件版本、服务器运行环境的关键配置。换环境后版本不一致，是页面空白或报错的常见原因之一。
常见错误是只备份了文件和数据库，却没有记录跳转规则和表单逻辑。结果数据都在，但用户访问路径断了。
迁移中：让每一步都可回溯
迁移过程要留下操作记录，目的是出问题时能定位到具体动作，而不是笼统地说“迁移过了”。
- 记录迁移开始和结束时间，精确到分钟。
- 记录每一步操作：上传文件、导入数据库、修改配置文件、切换解析、开启或关闭缓存。
- 每完成一步，立即访问几个代表性页面并记录结果，例如首页、一个产品页、一个新闻页、表单页。
- 修改配置前，先保存原配置内容，便于快速回退。
- 切换解析前，确认新环境已能通过临时地址正常访问，避免解析切过去后站点不可用。
这里有一个容易忽略的检查项：新旧环境的网址大小写、结尾斜杠、参数顺序是否一致。某些程序对 /Product/1 和 /product/1 的处理不同，迁移后可能表现为部分页面 404。
迁移后：用记录逐项验证，而不是凭感觉
迁移完成后，把迁移前记录拿出来逐项对照。验证不是看首页能打开就结束，而要覆盖访问、跳转、表单、收录入口几个方面。
- 状态码对照：抽查迁移前标记的正常页，确认仍返回 200；抽查原跳转页，确认跳转目标正确。
- 死链检查：对比迁移前后 404 数量。若迁移后明显增多，优先检查跳转规则和网址规则。
- 表单验证：实际提交一次留言，确认提示、跳转、邮件或数据写入符合迁移前记录。
- 站点地图与收录入口：确认站点地图可访问、内容为最新网址；确认搜索引擎能抓取到新页面。这里说的是网页搜索的抓取入口，与平台推荐、付费广告是不同体系，不要混在一起判断。
- 解析与证书：确认域名解析已指向新环境，访问协议与证书状态正常，避免出现混合内容警告。
判断结果时要注意：一个现象可能有多个原因。例如产品页空白，可能是数据库没导入完整，也可能是程序版本不兼容，还可能是缓存了旧页面。记录的价值在于帮你排除，而不是直接给出唯一答案。只有当你已经通过日志或对比定位到具体原因，才能说“已经定位”；否则只能列为“可能原因”。
哪些记录最值得长期保留
迁移结束后，至少保留以下内容一段时间：迁移前后网址对照表、跳转规则、备份文件及其校验值、迁移操作日志、验证结果记录。它们在下一次改版、换主机或排查历史收录问题时仍然有用。
下一步建议：先整理一份属于你自己站点的迁移记录模板，把上面清单里的项目逐条填上。哪怕只做一次小规模迁移，也按这个模板走一遍，之后再遇到访问异常，你手里就有可对照的证据，而不是从零开始猜。
