网站死链查询改版或迁移时应核对什么？交付前先定四份清单
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /dec502592119.html
📄
网站死链查询改版或迁移时应核对什么？交付前先定四份清单
改版或迁移时的网站死链查询，核对对象不是“有没有死链”这一句话，而是四份可交付的清单：旧URL与新URL的对应关系、返回状态与跳转目标、内链与入口的更新结果、以及验收时能复现的检查记录。只有这四份都能交给协作者复核，才算把死链问题交付清楚，否则上线后仍会反复返工。
先定交付结果，再倒推要收集的资料
多人协作最容易出问题的地方，是每个人对“查完了”的理解不同。建议在动手前先约定交付物，通常包括：
- 一份旧站URL全量清单，标明每个URL的最终去向：保留、301跳转、410删除或暂时保留。
- 一份跳转映射表，包含旧URL、新URL、跳转类型、负责人。
- 一份检查记录，写明用什么方式抓取、抓取时间、样本范围、发现的异常。
- 一份待办清单，列出尚未处理或需要业务方确认的URL。
资料齐了，任务和责任才能分得清。缺少旧URL清单，后面所有核对都会变成凭印象补漏。
核对状态码与跳转链，而不是只看能否打开
浏览器里能打开，不代表对搜索引擎友好。核对时要区分几种情况：
- 301：旧地址永久指向新地址，适合已确定替换关系的页面。
- 302或307：临时跳转，改版迁移中大量使用会让旧URL的权重归属变得模糊，应确认是否有意为之。
- 404：页面确实不存在。若是重要入口，应补跳转；若是废弃内容，可考虑410。
- 跳转链：A跳B、B再跳C，属于链条过长，应尽量改成A直接跳C。
- 跳回旧站或跳错页：常见于映射表填写错误，需要逐条比对。
执行时可以用抓取工具跑一遍旧URL清单，导出状态码和最终落地URL，再和映射表做比对。判断标准很简单：映射表里写的目标，必须和实际抓到的最终URL一致；不一致的单独列出来交给对应负责人。
把内链、导航和站点地图一起纳入核对
外链指向旧URL往往无法全部控制，但站内入口可以。迁移后要检查：
- 导航、面包屑、页脚是否仍指向旧地址。
- 文章正文里的站内链接是否已替换为新地址。
- 站点地图是否只包含当前有效、希望被收录的URL。站点地图不保证收录，它只是提交线索，不能当作死链已清理的证明。
- robots.txt 是否误屏蔽了新目录。抓取限制不等于可靠的索引移除，被屏蔽的URL仍可能因外部链接出现在结果里，所以删除页面要用状态码处理，而不是只靠robots.txt。
这一步的责任通常落在内容编辑和前端两方：编辑负责正文链接，前端负责模板和导航。验收时各查各的部分，避免互相以为对方已经改过。
验收要有可复现的检查项
交付前建议做一次抽样加全量结合的验收，检查项可以固定为：
- 随机抽20条旧URL，手动访问，确认落地页与映射表一致。
- 全量抓取旧URL清单，统计非200且非301的数量，逐条给出处理结论。
- 检查跳转是否超过两跳，超过的标记为待优化。
- 确认新站内不存在指向旧域名的链接。
- 把抓取结果、异常清单和负责人确认记录一起归档。
假设某次迁移有5000条旧URL，其中300条映射表未填写。这300条不能默认删除，也不能默认保留，必须由业务方逐条判断是补跳转还是允许404。判断依据是页面是否有外部链接、是否有搜索流量、是否是用户收藏入口。这些信息拿不到时，保守做法是先保留并跳转到最相关的上级页面，再逐步清理。
协作中最容易返工的三件事
一是映射表没有版本，几个人同时改，最后不知道以谁为准。二是把“抓取通过”当成“收录正常”，实际上HTTPS不保证安全无漏洞或排名，抓取正常也不等于索引正常。三是只查首页和栏目页，漏掉分页、筛选参数和历史专题页，这些恰恰是死链高发区。
下一步可以做的，是把旧URL清单、映射表和检查记录合并成一份交付文档，指定一名负责人统一维护版本，其他人只提交修改建议，不再各自保存副本。这样上线后的核对才有唯一依据。
