死链处理：改动前怎样保存原始状态 - 先留证据再动手
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /4f23288a69f8.html
📄
死链处理：改动前怎样保存原始状态 - 先留证据再动手
死链处理改动前保存原始状态，核心是留下三样可复查的东西：当前返回状态、当前跳转或内容、当前引用入口。做法是在任何删除、改链、加跳转之前，先把这些信息按可对照的格式记录下来，并让协作方确认同一份记录。这样改动后出现争议时，能判断是原本就存在的问题，还是本次操作引入的。
先观察：死链的原始状态包含哪些字段
一条死链在被处理前，至少有四类信息值得固定下来。缺了其中任何一类，复查时都可能说不清责任。
- 请求结果：实际返回的HTTP状态码，以及是否经过跳转、最终落到哪个地址。
- 响应内容：返回的是错误页、空白页，还是带200状态码但内容已失效的页面。
- 入口来源：哪些页面、导航、站点地图或外部链接指向它。这决定改动会影响谁。
- 时间与执行人：记录抓取或检查的时间点、使用的工具或命令、操作者。
这里要分清“可能原因”和“已经定位的原因”。返回404可能是页面被删，也可能是路径写错、大小写不一致、服务器配置拦截。记录阶段只写观察到的事实，不急着下结论，判断留到下一步。
判断：哪些状态必须原样留存，哪些可以只记摘要
并非所有信息都要整页保存。判断依据是改动后是否还需要用它来对照。
需要原样留存的：状态码、跳转链路、失效页面的关键内容片段、指向它的入口清单。这些是复查时的比对基准，改动后无法还原。
可以只记摘要的：页面正文的完整副本。如果页面内容量大，保存标题、主要段落和最后修改时间即可，但要注明摘要范围和截取时间。
一个可执行的检查项：对每条待处理死链，用同一工具在改动前连续检查两次，间隔几分钟。如果两次结果不一致，说明该地址本身不稳定，先别改，把两次结果都记下来再判断。适用条件是地址可能受缓存、CDN或临时故障影响；如果两次一致，才进入处理环节。
处理：改动前保存原始状态的具体步骤
按顺序执行，每步留下可交付的文件或记录，减少多人协作时的返工。
- 建立一份清单，每条死链一行，列出原始地址、状态码、跳转目标、入口来源、记录时间。
- 对每条地址保存改动前的响应快照。可以用命令行把响应头和状态码写入文本文件，例如
curl -I 原始地址，把输出原样粘贴进记录，不要只写“返回404”。 - 如果页面还有内容，保存标题和关键段落，并标注是全文还是摘要。
- 导出指向该地址的入口列表。站内入口可以从站点地图、导航配置或站内搜索日志中整理；外部入口如无法穷举，至少记录已发现的来源。
- 把清单和快照放在协作方可访问的同一位置，命名带日期，避免覆盖旧版本。
- 确认记录完成后再执行删除、改链或加跳转，改动本身单独记录，与原始状态分开存放。
这里涉及一个容易混淆的点：robots.txt的抓取限制不等于可靠的索引移除。如果死链处理涉及让搜索引擎不再访问某地址，保存原始状态时也要记录改动前robots.txt的相关内容，但不要把它当作索引移除的保证。站点地图同样不保证收录，记录入口来源时它只是线索之一，不是收录依据。
复查：改动后如何用原始状态验证结果
复查不是重新检查一遍，而是拿改动后的结果与改动前的记录逐项对照。
- 状态码是否按预期变化：原来404，现在是否返回301、410或200。
- 跳转链路是否只跳一次、是否落到目标页面，而不是跳到另一个失效地址。
- 入口来源是否都已处理，还是有页面仍指向原始地址。
- 记录中的时间、执行人、改动内容是否完整，其他人能否据此复现判断。
如果复查发现结果与预期不符，先回到原始状态记录，确认是改动没生效，还是原始状态本身与记录不一致。多人协作时，这一步能快速区分是执行问题还是记录问题。不同搜索引擎对状态码和跳转的处理方式需要分别核查，不要用一次检查结果推断所有搜索引擎的表现。
下一步：挑一条当前待处理的死链，按上面的清单先完成原始状态记录，再执行改动，用同一条记录做一次完整对照，确认这套流程在你的协作环境中能跑通。
