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

SEO死链处理：页面内容相同但响应头不同会影响哪些判断

页面正文完全一样，响应头却不同，最直接的影响是：你无法再只凭“内容相同”判断这两条 URL 该保留哪一条、该让哪一条退出索引。响应头里的状态码、Location、X-Robots-Tag、Content-Type 和缓存指令，会分别改变抓取、索引和展示三层结论。处理死链时，先确认这两条 URL 是“同一资源的两种入口”，还是“两个独立资源恰好内容重复”，动作完全不同。

先分清两种成立条件：同源等价，还是独立重复

如果两条 URL 返回 200 且正文一致，但其中一条带 X-Robots-Tag: noindex，另一条没有，这通常说明站点有意让其中一条不进入索引。此时不能因为“内容一样”就把两条都当死链删除，也不能把带 noindex 的那条简单 301 到另一条——需要先确认它是刻意设置的过滤页、参数页还是旧入口。

如果一条返回 200，另一条返回 301 并指向第一条，正文相同只是重定向后抓到的结果，那么后者本身不是死链，而是规范化入口。真正要处理的是：这条 301 是否稳定、是否指向最终 200、是否形成链式跳转。判断依据不在正文，而在响应头里的状态码与 Location 是否始终一致。

两种条件的边界可以这样区分：用同一请求头分别请求两条 URL，记录状态码、Location、X-Robots-Tag、Content-Type 和 Vary。若除状态码外其余头一致、且 301 指向 200，按同源等价处理；若 X-Robots-Tag、Content-Type 或 Vary 不同，则按独立重复处理，先查清设置来源再决定去留。

响应头不同会改变哪些具体判断

状态码决定这条 URL 是否还算“存在”。 404 和 410 都表示资源不可用，但 410 更明确；301 和 302 的区别在于是否永久。内容相同但状态码不同，说明至少有一条 URL 的语义已经改变，不能再用“页面内容”作为唯一依据。

X-Robots-Tag 决定索引意图。 它与页面内的 meta robots 作用类似，但作用在 HTTP 层，对非 HTML 资源也有效。两条 URL 内容相同、一条带 noindex，另一条不带，说明站点对它们的索引期望不同。此时若把带 noindex 的那条当作死链删除，可能删掉一个本就被刻意排除的入口；若把它 301 到不带 noindex 的那条，则可能把原本不想被索引的 URL 变成可索引路径。

Location 决定跳转是否可信。 同一条 URL 在不同时间返回不同 Location，或者 301 指向的地址又返回 301，都会让“内容相同”这个观察失去意义。判断死链时，应沿着 Location 追到最终 200，确认跳转链没有循环、没有跨协议反复、没有落到 404。

Content-Type 和 Vary 决定内容是否真的相同。 两条 URL 返回的字节可能一样，但一条声明为 text/html，另一条声明为其他类型，抓取方的处理方式会不同。Vary 不同则意味着同一 URL 可能因请求头返回不同内容，此时“内容相同”只是当前请求下的巧合，不能推广到所有抓取场景。

一个假设例子：样本成立，规模化后出现例外

假设某站点有一批旧商品页，测试了 20 条，发现每条旧 URL 都返回 301 指向新 URL，正文一致，于是决定把所有旧 URL 按同一规则批量 301。这个结论在样本内成立，但规模化后可能出现例外：部分旧 URL 的 301 目标本身已 404；部分旧 URL 带 X-Robots-Tag: noindex，说明它们原本就不该被索引；还有部分旧 URL 的 Location 指向带参数的地址，与样本中的干净地址不同。

这时不能直接照搬样本规则。实际动作是：先按响应头分组，而不是按正文分组。把状态码、Location 目标、X-Robots-Tag 是否存在、Content-Type 是否一致作为分组字段，逐组决定处理方式。分组结果会直接影响下一步——如果某一组普遍带 noindex，说明这批 URL 可能属于同一类被刻意排除的入口，应先查设置来源，而不是统一跳转。

实施动作与例外边界

可执行的第一步是固定请求条件：用相同 User-Agent、相同协议、相同路径大小写，分别请求待处理 URL，记录完整响应头。不要只记录状态码，因为状态码相同、其余头不同的情况恰恰是本题要处理的场景。

第二步是按响应头差异分类，而不是按正文相似度分类。可以按以下顺序判断：

1. 状态码是否为 3xx；若是，追 Location 到最终 200，确认无循环。
2. 是否存在 X-Robots-Tag；若存在且含 noindex，先查设置来源，不直接删除或跳转。
3. Content-Type 是否一致；若不一致，确认哪一条才是目标资源类型。
4. Vary 是否不同；若不同，用多组请求头复测，确认内容是否真的稳定相同。

第三步是根据分类结果决定动作：同源等价组可保留一条、其余 301；独立重复组先查清 noindex 或类型差异的来源，再决定保留、移除还是保持现状。动作完成后，用同一套请求条件复测，确认响应头已按预期变化，而不是只看正文是否还能打开。

例外边界需要明确：robots.txt 的抓取限制不等于可靠的索引移除，即使某条 URL 被 robots.txt 禁止抓取，它仍可能因外部链接出现在索引中；站点地图不保证收录，把某条 URL 放进站点地图不能替代对响应头的处理；HTTPS 不保证安全无漏洞或排名，协议差异本身不能作为判断死链的依据。请求量、抓取量或某项统计归零，也不能单独证明处理正确——它还可能来自抓取预算变化、外部链接减少或统计口径调整。必要适用条件是：这套判断只适用于你能控制响应头、且能复测的 URL；对于第三方域名或无法复测的入口，只能记录观察，不能据此批量操作。