死链检查，静态响应与脚本渲染结果不同时怎样定位差异
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /4b39d371f47a.html
📄
死链检查，静态响应与脚本渲染结果不同时怎样定位差异
先给结论：静态响应返回 404 而脚本渲染后页面有内容，说明死链判断的差异来自“谁在请求、请求到了哪一层”。定位方法是把同一条 URL 分别用不执行脚本的请求和浏览器执行脚本的请求各取一次结果，比较状态码、响应体长度和最终落地 URL 三项。三项都一致才算同一种结果；只要有一项不同，就要先确定差异发生在服务端、跳转层还是客户端脚本，再决定这条链接按死链处理还是按可用处理。
先明确前提：什么时候必须区分这两种结果
假设有一个内容站点，早期用服务端渲染输出文章页，后来前端改成先返回一个壳页面，再由脚本请求接口填充正文。改版前后，同一批内链的静态响应从 200 变成 404，但用浏览器打开仍能看到完整文章。这个情境是假设的，用来演示判断顺序，不是某个真实项目的记录。
在这个前提下，是否要把这些 URL 当死链，取决于两件事：一是访问者是否执行脚本，二是你希望被谁看到。搜索引擎爬虫、社交平台的预览抓取、部分监控工具通常只取静态响应；真实用户浏览器一般会执行脚本。如果站点的主要流量来自前者，静态 404 就是实际损失；如果只服务已登录且必然执行脚本的用户，影响范围会小得多，但仍要单独核查每个抓取方的行为。
判断条件可以简化成一句：静态响应决定“能不能被发现”，脚本渲染决定“用户能不能看到”。两者不一致时，先按更保守的一方处理。
用三项对比把差异钉在具体环节
不要只看状态码，也不要只看页面是否“看起来正常”。对同一条 URL 做两组请求，记录下面三项：
- 状态码：静态请求返回 200、301、404 还是 410。这是最容易被监控工具捕获的信号。
- 响应体长度与首屏文本：静态响应里是否已经包含标题、正文关键词或“页面不存在”的提示。长度接近 0 或只有脚本标签，说明内容不在静态层。
- 最终落地 URL：静态请求是否被 301/302 带到别处，脚本执行后地址栏是否又发生一次客户端跳转。两次跳转目标不同，是差异的常见来源。
三项组合能区分几种原因：静态 404、脚本 200，通常是路由或接口鉴权把静态请求挡在外面；静态 200、脚本 404，通常是脚本内部请求接口失败后主动渲染了错误页；两边都 200 但落地 URL 不同，通常是跳转规则在服务端和客户端各写了一套。
实际动作：把这三项记录成一行数据，再对同一条链接用不同 User-Agent 各取一次。如果只有某个 User-Agent 触发 404，差异就落在服务端的分支逻辑上，下一步应去查该分支的匹配规则，而不是改前端脚本。这一步的结果直接决定后续排查方向，避免在错误的一层反复修改。
区分“抓取受限”与“真的不存在”
静态响应异常时，容易把几种情况混在一起。需要分开看：
- robots.txt 限制：它只约束抓取行为，不等于把页面从索引中移除，也不代表页面不存在。被限制抓取的 URL 仍可能因外链被收录。
- 站点地图：提交站点地图不保证收录，它只是提供候选 URL，不能用来证明某条链接有效。
- 鉴权或地域分支：未登录请求被重定向到登录页，状态码可能是 200 或 302，但内容并非目标页面。这类结果不能当成有效页，也不能直接判为死链。
- 跳转链：多级 301 会让静态请求的最终 URL 和脚本渲染后的 URL 分叉，需要逐跳记录。
这里有一条容易误判的推理：某条链接的请求量归零，不能单独证明它已经失效。请求量下降还可能来自入口页面改版、内链位置下移、抓取预算被分给其他路径，或统计口径变化。要证明失效，仍要回到状态码和内容本身。
按差异类型决定处理动作
定位到具体环节后，处理方式不同：
- 静态 404、脚本有内容：如果希望被抓取和被分享预览，需要让服务端在静态层返回正确状态码和基础内容，或为该路径提供可被抓取的服务端输出。若只服务登录用户，应在监控中把这类 URL 排除，避免误报。
- 静态 200、脚本渲染错误页：问题在客户端，通常是接口失败后的兜底逻辑把错误页渲染成了 200。需要让脚本在内容缺失时给出明确信号，而不是静默展示空壳。
- 两边状态码一致但落地 URL 不同：核对服务端跳转规则与脚本跳转规则，确认哪一条是预期目标，再统一到一处，避免两套规则互相覆盖。
- 仅特定 User-Agent 异常：先确认该分支是有意设计还是配置遗漏，再决定是放行、返回正确状态码，还是保持限制并调整监控预期。
每次处理完，重复同一组对比请求，确认三项记录是否收敛到一致。如果只有状态码变了而响应体仍是空壳，说明问题没有真正解决，只是把信号改得更隐蔽了。
把检查结果变成可复用的判断条件
为了让结论稳定，可以把判断写成条件而不是感觉：静态响应包含目标内容且状态码为 200，判为可用；静态响应状态码为 404 或 410 且响应体无目标内容，判为死链；静态响应为 200 但内容为空壳，判为待确认，必须补做脚本渲染对比；静态响应被重定向到登录页或错误页，判为受限，不计入死链也不计入可用。
这组条件的好处是，它把“脚本渲染结果不同”这个现象拆成了可验证的步骤，也让不同人执行时得到相近结论。条件本身需要按站点实际情况调整，尤其是鉴权和地域分支较多的站点，应先把受限类型单独归类，再统计真正的死链数量。
