死链修复工具，页面内容相同但响应头不同会影响哪些判断
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /cf9898545ebc.html
📄
死链修复工具，页面内容相同但响应头不同会影响哪些判断
结论有条件：如果同一份可见内容同时存在 200、301、404 或 410 等不同响应头，死链修复工具不能只凭“页面看起来一样”判断链接是否已修好。响应头决定爬虫和工具把该 URL 归入哪一类状态；内容相同只说明渲染结果相似，不说明该地址仍可访问、仍应被抓取，或旧地址已经完成迁移。只有当响应头与内容意图一致时，修复判断才成立。
先分清：工具看到的是内容，还是状态
死链修复工具通常要同时读取两样东西：一是 URL 返回的状态码和重定向链，二是页面渲染后的可见文本。两者不一致时，工具可能给出相反结论。例如旧文章地址返回 301 指向新地址，新地址返回 200 且正文相同，这属于正常迁移；但如果旧地址直接返回 200，正文又与新地址完全一样，工具会认为两个 URL 都可用，内链和外链可能继续指向旧地址，修复动作就没有真正收敛。
更隐蔽的情况是：一个地址返回 404，但页面模板仍渲染出完整导航、页脚和推荐位，肉眼看上去“内容很多”。此时若把 404 当成可访问页面保留，死链修复工具会漏掉真正的失效状态；反过来，若把返回 200 的重复内容页直接删除，又可能切断仍有价值的入口。判断依据不是页面像不像，而是响应头是否与链接意图匹配。
两种做法都成立，但适用条件不同
做法一：保留内容相同、响应头不同的多个 URL，只修正内链指向。适用于这些 URL 各自有独立外链、且短期内不能合并的场景。代价是重复内容可能分散信号，工具每次扫描都要重复判断，后续维护成本高。
做法二：把旧 URL 统一 301 到主 URL，再让死链修复工具复扫。适用于旧地址没有独立价值、迁移目标明确、且服务器能稳定返回 301 的场景。代价是重定向链过长会拖慢抓取，若中间某一跳返回 404 或 410，工具会把整条链判为异常。
选择条件可以压缩成一句：看旧 URL 是否还有独立入口价值。有，就先保留并修正内链；没有，就做 301 收敛。两种做法都不该在响应头未核实前执行。
一个反例会让上面的结论失效
假设某页面返回 200，正文与目标页相同，但响应头里带有 X-Robots-Tag: noindex。这时“内容相同”不再支持“两个地址都可保留”的判断，因为该 URL 被明确要求不进入索引。死链修复工具若只比较正文，会把它当成正常页面；若只看到 noindex，又可能误判为需要删除。正确动作是先确认这个响应头是临时测试、误配置，还是迁移期的有意设置，再决定保留、移除或改为 301。没有这一步，任何修复结论都可能被一个响应头推翻。
下一步动作：用响应头分组，而不是用页面相似度分组
可以把待处理 URL 按响应头分成三组：
- 200 组：检查是否存在重复正文、canonical 指向何处、是否带 noindex。若正文相同且 canonical 指向主 URL，可保留但不再新增内链。
- 3xx 组：记录重定向链长度和最终状态码。最终为 200 才算闭环；最终为 404 或 410 的，要继续修目标地址。
- 4xx/5xx 组：区分 404、410 与 5xx。404 和 410 可进入移除或替换流程；5xx 应先排查服务端，不要直接当作死链删除。
执行后，用同一批 URL 复扫一次，对比分组是否变化。如果某个 URL 从 404 变成 301、最终落到 200，说明修复生效；如果它仍返回 404 但页面模板有内容，说明工具或判断口径仍把“可见内容”当成了“可访问状态”，需要回到响应头重新核对。这个动作的结果会直接决定下一步是继续修链接、改服务器配置，还是停止对该 URL 的删除操作。
