死链处理方法：改动前怎样保存原始状态，先做哪一步最稳
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /58d98c52333e.html
📄
死链处理方法：改动前怎样保存原始状态，先做哪一步最稳
处理死链之前，最该先做的一件事是给当前状态留一份可回退的快照：把涉及跳转、删除、替换的原始URL、HTTP状态码、页面标题、跳转目标、生效时间记录下来，并把文件或配置复制一份带日期的副本。这样做的目的不是留档好看，而是当批量改动误伤正常页面时，你能在几分钟内定位差异并还原，而不是凭记忆猜哪里改过。
准备阶段：先记录，再动手
时间和人手有限时，最容易省掉的就是记录，但这一步恰恰是后面省时间的。建议按下面顺序执行：
- 导出待处理URL清单。来源可以是服务器访问日志、站点地图、抓取工具结果或CMS后台的URL列表，关键是每条URL都要有唯一标识。
- 为每条URL补上当前状态字段：HTTP状态码、是否可访问、页面标题、跳转目标（如有）、最后修改时间。
- 把将要修改的文件或规则复制成带日期的备份，例如
redirects-2024-06-01.conf，不要覆盖原文件。 - 如果改动涉及数据库字段或CMS条目，先做一次完整导出，并确认导出文件能打开、条数对得上。
判断备份是否合格，可以做一个简单检查：随机抽三条URL，用备份文件或导出记录还原，看能否恢复成改动前的状态。如果还原不了，说明记录缺字段，需要补齐再继续。
实施阶段：小批量试跑，保留对照
不要一次改完整份清单。先挑10到20条代表性URL试跑，覆盖不同类型的死链：曾经404的、曾经301的、指向已删除页面的。试跑后立刻用同样的记录表复查状态码和目标地址，确认没有把正常页面误改成跳转。
这里要区分两种判断：如果试跑后出现异常，可能是规则写错、匹配顺序不对，也可能是缓存未刷新，不能只凭一次访问就断定原因，需要换浏览器、清缓存或直接请求源站再核对。确认试跑无误后，再按同样格式处理剩余URL，并保持每一批都有对应的改动记录。
验证阶段：对照原始快照逐项核对
验证的核心是拿改动后的状态和原始快照做对比，而不是只看“现在能不能打开”。可以按这个清单逐项检查：
- 原URL现在的状态码是否符合预期，是301、302、410还是404。
- 跳转目标是否是计划中的页面，且目标页面本身可访问、内容相关。
- 原本正常的URL有没有被误加入跳转或删除列表。
- 站内指向这些URL的内部链接是否同步更新，避免留下新的死链。
需要留意的是，robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录，所以验证时应以实际请求返回的状态为准，而不是以提交了某个文件为准。不同搜索引擎对跳转和移除的处理节奏不一样，需要分别核查，不能用一个平台的结果推断另一个平台。
维护阶段：让快照成为长期习惯
死链处理不是一次性任务。每次新增或修改跳转规则前，都重复“复制备份—记录原始状态—小批量试跑—对照验证”的流程，改动记录按日期归档，保留至少能覆盖一个完整排查周期的时长。这样下次再有人问“这条URL原来指向哪里”，你能直接查表回答，而不是重新抓一遍。
下一步建议：先建一份包含URL、原状态码、原跳转目标、改动日期、操作人五列的表格，把本次要处理的死链全部填进去，再开始改第一条规则。
