死链检测：静态响应与脚本渲染结果不同时怎样定位差异
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /4e0754aa8a4b.html
📄
死链检测：静态响应与脚本渲染结果不同时怎样定位差异
先给结论：当静态响应显示 200 或 404，而脚本渲染后结果不同，第一步不是判定谁对谁错，而是确认差异发生在哪一层——是服务端返回的状态码、渲染后页面内容，还是链接本身只存在于脚本中。缺少完整日志和权限时，仍可用单页请求、禁用脚本对比和链接来源归类三个最小动作缩小范围，但不能据此断定全站死链数量或索引状态。
先分清两种差异：状态码差异与内容差异
静态响应与脚本渲染结果不同，通常落在两类。第一类是状态码差异：直接请求 URL 得到 200，但脚本执行后页面显示“不存在”或跳转；反过来也常见，静态返回 404，脚本接管路由后渲染出正常内容。第二类是内容差异：状态码一致，但静态 HTML 里没有目标链接，脚本执行后才插入链接。
区分这两类的依据是：差异是否改变 HTTP 状态码。状态码不同，影响抓取和索引判断；仅内容不同，影响的是链接发现和可抓取性。两种情况下，后续动作完全不同，所以不要混在一起处理。
条件一：有服务端访问权限时的定位选择
如果能拿到访问日志或能直接请求源站，优先做状态码对照。对同一 URL 分别发起不带脚本的请求和带脚本的请求，记录返回码、响应头和最终 URL。若两者状态码不同，说明差异来自服务端路由、重定向规则或前端路由接管。
此时可执行的动作是：固定一个 URL，用 curl -I 观察响应头，再在浏览器中禁用 JavaScript 重新加载，比较地址栏和页面主体。结果如何影响下一步——如果禁用脚本后返回 404，而启用脚本后渲染正常，说明该链接依赖客户端路由，抓取工具可能看不到，需要检查是否存在服务端可访问的等价 URL；如果禁用脚本后正常、启用后反而报错，则要排查脚本请求的接口是否返回了错误状态。
例外：单页应用常把路由交给前端，服务端对所有路径都返回 200。这种情况下静态响应正常不代表链接有效，必须结合渲染后内容判断。
条件二：没有权限、只能从外部观察时的最小动作
缺少日志和后台权限时，仍可做三件事：一是对可疑 URL 单独请求，记录状态码和响应体是否包含“未找到”等文本；二是禁用脚本后重新加载，看链接是否仍然存在；三是查看该链接出现在哪些页面，判断它是模板级链接还是单页链接。
这些动作能得到的结论有限。请求返回 200 不能证明链接可用，因为可能是软 404；返回 404 也不能证明全站同类链接都失效，除非确认它们共用同一模板或同一数据源。此时可先标记“待确认”，而不是直接批量提交移除。
需要提醒的是，robots.txt 的抓取限制不等于可靠的索引移除。即使某条链接被 robots 屏蔽，也不代表它已从索引中消失，因此不能把抓取限制当作死链处理结果。
用链接来源归类，避免把个别现象放大成全站问题
定位差异后，下一步是按来源归类，而不是按数量下结论。可把可疑链接分为三类：导航或模板中的固定链接、内容正文中的编辑链接、脚本动态插入的链接。
- 固定链接出问题，通常影响一批页面，优先检查模板和路由配置。
- 编辑链接出问题，多为单条内容，逐条核对即可。
- 脚本插入的链接，需要确认渲染后是否生成可抓取的 <a> 标签，还是仅绑定点击事件。
归类后，动作才有方向：模板问题改一处可覆盖多页；单条链接改内容即可；脚本链接则需要评估是否补充服务端可访问的静态链接。站点地图不保证收录，所以即使把修好的链接放进站点地图，也不能作为修复完成的唯一证据。
假设例子：一次对照如何改变处理顺序
假设某页面静态请求返回 200，禁用脚本后页面正常，启用脚本后正文区域显示“内容不存在”。单看静态响应会误判为正常。按上述步骤，先记录两种条件下的状态码和页面文本，再查看脚本请求的接口返回。若接口返回 404，而页面外壳仍为 200，则问题在接口层，而不是链接本身。此时下一步应修接口或改由服务端渲染该内容，而不是把该 URL 当作死链删除。这个例子说明：状态码一致时，差异可能藏在内容来源，需要继续追一层。
反过来，若静态返回 404、脚本渲染出完整页面，则要确认该页面是否依赖客户端路由。若抓取工具不执行脚本，这条链接可能长期不可发现。此时可考虑提供静态可访问的等价入口，并单独验证其响应，而不是仅凭浏览器可见就认为修复完成。HTTPS 不保证安全无漏洞或排名，所以协议正常也不能替代对状态码和内容的核对。
