如果两份响应的正文完全一致,但一份返回 200 OK 且带正常内容类型,另一份返回 206 Partial Content、304 Not Modified 或错误的 Content-Type,百度对这两份响应的处理判断就可能不同。此时真正要解决的不是正文重复,而是先确认响应头是否让抓取端把同一内容识别成了不同资源,或误判为不完整、不可索引的响应。
正文相同只说明字节层面的内容接近,不能说明抓取、索引和展现三层判断一致。响应头首先影响的是抓取端对这次请求是否成功的判断。例如,200 通常表示完整返回;206 表示部分内容,抓取端可能不会把它当作完整页面处理;304 表示资源未修改,通常用于条件请求,若在普通抓取场景下频繁出现,抓取端可能无法获得最新正文;Content-Type 若不是 text/html,页面可能被当成其他资源类型处理。
这些差异不会因为正文相同而自动抵消。判断顺序应是:先看状态码是否表示完整成功,再看内容类型是否与页面类型一致,最后才看正文是否重复。若第一步就不成立,后面的内容比较没有决策价值。
假设某站点同一套页面内容通过两个入口返回:入口 A 返回 200、Content-Type: text/html,入口 B 返回 206、Content-Type: text/html。两份正文由同一模板生成,肉眼和文本比对都相同。此时不能直接判断“内容重复,需要合并”,而应先确认入口 B 为什么返回 206。
如果入口 B 是范围请求触发的正常部分响应,那么它本来就不应作为页面抓取入口;把它当作可收录地址提交,可能让抓取端拿不到完整页面。实际动作是:检查入口 B 是否被站内链接、站点地图或跳转指向。如果被指向,先移除这些指向,再观察入口 A 的抓取和索引状态是否变化。这个动作的结果会决定下一步:若入口 A 的抓取恢复正常,问题属于入口选择错误;若入口 A 仍无变化,才继续排查内容质量和站内结构。
200 与 206 并存:优先确认 206 地址是否被当作普通页面入口使用。若是,先切断入口,而不是先改正文。200 与 304 混用:确认条件请求是否被错误地用于首次抓取或普通访问。若抓取端长期只拿到 304,需要检查缓存和校验逻辑,而不是只提交站点地图。Content-Type 不一致:一份是 text/html,另一份是 application/octet-stream 或 text/plain。后者可能被当成下载或纯文本资源,影响页面级判断。Content-Length 或分块传输差异:若一份声明长度与实际不符,抓取端可能认为响应不完整。此时应修正响应生成逻辑,而不是重复提交同一地址。Vary、Cache-Control 差异:可能让不同抓取请求拿到不同缓存版本。若正文相同但缓存策略不同,应先统一缓存键和回源逻辑,再判断内容是否重复。这些情况的共同点是:正文相同并不能证明响应等价。响应头决定了抓取端是否拿到完整、可解析、可缓存的页面表示。
不要只凭“抓取量归零”或“某次日志里没有出现”就断定响应头是唯一原因。抓取量下降还可能来自站点整体抓取预算调整、robots.txt 限制、服务器不稳定、外部链接变化或百度自身调度波动。robots.txt 的抓取限制也不等于可靠的索引移除;站点地图不保证收录;HTTPS 不保证安全无漏洞或排名。验证时应把响应头作为一组可区分原因之一,而不是唯一解释。
一个可操作的验证方法是:在假设前提下,保持正文、内链和站点地图不变,只修正入口 B 的响应头,使其与入口 A 一致,然后分别记录两个入口在后续抓取中的状态码分布和内容类型分布。若入口 B 的状态码从 206 变为 200 后,抓取端开始稳定获取完整正文,说明响应头是主要变量;若状态码已一致但抓取仍无变化,则要继续检查内容质量、站内链接和服务器稳定性。这个结果直接决定下一步是继续修响应头,还是转向其他层排查。
如果两个入口本来就承担不同职责,例如一个用于下载、一个用于页面展示,且下载入口没有被站内链接、站点地图或跳转当作页面地址使用,那么可以不强行统一响应头。适用条件是:页面入口始终返回完整 200 和正确内容类型,下载入口不被当作可索引页面提交,且抓取端没有把两者混为同一资源。此时优先保持职责分离,而不是为了“看起来一致”去改下载响应。
反过来,如果两个入口都可能被用户、站内链接或站点地图当作页面访问,就应先统一页面入口的响应头,再处理内容重复。判断依据不是正文是否相同,而是哪个地址会被抓取端当作页面资源请求。只有先让页面入口返回完整、正确的响应,后续关于收录的判断才有意义。