网站死链检测:动态页面怎样确认可见内容

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

网站死链检测:动态页面怎样确认可见内容

动态页面的可见内容不能只看浏览器地址栏返回的HTML源码,因为很多内容由JavaScript在页面加载后写入DOM。确认死链时,应把“服务器返回状态码”和“用户实际看到的链接”分开判断:先看原始响应,再渲染页面,最后比对渲染后出现的链接是否可访问。对第一次处理这个问题的人来说,起点是明确检查对象,下一步是选一种可重复的检测流程。

先分清三种“链接”状态

动态页面里同一个链接可能以三种形态存在,判断结果完全不同。第一种是原始HTML中已经写出的<a href="...">;第二种是JavaScript执行后插入DOM的链接;第三种是用户点击后由前端路由或接口请求触发的跳转。死链检测要覆盖的是前两种,因为第三种已经进入交互行为,通常需要单独做端到端测试。

如果只检查原始HTML,动态页面很可能被误判为“没有链接”或“链接全部正常”;如果只检查渲染后DOM,又可能把接口临时失败当成死链。因此,确认可见内容的核心是:以渲染后用户能看到的链接为准,再对每个链接单独请求验证。

用渲染快照确认“用户能看到什么”

判断动态页面可见内容,最直接的方法是获取渲染后的DOM快照。可以在浏览器开发者工具中执行一段脚本,收集当前页面上所有可见的链接文本和地址:

Array.from(document.querySelectorAll('a[href]')).filter(a => a.offsetParent !== null).map(a => ({text: a.innerText.trim(), href: a.href}))

这段代码只保留有布局占位、用户可能看到的链接。执行后得到一份清单,再逐个请求这些地址,记录HTTP状态码和最终跳转地址。适用条件是页面已经加载完成;如果页面有懒加载或“加载更多”按钮,需要先触发这些操作再执行。判断结果是:状态码为404或410的链接可视为死链候选,状态码为200但内容为空或提示“不存在”的页面,需要结合页面正文进一步确认。

比较两种检测路径的代价

动态页面死链检测通常有两条路径,选择取决于页面规模和更新频率。

如果页面数量少、链接由前端框架统一生成,直接选浏览器自动化更省心;如果站点有大量静态文章页,只有列表页和详情页的部分模块是动态的,混合路径更划算。判断依据不是工具品牌,而是页面中链接的出现位置:链接写在原始HTML里,就不必渲染;链接只在DOM操作后出现,就必须渲染。

执行检查时容易忽略的条件

确认可见内容时,有几个条件会直接影响结果。第一,登录态和权限:未登录时看不到的链接,不代表登录后不存在死链,需要分别检测。第二,懒加载:滚动到页面底部再收集链接,否则会漏掉折叠区域。第三,重定向:状态码200但经过多次跳转的链接,应记录最终地址,判断是否跳到了无关页面。第四,robots.txt限制:它只约束抓取行为,不等于链接已经失效,也不能作为索引移除的依据;检测死链时应以实际请求结果为准。第五,站点地图和HTTPS都不能保证链接有效,前者只是提交线索,后者只说明传输层加密,与目标页面是否存在无关。

一个可执行的检查顺序是:先列出需要检测的页面地址;对每个页面等待渲染完成并滚动到底部;收集可见链接;对每个链接发起请求并记录状态码、最终地址和响应时间;把404、410以及跳转到错误页的链接单独输出。若同一链接在不同页面重复出现,只需验证一次,但要在结果中标注它出现在哪些页面。

从检测结果到下一步处理

得到死链清单后,先按来源分类:站内链接指向已删除页面、站外链接指向失效资源、参数错误导致的路由未匹配。站内死链优先修复或设置正确的重定向;站外死链根据是否仍需要引用决定替换或移除。修复后重新跑一遍同一份页面清单,确认渲染后可见链接中不再出现404或410。对第一次接触这个问题的人,下一步就是选一个页面,用上面的脚本收集可见链接,再逐个请求验证,先跑通一个小样本,再决定是否扩展到全站。

图1 图2

nginx