百度URL提交，源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /9f6cc57829b7.html
📄
百度URL提交，源站正常而边缘节点异常时应保留哪些证据
当源站返回正常、边缘节点却对百度蜘蛛返回异常时，先别急着重新提交或改 robots。应保留三类证据：同一时刻源站与边缘的对照响应、边缘节点异常响应的原始记录、以及百度URL提交后抓取行为变化的日志。这三类证据能区分“源站问题”“边缘问题”和“提交本身的问题”，决定下一步是修边缘、回源还是暂停提交。
先固定一个假设情境，避免边查边改
假设：某旧系统需要退出，但其中一部分旧内容仍有保留价值。运维把旧域名整体切到边缘节点，源站继续正常返回 200。随后发现百度蜘蛛访问时，边缘节点对部分旧 URL 返回 403 或 5xx，而源站直连始终正常。此时如果直接重新做百度URL提交，等于在异常状态下叠加新变量，后续很难判断是边缘问题还是提交动作导致的。
正确顺序是先冻结变更，再采集证据。冻结包括：暂停批量提交、暂停边缘规则调整、暂停删除旧内容。只有保持状态不变，采集到的对照数据才有比较意义。
证据一：同一时刻的源站与边缘对照响应
核心是证明“差异发生在边缘，而不是源站”。需要记录同一 URL、同一时间窗口内两组响应：
- 直连源站（绕过边缘）的状态码、响应头、响应体前若干字节。
- 经边缘节点访问的状态码、响应头、是否命中缓存、回源与否。
关键字段包括状态码、Content-Type、Cache-Control、X-Cache 一类边缘标记，以及响应时间。若源站 200、边缘 403，且边缘响应头显示命中缓存，说明异常很可能来自缓存副本或边缘规则，而非源站内容本身。这个判断会直接影响下一步：优先清边缘缓存或修规则，而不是改源站或重新提交。
证据二：异常响应的原始记录与触发条件
只截一张 403 页面不够，要能回答“什么条件下异常”。需要保留：
- 异常 URL 的完整列表，以及它们与正常 URL 的差异（路径、参数、目录层级）。
- 触发异常时的请求特征：User-Agent、来源 IP 段、请求方法、是否带特定查询参数。
- 边缘节点的访问日志与错误日志中对应时间点的条目。
例如，假设异常只出现在带某个旧查询参数的 URL 上，而纯静态路径正常，那么问题更可能是边缘规则对参数的处理，而不是整站不可访问。此时处理范围可以收窄到规则层，不必动全部旧内容。
还要注意：边缘节点对百度蜘蛛返回 403，不等于内容已被移除。robots.txt 的抓取限制也不等于可靠的索引移除。两者是不同机制，不能互相替代，证据里要分开记录。
证据三：百度URL提交后的抓取行为变化
提交本身会产生状态变化，所以要把“提交前”和“提交后”的日志分开留存。需要核对：
- 提交时间点，以及对应 URL 在服务端日志中是否出现新的抓取请求。
- 抓取请求命中的是源站还是边缘，返回码是什么。
- 提交前后同一 URL 的抓取频次与返回码是否一致。
如果提交后抓取量归零，不能单独证明提交失败。合理解释至少包括：边缘持续返回异常导致抓取被抑制、抓取调度本身有周期、或该 URL 本来就不在活跃抓取范围内。只有把提交记录、边缘日志、源站日志按时间对齐，才能排除部分解释。
站点地图不保证收录，提交也不保证抓取。证据的作用是缩小原因范围，而不是承诺结果。
根据证据决定下一步动作
采集完成后，按差异位置分流：
- 源站正常、边缘异常且命中缓存：先清缓存并复测边缘响应，再决定是否重新提交。复测仍异常，则查边缘规则。
- 源站正常、边缘异常但未命中缓存：问题在回源链路或边缘规则，修完并确认边缘返回 200 后，再恢复提交。
- 源站与边缘都正常，仅提交后无抓取：保留日志继续观察，不叠加新提交，避免污染对照。
对于要退出的旧系统，保留有价值部分的做法是：先确认这些 URL 在边缘稳定返回 200，再单独整理它们的清单，而不是整站提交。退出旧合作关系或旧系统时，边缘异常往往先于源站暴露，证据留得越完整，越能避免把边缘故障误判为内容失效。
