如何让百度收录网站：源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /0f6a2ad384c7.html
📄
如何让百度收录网站：源站正常而边缘节点异常时应保留哪些证据
先给结论：源站返回 200 只能证明回源这一跳正常，百度蜘蛛看到的是边缘节点返回的响应。此时应保留三类证据——同一 URL 在源站与边缘节点的响应对比、边缘节点返回的完整响应头、以及带时间戳的抓取日志。缺了其中任何一类，后续都只能靠猜。
为什么源站正常不等于蜘蛛抓到的正常
百度蜘蛛的请求先到 CDN 或反向代理，再由边缘节点回源。源站监控通常只探测源站本身，边缘节点是否缓存了错误页、是否对特定 UA 返回不同内容，源站监控看不到。常见的表现是：你在源站 curl 得到 200，蜘蛛日志里同一 URL 却是 403、503 或跳转到验证页。
所以判断依据不是“源站是否正常”，而是“同一请求在两个位置是否一致”。这决定了你接下来要采集什么。
第一类证据：同 URL 的双端响应对比
选一个具体页面作为样本，不要笼统地说“整站有问题”。对同一个 URL 分别向源站地址和边缘节点地址发起请求，记录以下内容：
- 状态码，以及是否发生跳转、跳转到哪里
- 响应体开头若干字节，用于判断是否被替换成错误页或验证页
- 请求时使用的 UA，最好与百度蜘蛛的 UA 一致，并同时用普通浏览器 UA 做对照
- 请求时间，精确到分钟
如果两者状态码不同，或响应体明显不同，就说明差异发生在边缘层。这一步的动作结果是：把排查范围从“整站”缩小到“边缘节点配置或缓存”，后续不必再花时间检查源站程序。
假设的例子
假设某页面源站返回 200 且内容完整，边缘节点返回 403。你保留了两份响应体开头对比和各自时间戳。这个对比本身不能说明原因，但它能排除源站故障，让下一步直接指向边缘节点的访问控制规则或缓存策略，而不是去翻源站日志。
第二类证据：边缘节点返回的完整响应头
响应头比状态码更能说明中间发生了什么。需要保留的字段包括：
Cache-Control、Age、X-Cache一类缓存标记，用来判断命中的是缓存还是回源Vary，判断是否按 UA 或其它头做了差异化响应Server与自定义节点标识，确认响应确实来自边缘而非源站- 任何重定向相关的
Location
把这些头连同请求时间一起保存。如果 Age 显示命中了旧缓存，而你刚更新过页面，那问题可能只是缓存未刷新，与收录本身无关。这是区分“边缘异常”和“内容更新未生效”的关键一步。
第三类证据：带时间戳的抓取日志
日志要能回答“蜘蛛什么时候来、拿到了什么”。至少保留：
- 蜘蛛请求的时间、URL、UA
- 边缘节点返回给蜘蛛的状态码
- 该请求是否回源、回源结果是什么
把日志与前面的双端对比放在同一时间轴上，就能看出异常是持续存在还是只出现在某个时间段。如果只有蜘蛛 UA 被拒，普通 UA 正常，方向就指向 UA 相关的访问控制；如果所有 UA 都异常，方向则指向节点本身。
这些证据不能证明什么
需要提醒的是：某段时间日志里蜘蛛请求为零，并不能单独证明边缘节点就是原因。抓取频率下降、站点整体抓取预算变化、robots.txt 限制都可能造成类似现象。robots.txt 的抓取限制也不等于可靠的索引移除，站点地图不保证收录。因此日志只能作为证据之一，必须和前两类证据交叉比对。
另外，HTTPS 不保证安全无漏洞或排名，它和边缘节点异常是两回事，不要混在一起排查。
按顺序做的一个可执行流程
先固定一个样本 URL，做双端对比并保存结果；再取该 URL 的完整响应头；最后从日志中找出同一时间段内蜘蛛对该 URL 的请求记录。三份材料时间对齐后，你就能把问题定位到“缓存”“访问控制”或“节点回源”中的某一类，并据此决定是联系节点运维、调整缓存规则，还是继续观察。缺少任何一份，判断都会退回到猜测。
