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

死链检查方法，页面内容相同但响应头不同会影响哪些判断

会，而且影响往往不在“是不是死链”这一步，而在“这条链接该不该继续查、该按什么状态处理”这一步。页面正文相同不代表响应头可以忽略：状态码、Location、Content-Type、Content-Length、Cache-Control、X-Robots-Tag 以及是否带 Vary，都会改变死链检查工具或日志分析给出的结论。下面按“拿一个页面样本，先分层，再决定是否扩大范围”的顺序说明。

先分清：相同内容可能对应哪几类响应头差异

假设你手头有一个 URL，用浏览器打开看到的是正常文章，但用命令行或抓取工具请求时返回的响应头与浏览器不一致。常见差异可以归为四类，每一类对死链判断的影响不同。

• 状态码不同：浏览器显示 200，工具却看到 301、302、404 或 410。此时先别把 404 当成死链，它可能是请求头、Cookie、UA 或路径大小写导致的另一条分支。
• 重定向目标不同：同一路径对移动端和桌面端返回不同 Location。死链检查若只跟随其中一条链，会把另一条链上的正常页面误判为断链。
• 内容协商不同：带 Vary: Accept-Language 或 Vary: User-Agent 时，同一 URL 可能返回不同语言或不同模板的正文，但状态码都是 200。此时“内容相同”只是你看到的那一次请求相同。
• 缓存与索引指令不同：Cache-Control: noindex、X-Robots-Tag: noindex 或 Content-Type 被写成 text/plain，会让页面虽可访问却不应被当作可索引目标。死链检查若只看状态码，会把它归入“正常”。

这些差异不是同一件事。判断顺序应当是：先确认请求是否等价，再确认响应头是否指向同一资源，最后才判断链接是否失效。

用最小样本做一次可复现的对比

不要一上来就全站跑。选一个你怀疑有差异的 URL，做三次请求并记录响应头：一次用浏览器或默认 UA，一次用不带 Cookie 的干净请求，一次用你死链检查工具实际使用的 UA。比较以下字段：

1. 状态码与重定向次数；
2. Location 是否存在，以及它指向的 URL 是否与最终落地页一致；
3. Content-Type 是否为 text/html；
4. X-Robots-Tag 与页面内 meta robots 是否冲突；
5. Vary 是否包含会改变正文的请求头。

如果三次请求的状态码和 Location 都一致，只是正文渲染不同，那么这条 URL 更可能是内容协商或前端渲染问题，不应直接进入死链清单。如果其中一次返回 404 或 410，而另外两次返回 200，则要先把该分支单独标记，而不是把整条 URL 判死。

这里有一个实际动作：把三次请求的响应头保存为同一份对照记录，并注明每次请求使用的 UA、Cookie 和 Accept-Language。这个动作的结果会直接影响下一步——如果差异只出现在带 Cookie 的请求上，扩大范围时就应优先检查登录态或地域分流，而不是全站重跑死链。

哪些判断不能只靠“内容相同”下结论

内容相同会掩盖三种误判。

第一，把软 404 当成正常页。页面返回 200，但正文是“未找到”或空模板，响应头里也没有 X-Robots-Tag: noindex。这时死链检查工具若只按状态码过滤，会漏掉它。要区分软 404，需要同时看正文特征和响应头，不能只看其中一项。

第二，把重定向链上的中间页当成最终页。A 跳 B、B 跳 C，A 和 B 的正文可能相同或为空，但只有 C 是目标。如果检查工具只记录首次响应，就会把 A 标为 200 或 301，而忽略 B 是否 404。处理时应记录完整跳转链，而不是只看第一条响应。

第三，把 robots.txt 限制或 noindex 当成死链。robots.txt 的抓取限制不等于可靠的索引移除；站点地图也不保证收录。一个 URL 在 robots.txt 中被禁止抓取，并不说明它已失效。反过来，一个 URL 返回 200 但带 X-Robots-Tag: noindex，也不说明它是死链。这两类情况应进入“可访问但不应索引”或“被限制抓取”的分组，而不是死链分组。

把样本结论转成可执行的处理方案

当你确认差异来自响应头而非内容后，按下面顺序处理，避免把个别样本的结论直接套到全站。

• 先分组，不先删除：把 URL 分为“确认死链”“疑似软 404”“重定向链异常”“可访问但 noindex”“被 robots.txt 限制”五组。每组对应不同动作。
• 对确认死链：检查是否应返回 410 或 301 到最相关的新页面。若返回 301，确认 Location 指向的页面本身不是 404 或 noindex。
• 对疑似软 404：在响应头或页面模板中补 noindex，或改为正确的 404 状态码。动作完成后重新请求一次，确认状态码和 X-Robots-Tag 已同步变化。
• 对重定向链异常：只保留一跳到最终页，去掉中间跳转。改完后用同一组请求头复测，确认不再出现中间 404。
• 对可访问但 noindex：不要把它放进死链清单，而应放进“不应出现在索引”的清单，并检查内链是否还在指向它。
• 对被 robots.txt 限制：先确认限制是否有意为之。若是误封，解除后仍需单独验证抓取与索引状态，不能因为解除限制就默认恢复。

这个分组动作的结果会决定下一步是修模板、修跳转还是修 robots 规则。如果跳过分组直接批量改 301，可能把本来只是 noindex 的正常页也跳走，反而制造新的死链。

规模化前必须确认的边界

个别样本成立，不等于全站成立。扩大范围前，至少确认三点。

一是请求头是否一致。死链检查工具、浏览器和日志中的 UA、Accept-Language、Cookie 往往不同。如果样本差异只出现在某一组请求头上，全站跑之前应先固定一组请求头，或按请求头分组跑。

二是缓存是否干扰。CDN 或反向代理可能对同一 URL 返回不同缓存版本，导致你看到的响应头不是源站响应头。此时应绕过缓存复测一次，再决定是否把该差异写入规则。

三是不同搜索引擎支持情况须分别核查。X-Robots-Tag、Vary 和重定向处理在不同搜索引擎之间可能存在差异，不能因为一个引擎的表现就推断另一个。HTTPS 也不保证安全无漏洞或排名，它不能替代对响应头和状态码的检查。

最后提醒一个常见误判：请求量、抓取量或某项统计归零，不能单独证明你的死链处理正确。它还可能来自抓取预算变化、robots 规则调整、日志采样或工具本身的重试策略。要证明处理有效，应回到具体 URL 的响应头对照记录，而不是只看总量曲线。