网址收录：内容相同但响应头不同，该先查哪一层
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /3bf37130e3e9.html
📄
网址收录：内容相同但响应头不同，该先查哪一层
内容完全相同的两个地址，如果响应头不同，最先要判断的不是“哪个会被收录”，而是它们是否被当成两个可独立选择的资源。对已有业务而言，关键变化通常来自缓存策略、内容协商或重定向链的调整：一旦同一份正文对应多个响应头组合，抓取工具可能看到不同状态、不同类型或不同缓存指令，后续的规范化、抓取预算和索引选择都会跟着变。处理顺序应当是先确认响应头差异属于哪一类，再决定合并、保留还是回退。
先区分三种响应头差异，不要直接改正文
把手中的页面当作样本，分别用带缓存和不带缓存的请求取一次响应头，重点看三组字段：Content-Type、Cache-Control与Vary、以及状态码和Location。这三组对应完全不同的判断。
- Content-Type 不同：例如一份返回
text/html，另一份返回application/xhtml+xml或text/plain。正文肉眼相同，但解析路径不同，可能一份被当作可索引页面，另一份被当作下载或纯文本。 - 缓存与 Vary 不同：同一地址对移动端与桌面端返回不同
Cache-Control，却没有声明Vary。中间缓存可能把一份响应交给另一类请求，抓取工具拿到的内容与响应头不匹配。 - 状态码与跳转不同：一份是
200，另一份是301、302或304。正文相同不代表状态相同，跳转链上的中间地址是否值得保留，取决于它是否承担了独立入口。
如果三组里只有 Cache-Control 的 max-age 数值不同，而状态码、类型和 Vary 一致，通常不需要为收录单独做处理，先解决缓存一致性即可。
用可复现的请求把差异钉死
不要凭浏览器地址栏的印象下结论。对同一路径分别发起两次请求：一次带常见的浏览器请求头，一次不带 Accept 与 User-Agent 中影响内容协商的部分，保存完整响应头。把两次结果并排比较，只记录真正不同的字段。
假设一个短例子：某页面在带 Accept: text/html 时返回 200 与 text/html，在不带该头时返回 406 或 text/plain。此时“内容相同”只是错觉——服务端根本没有把这份正文作为默认表示提供。下一步不是提交收录，而是修内容协商的默认分支，让无偏好请求也能得到与主版本一致的表示。
这个动作的结果会直接改变后续判断：如果修完后两次响应头收敛为同一组，问题就从“多版本选择”降级为普通抓取；如果仍然分叉，说明差异来自更上层的网关或 CDN 配置，需要继续往请求链路的上游查，而不是反复改页面模板。
响应头不同会改变哪些收录判断
内容一致时，响应头差异主要影响四个判断，且它们并不等价。
- 是否构成重复资源：类型或状态不同时，抓取工具可能把它们视为不同资源，而不是同一正文的两个副本。此时单靠 canonical 指向并不一定足够，还要让两个地址的响应语义一致。
- 哪一个地址值得保留：如果一个是
200、一个是302，保留 200 的地址通常更合理；但如果 302 的地址承载了真实外链和用户入口，直接删掉会损失入口，应先评估跳转是否可改为 301，并确认目标稳定。 - 抓取预算的分配：同一正文的多个响应头组合会各自消耗请求。若差异由参数或内容协商批量产生，先收敛响应头比逐条提交更有效。
- 缓存与更新可见性：
Cache-Control过长且缺少Vary时，抓取工具可能长期拿到旧表示。此时即使正文已更新，看到的仍是旧响应头组合。
需要提醒的是，请求量或抓取量下降本身不能证明某个响应头处理正确，它也可能来自抓取节奏调整、入口减少或服务端限流。把响应头变化与抓取日志放在同一时间窗对照，才是有依据的判断方式。
按前提变化决定合并、保留还是回退
把决策条件写清楚，才能避免“看到差异就统一”。
- 应当合并：两个地址正文相同，且其中一个没有独立入口、没有外链、没有用户收藏价值。做法是让次要地址返回 301 指向主地址，并让主地址的响应头稳定为单一组合。合并后观察主地址的响应头是否仍被其他规则改写。
- 应当保留：两个地址面向不同设备或不同语言，且差异是有意为之。此时要补齐
Vary，让缓存按维度区分，并确认每个版本都有稳定的状态码与类型。保留的前提是你能说清每个版本服务谁。 - 应当回退：改动后主地址出现 5xx、跳转成环，或原本可正常返回的表示变成 406。回退到改动前的响应头配置，先恢复单一稳定表示，再重新设计协商规则。回退不是失败，而是避免把可抓取状态拖成不可抓取状态。
如果站点使用 robots.txt 限制某些路径，要记住抓取限制不等于可靠的索引移除；被限制抓取的地址仍可能因外链被引用而出现在结果中。站点地图也不保证收录，它只提供发现线索。HTTPS 同样不保证安全无漏洞或排名。不同搜索引擎对内容协商和响应头的支持情况需要分别核查，不能拿一个引擎的表现推断全部。
把处理结果写回可执行的检查项
完成一轮处理后，用同一路径再做一次无偏好请求，确认三件事：状态码是否唯一、类型是否与正文一致、缓存指令是否与 Vary 匹配。若三项都稳定，下一步才是观察该地址在抓取日志中的响应分布，而不是立刻追加提交。若仍分叉，把差异字段和请求头一起记录，交给能改网关或服务端配置的人，而不是继续在页面层加标签。
这样做的价值在于：你判断的是响应语义是否一致，而不是正文是否看起来一样；后续无论是合并、保留还是回退，都有可复现的证据支撑，而不是靠一次抓取结果下结论。
