📍 WDQWDWQD987AAAAA:216.73.217.38
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /e77278cc08e6.html
📄

死链检测改动前怎样保存原始状态 - 先留证据再动手

死链检测改动前保存原始状态，核心是先把“改动前的证据”固定下来：导出当前链接清单与状态码、保存页面快照或响应头、记录检测时间与工具参数、留存服务器或CMS的配置备份，再开始修复或删除。这样做的目的不是留档好看，而是当改动后出现流量波动、收录变化或误删争议时，能对照出究竟是哪一条链接、哪一次操作造成的影响。

先明确改动会动到什么，再决定存什么

死链检测后的常见改动有三类，每类需要保存的原始状态不同：

• 删除或替换站内链接：需要保存改动前的页面HTML、该链接所在位置（导航、正文、页脚）、链接指向的URL。
• 设置301/302跳转：需要保存原URL、原状态码、原响应头（尤其是Location）、跳转目标URL。
• 在robots.txt或服务器层屏蔽：需要保存改动前的robots.txt全文、屏蔽规则、生效时间。注意robots.txt的抓取限制不等于可靠的索引移除，它只影响抓取，不能保证页面从索引中消失。

如果只保存一份“死链列表”而不保存上述上下文，改动后就无法判断某条链接是本来就有问题，还是这次操作引入的。

一份可执行的原始状态保存清单

按下面顺序执行，每一步都产出可核对的文件：

1. 导出全量URL与状态码：用爬虫工具或curl -I批量获取，保存为CSV，字段至少包含URL、HTTP状态码、检测时间。检测时间必须精确到分钟，因为状态码会随服务器调整变化。
2. 保存关键页面的原始HTML：对含死链的页面，用浏览器“另存为”或curl保存完整HTML，文件名带日期。这是判断“链接原本指向哪里”的唯一可靠依据。
3. 记录响应头：对每个待改动的URL，保存完整响应头。命令示例：curl -I https://example.com/old-page，把输出重定向到文件。响应头里的Location、Cache-Control、X-Robots-Tag都是后续排查的关键。
4. 备份配置文件：robots.txt、.htaccess、Nginx配置、CMS的重定向插件数据，改动前各复制一份，文件名标注版本和日期。
5. 截图或存档页面：对视觉呈现重要的页面，用浏览器截图或网页存档工具保存，防止改动后无法还原原始版式。

假设某页面正文里有一条指向旧活动页的链接已返回404。改动前应保存：该页面HTML、该链接的完整URL、该URL的404响应头、检测时间。改动后若发现该活动页其实还有搜索流量，就能凭这些记录决定是恢复链接还是改为301，而不是凭印象判断。

保存后怎样验收，判断资料是否够用

验收标准是：不看现在的网站，仅凭保存的文件，能否还原改动前的状态。具体检查项：

• URL清单能否覆盖所有待改动链接，有无遗漏。
• 每条链接是否有对应的状态码和检测时间。
• 关键页面是否有原始HTML，能否定位链接在页面中的位置。
• 配置文件备份是否可读、可回滚。
• 文件命名是否包含日期和版本，能否区分多次改动。

如果某项缺失，先补采再动手。例如只存了状态码没存HTML，改动后就说不清链接原本的锚文本是什么，也就无法判断替换后的锚文本是否改变了页面主题相关性。

容易踩的三个坑

只存死链列表，不存正常链接：改动可能误伤正常链接，原始清单里必须包含全量URL，而不只是404的那些。

用“最新检测结果”覆盖旧记录：每次检测另存新文件，不要覆盖。状态码会变，覆盖后就失去了时间线。

把站点地图当成状态依据：站点地图只表示“希望被抓取”，不保证收录，也不反映链接是否有效。判断死链必须看实际HTTP响应，不能只看站点地图里有没有这个URL。

另外，HTTPS不保证页面安全无漏洞，也不保证排名，它只是保存原始状态时的一个协议字段，不要把它当成质量判据。

下一步

先按上面的清单跑一遍导出和备份，确认文件齐全后，再执行死链修复。改动完成后，用同一套检测参数再跑一次，把新旧两份状态码清单逐行对比，差异行就是这次改动的实际影响范围。