死链接检测：动态页面怎样确认可见内容
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /0e1147948ecf.html
📄
死链接检测：动态页面怎样确认可见内容
对动态页面做死链接检测，不能只看HTTP状态码。更可靠的做法是：先确认页面在浏览器渲染后实际显示了哪些链接，再把这些链接逐条请求并判断返回结果。状态码为200但内容为空、被脚本替换、被登录墙遮挡的链接，都不算真正可见。起点是保存一份渲染后的DOM快照，终点是得到“可见链接清单+每条链接的请求结果”两份可核对记录。
先明确交付结果：两份清单，而不是一个数字
动态页面的死链接检测，最终应交付两类可复查的资料。第一份是可见链接清单，记录链接文本、目标地址、所在页面、发现方式。第二份是请求结果清单，记录每条链接的状态码、最终跳转地址、响应耗时和判定结论。只给一个“发现N个死链”的数字，无法验证，也无法安排修复。判定结论至少分三类：可用、失效、需人工确认。需人工确认通常包括403、429、超时和需要登录才能访问的目标。
为什么不能直接抓HTML源码就下结论
动态页面的链接常由JavaScript在加载后插入，源码里可能只有占位容器。直接请求初始HTML，会漏掉渲染后才出现的链接，也会把模板中未启用的链接误判为可见。反过来，有些链接虽然存在于DOM中，但被CSS隐藏、被弹窗覆盖或位于折叠区域，用户实际看不到。因此需要区分三个层次：源码中存在的链接、渲染后DOM中的链接、视口内真正可点击的链接。死链接检测通常以第二层为基础，再按需要收缩到第三层。
这里要避免一个常见误判：<a>标签存在不等于链接可用。如果href为空、为#或由脚本在点击时才赋值，静态检查会得出错误结论。判断时应看渲染后的实际属性值。
可执行的检查步骤
- 用无头浏览器或开发者工具的“渲染后保存”功能，导出目标页面的DOM快照，确认脚本已执行完毕。
- 从快照中提取所有
<a>的href，过滤掉javascript:、mailto:、纯锚点和空值。 - 对同一域名下的链接，逐条发送请求，记录状态码与最终地址；跨域链接同样请求，但结论只作参考。
- 对返回200的链接，再检查响应正文是否包含有效内容，避免把空页面当成可用。
- 对403、429、超时和跳转到登录页的链接，标记为需人工确认，不直接判死。
- 把结果与上一次检测记录对比，区分新增失效和长期失效，便于安排修复优先级。
这套步骤适用于内容由前端框架渲染、链接异步加载的页面。如果页面是纯静态输出，可以直接抓源码，但仍建议保留渲染后复核这一步，用来发现脚本注入的链接。
判定标准与容易踩的坑
- 200不等于可用：软404页面会返回200，正文却是“内容不存在”。需结合正文关键词和页面标题判断。
- 301和302不等于失效：应记录最终地址，并检查跳转链是否过长或形成循环。
- robots.txt限制抓取不等于链接失效：被限制抓取的地址可能对用户正常可见，检测工具无法访问时应单独标注，不能直接判死。
- 登录态影响结果：需要登录才能访问的链接，在未登录检测中会返回跳转或403，应使用测试账号复测或明确标注。
- 站点地图不保证收录：检测范围应以页面实际可见链接为准，不能只依赖站点地图中的地址。
- HTTPS不保证目标可用：证书有效只说明传输层正常，目标资源仍可能返回404或空内容。
责任分工与验收方式
检测环节通常由技术SEO或前端负责，产出可见链接清单和请求结果清单。修复环节由内容或开发负责，按失效原因分类处理：地址写错就改地址，目标已删除就替换或移除链接，跳转链过长就更新为最终地址。验收时重新跑一遍相同范围的检测，确认原失效项已变为可用，且没有引入新的失效项。验收标准应写成可核对的条件，例如“原清单中标记为失效的链接，复测状态码为200且正文包含预期标题”。
假设某列表页渲染后有20条链接，首次检测发现3条返回404、2条返回403。修复后复测，3条404全部恢复为200，2条403经确认是权限设置，标注为需人工确认并保留记录。这就是一次可验收的闭环，而不是只看死链数量是否归零。
下一步：选一个动态页面，按上述步骤导出渲染后DOM，生成第一份可见链接清单，再对清单逐条请求，得到第一份请求结果记录。
