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

网站建设策划书_迁移前应准备哪些记录与验收清单

网站迁移前应准备的记录，核心是让接手人能独立完成验收：一份可核对的资产与配置清单、一份任务与责任表、一份验证结果记录。判断记录是否合格的标准很简单——离开原负责人后，新负责人能否仅凭这些记录确认“旧站内容已全部到位、新站可正常访问、出问题知道回退到哪一步”。如果做不到，记录就是缺项的。

从交付结果倒推：迁移记录要覆盖四类对象

不要从“我做了哪些操作”出发写记录，而要从“验收时要看到什么”倒推。迁移的交付结果通常有四类对象，每类都要有对应记录。

• 内容资产：页面、文章、图片、附件、视频、下载文件的迁移前后对照，记录总数、已迁移数、遗漏项及原因。
• 配置与结构：域名解析记录、URL 结构、栏目层级、重定向规则、robots 文件、站点地图。
• 功能与数据：表单、搜索、评论、会员、订单等模块的可用状态，以及数据库或用户数据的迁移范围。
• 责任与回退：每一步由谁执行、谁验收，出现异常时回退到哪个版本、由谁决策。

这四类对应的是验收时最常出问题的环节：内容漏迁、链接失效、功能失灵、出事无人负责。记录的作用就是让这四类问题在验收前就能被查出来。

资产与配置清单：写清“迁移前是什么样”

迁移记录最容易缺的不是操作步骤，而是迁移前的基线。没有基线，验收时无法判断“新站少了东西”还是“旧站本来就没有”。

建议在动手前先固定一份基线快照，至少包含：

1. 旧站可访问页面总数与栏目清单，注明统计口径和统计时间。
2. 域名与解析记录：A 记录、CNAME、MX、TXT 等逐条列出，标明用途。
3. URL 规则：动态参数、伪静态、大小写与结尾斜杠的处理方式。
4. 已生效的重定向与 canonical 设置，注明哪些是历史遗留。
5. 外部依赖：统计代码、第三方表单、支付或客服组件的接入方式。

基线快照要带日期。验收时用同一口径重新统计，数量与规则对不上，就是需要追问的差异点。

任务、责任与验收记录：让每一步可追溯

把迁移拆成可勾选的任务，每条任务写清三件事：执行人、验收人、验收依据。验收依据要具体到可操作，例如“随机抽取 20 个旧 URL，逐个访问，确认返回 200 或预期的 301 目标页”，而不是“检查链接是否正常”。

可以用一张表记录，字段建议为：任务项、执行人、完成时间、验收人、验收结果、异常备注。验收结果只填“通过/不通过/待确认”三种，避免模糊描述。对不通过的项，备注里写清现象与复现步骤，方便后续定位。

这里要区分“可能原因”和“已定位的原因”。例如某个页面打不开，记录里应写“访问 /old-page 返回 404”，而不是直接写“重定向没配好”。前者是现象，后者是判断，判断需要验证后才能写进结论。

可执行的检查项与判断结果

下面是一组可以直接执行的检查项，以及每项对应的判断结果。假设旧站有 300 个页面，迁移到新结构后应逐项核对。

• 页面覆盖：按旧站地图逐条访问新站对应地址。结果应为全部可达；出现 404 的条目单独列出，确认是遗漏还是有意下线。
• 重定向：抽取旧 URL 中带参数、带中文、带大写字母的样本各若干。结果应为跳转到内容对应的新地址，而不是统一跳首页。
• 资源加载：打开页面后检查图片、样式、脚本是否加载成功。结果应为无控制台报错、无空白图。
• 表单与数据：提交一次测试表单，确认能收到。结果应为数据落到预期位置，且旧数据仍可查询。
• 回退可用：确认旧站或旧版本仍可访问、备份可恢复。结果应为在约定时间内能切回，且切换步骤有人能执行。

这些检查适用条件是：迁移范围已明确、旧站仍可访问。如果旧站已经下线，则基线快照必须在迁移前完成，否则部分检查无法执行，此时应在记录中明确标注“无法核验项”及其影响。

交接与验收的下一步

把上述基线快照、任务责任表、检查结果三份记录合并成一份迁移档案，在验收会上逐项过一遍。任何“待确认”项都要指定责任人和确认时间，确认完成后再签署验收。迁移档案应随网站一起交接，而不是留在原负责人手里。