死链检测怎样确认配置实际生效：别把“扫到0条”当成配置已生效
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /b847c796c9c5.html
📄
死链检测怎样确认配置实际生效：别把“扫到0条”当成配置已生效
确认死链检测配置实际生效，不能只看工具界面显示“已完成”或“发现0条死链”。真正有效的判断是：用一条你已知的、可控的失效链接去触发检测，看它是否被记录、被归类、被通知，并且在下一次运行时结果一致。只有“已知坏链被稳定捕获”，才说明配置在按预期工作。
常见误解：扫描完成不等于规则生效
很多人把死链检测当成一次性任务：填好域名、点开始、等结果。只要跑完没报错，就认为配置已经生效。问题在于，检测结果受多个环节影响：
- 入口是否覆盖了目标页面，还是只扫了首页或站点地图里的部分URL；
- 超时、重试、并发设置是否让部分链接被跳过而非真正判定；
- 状态码判定规则是否把 404、410、软404、超时区分开；
- 白名单或忽略规则是否把本应报告的链接过滤掉了。
这些环节任意一个设置不当，都可能让结果看起来“干净”，但实际是漏报。所以“0条死链”有两种完全不同的解释：一种是站点确实没有死链，另一种是检测根本没覆盖到。两者必须区分。
用一条已知坏链做触发验证
最直接的生效确认方法，是人为制造一个可预期的失效目标，再观察检测是否命中。可以按下面步骤执行：
- 选一个测试页面，添加一条指向确定不存在路径的链接，例如
/this-page-should-404-test。确认该路径返回 404 或 410，而不是被重定向到首页。 - 运行死链检测，范围限定为包含该测试页面的最小集合，减少干扰。
- 检查结果中是否出现这条测试链接，并核对它报告的状态码、来源页面、发现时间是否与实际一致。
- 如果配置了通知或工单，确认这条测试死链是否触发了对应通知。
- 删除测试链接，再运行一次，确认该条目从结果中消失或转为已修复。
判断结果：如果测试链接被稳定捕获、状态码正确、来源可追溯，说明检测链路是通的。如果没被捕获，优先检查扫描范围、忽略规则和超时设置，而不是直接认定站点没有死链。
区分“可能原因”和“已经定位的原因”
检测没抓到测试链接时，不要立刻下结论。同一现象可能有多种解释：
- 可能原因：测试页面不在扫描范围内，比如被排除规则、robots.txt 限制或站点地图未包含。
- 可能原因：检测工具把超时或连接失败当作跳过，而非记为死链。
- 可能原因：链接是 JavaScript 渲染后才插入的，静态抓取看不到。
- 可能原因：白名单或忽略规则误匹配了测试路径。
要把它变成“已经定位的原因”，需要逐项排除：先确认扫描范围包含测试页，再确认超时阈值和重试次数，然后检查是否需要渲染模式，最后核对忽略规则。每排除一项，就缩小一次范围。多人协作时，把每一步的检查结果记录下来，比口头说“我这边是好的”更能减少返工。
需要特别注意：robots.txt 的抓取限制只影响爬虫是否访问，不等于可靠的索引移除；站点地图也不保证收录。所以即使站点地图里列了测试页，也不能假设检测一定覆盖到它，必须实际验证。
交付时该固定哪些检查项
多人协作场景下，配置生效的确认要能交接。建议在交付说明里固定以下检查项，让下一个人可以复现：
- 扫描入口清单：具体扫了哪些页面或目录，是否包含动态渲染；
- 状态码判定规则：哪些码算死链，哪些算软404，超时如何处理；
- 忽略与白名单：列出当前规则，说明为什么这样设；
- 触发验证记录：测试链接、运行时间、捕获结果、通知结果；
- 复跑一致性：连续两次运行，已知坏链是否都被稳定报告。
如果这些检查项齐全，接手的人不需要重新猜配置，也能独立判断检测是否真的在生效。反之，只交付一句“已配置完成”，后续很容易因为范围或规则不一致而返工。
下一步：做一次可复现的触发测试
现在就可以在测试环境加一条已知失效链接，按上面的步骤跑一次，把捕获结果和通知结果记录下来。确认它能被稳定识别后，再把这个测试路径和判定规则写进交付说明，作为后续每次调整配置后的回归检查。
