网站死链修复改版或迁移时应核对什么：交付前必须对齐的四类资料
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /ac9df0a778f1.html
📄
网站死链修复改版或迁移时应核对什么：交付前必须对齐的四类资料
改版或迁移时的死链修复，核对重点不是“有没有做301”，而是旧URL清单、跳转映射、生效证据、责任归属这四类资料能否同时交付。任何一项缺失，验收时都无法判断死链是否真正处理完，返工几乎不可避免。下面从交付结果倒推，说明每一类资料要核对到什么颗粒度。
先核对旧URL清单是否完整且可追溯
死链修复的起点是“旧站到底有哪些URL被访问过、被链接过、被收录过”。如果清单本身不完整，后面所有跳转都建立在错误基础上。核对时看三点：
- 来源是否覆盖多路：服务器访问日志、站点地图、站内链接抓取结果、外部反向链接数据，至少要有两路以上互相印证。只导出一份站点地图就当作全部旧URL，会漏掉大量历史页面。
- 是否标注状态：每条旧URL应标明当前返回码（200、301、404、410等）和是否仍有流量。只有明确“现在返回404且仍有访问”的条目，才是优先修复对象。
- 是否可核对到具体页面：清单里出现
/old-page-1这类无语义路径时，要能对应到原页面标题或截图，否则无法判断该跳到哪个新页面。
判断结果：如果旧URL清单无法回答“这条URL原来是什么内容”，说明资料不足以支撑跳转决策，需要先补齐再进入映射环节。
核对跳转映射是否一对一且有依据
映射表是改版迁移中最容易产生分歧的交付物。核对时不要只看数量，要看每一行的判断依据。
- 一对一优先：旧页面有直接对应的新页面时，必须精确指向该页，而不是统一跳首页。批量跳首页会把原本分散的入口价值集中到一处，用户在搜索结果里点进来也会觉得答非所问。
- 合并页面要说明归属：多个旧页面合并成一个新页面时，映射表要写明“哪些旧URL指向同一新URL”以及合并原因，方便后续复查是否漏掉内容。
- 确实无对应内容的处理：若旧页面内容已彻底下线，应返回410或保留一个说明页，而不是硬造一个不相关的新页面承接。这里要区分“暂时找不到对应页”和“确定不再提供该内容”，前者继续排查，后者才做移除处理。
假设示例：旧站有/service-a和/service-a-old两个页面，新站只保留/service-a。映射表应写成两行，都指向/service-a，并注明后者是历史版本。如果只写一行，验收时就无法确认另一个旧URL是否被遗漏。
核对生效证据而不是口头确认
“已经改好了”不能作为交付依据。改版迁移涉及服务器配置、CDN缓存、前端路由多层，任何一层没生效都会让跳转失效。核对时要拿到可复查的证据：
- 返回码实测记录：对旧URL逐条请求，记录实际返回的状态码和Location目标。注意区分“配置里写了301”和“访问时确实返回301”，两者可能因缓存或规则顺序不一致。
- 跳转链路是否只有一跳：旧URL→中间页→新URL这种两跳以上会拖慢响应，也容易在中间环节断掉。核对时确认最终落地页就是目标页。
- 大小写与斜杠变体：
/Page与/page、带斜杠与不带斜杠，在部分服务器上被视为不同URL。核对清单里要包含这些变体，避免只测了标准写法。
需要分清：robots.txt的抓取限制不等于可靠的索引移除，它只影响抓取，不保证旧URL从搜索结果消失；站点地图也不保证收录。因此生效证据应以实际请求返回结果为准，而不是以提交了某个文件为准。
核对责任分工与验收标准
多人协作时，死链修复最容易卡在“谁负责确认”。交付前应明确：
- 谁提供旧URL清单：通常是熟悉原站结构的人或能导出日志的运维方。
- 谁制定映射规则：内容或产品负责人决定旧页面内容归属，技术人员只负责实现，不替内容做判断。
- 谁执行配置：服务器或CDN规则的修改人，需在变更记录里留下时间与范围。
- 谁做最终验收：验收人应按清单逐条抽查，而非只看汇总数字。抽查比例和通过标准要事先写进交付说明。
判断结果：如果映射表里出现“待定”“稍后确认”这类状态，说明该条目尚未达到可交付条件，不应计入完成量。
下一步：先冻结旧URL清单版本
在开始配置跳转之前，把旧URL清单定版并标注版本号或日期，后续所有映射、实测、验收都基于同一版本进行。清单一旦冻结，任何新增条目都要走变更记录，这样多人协作时才能避免“我改的是旧版清单”这类返工。
