网站建设策划网站迁移应准备哪些记录：从一份假设的迁移清单讲起
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /9dcc78deb624.html
📄
网站建设策划网站迁移应准备哪些记录：从一份假设的迁移清单讲起
网站迁移前最该准备的是一份可核对的记录清单，而不是只备份数据库和文件。它至少要覆盖迁移范围、原环境信息、URL对应关系、重定向规则、DNS与证书状态、验证结果和回滚方案。下面用一个假设例子说明这些记录怎么用，以及哪些环节最容易漏。
假设一次从旧目录迁到新域名的迁移
假设某站点原来放在/old/目录下，现在要迁到独立域名并调整部分栏目。策划阶段先写一张迁移记录表，每一行对应一个页面或一类资源。至少记录：原URL、新URL、页面类型、是否保留、重定向目标、负责人、验证时间。这样做的目的不是形式化，而是让迁移前后可以逐条比对。
常见错误是只记录首页和新栏目，忽略分页、标签页、附件、图片和表单提交地址。迁移完成后，用户从搜索结果进入旧链接会落到404，或者图片仍指向旧域名。判断方法很简单：随机抽取旧站地图中的若干URL，逐个访问，看是否到达内容对应的新地址，而不是统一跳到首页。
迁移前必须留存的六类记录
- 原环境记录：服务器类型、程序版本、数据库版本、伪静态规则、已安装扩展及其配置。这些信息决定新环境能否复现原行为。
- 内容与资源清单：页面、文章、分类、标签、媒体文件、下载文件的数量和存放路径。数量对不上时，先查清差异再继续。
- URL映射表：旧地址到新地址的一一对应关系。能一对一就不要批量跳首页，否则用户和搜索引擎都难以判断新页面主题。
- 重定向规则记录：规则写在哪个配置文件、匹配顺序、是否区分大小写、是否带参数。规则冲突时，先匹配到的会生效。
- 域名与证书记录：DNS解析记录、TTL、证书覆盖的域名、到期时间、是否同时保留带www和不带www的访问。
- 验证与回滚记录：迁移后要检查的页面清单、检查时间、发现的问题、回滚触发条件和回滚步骤。
重定向与DNS记录要分开核对
重定向解决的是“旧页面地址指向哪里”，DNS解决的是“域名解析到哪台服务器”。两者混在一起排查，容易把解析生效问题误判为重定向错误。建议先确认新域名已解析到新服务器，再测试单条重定向是否按预期跳转。
检查项可以这样设：用不带参数的旧URL访问一次，再用带参数的旧URL访问一次；观察最终地址、返回状态和页面内容。如果带参数时跳到错误页面，说明规则可能没有保留查询字符串。此时应回到重定向规则记录，确认匹配条件和目标地址写法。
迁移后按记录逐项验证
验证不是只看首页能否打开。按迁移记录表抽取样本：首页、栏目页、内容页、分页、搜索页、表单页、图片地址各若干条。每条记录填写实际结果，而不是只写“正常”。发现异常时，先判断是内容未同步、重定向未生效，还是权限或证书问题，再决定修复还是回滚。
假设例子中，如果发现旧文章页全部跳到新首页，不能直接断定重定向规则写错，也可能是映射表本身只写了首页目标。先查映射表，再查规则文件，最后查服务器配置是否缓存了旧规则。区分“可能原因”和“已经定位的原因”，能避免反复改错地方。
把记录变成可执行的迁移步骤
- 冻结旧站内容变更，导出完整数据库和文件，记录导出时间。
- 整理URL映射表，标记必须保留、可以合并和确定删除的地址。
- 在新环境导入数据，逐项核对内容数量与媒体文件。
- 配置重定向并逐条测试，保留测试结果。
- 切换DNS前降低TTL，切换后观察解析是否指向新服务器。
- 按验证清单抽查，确认无误后再处理旧环境。
下一步建议先做一张只含旧URL、新URL和验证结果的表，把最关键的二十个页面填进去。这张表能跑通，再扩展迁移范围，比一次性全量切换更容易定位问题。
