百度收录延迟：源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /2b4c642f5278.html
📄
百度收录延迟：源站正常而边缘节点异常时应保留哪些证据
先给结论：源站正常不代表百度抓到的页面正常。当边缘节点返回错误、旧缓存或空内容时，百度收录延迟可能只是结果，真正要保留的是“源站响应”和“边缘响应”的对照证据。优先保留能证明差异存在、差异持续时间和差异范围的记录，而不是先删缓存或改 robots.txt。
矛盾现象：源站日志干净，抓取却像没发生
源站日志里，百度蜘蛛的请求返回 200，响应体大小正常，没有 5xx。但同一时间，边缘节点对同一 URL 可能返回 403、404、502，或返回一个不含正文的缓存页。此时会出现两种解释。
- 解释一：源站确实正常，边缘节点在部分地区或部分线路异常。百度部分抓取节点拿到错误响应，于是没有更新索引。这种情况下，源站日志只能证明源站一侧没问题，不能证明整条链路没问题。
- 解释二：源站日志被采样、被合并或时间不同步，看到的“正常”并不覆盖实际抓取。例如源站只记录回源请求，边缘命中缓存时根本不回源；或者日志时区与边缘日志相差数小时，导致对照错位。
两种解释都成立，处理动作却相反：前者要修边缘节点并保留证据，后者要先校准日志口径。先删边缘缓存，可能把唯一能证明异常的响应头和时间戳一起清掉。
能区分两种解释的证据：同一 URL 的双侧对照
最有用的一组证据，是同一时间窗口内、同一 URL 的源站响应与边缘响应对照。至少保留以下字段：
- 请求时间与响应时间，精确到秒，并注明时区。源站和边缘日志时区不一致时，先统一再对照。
- 完整 URL 与查询参数，包括大小写和尾部斜杠。边缘缓存常按规范化后的 URL 命中，源站日志可能只记原始路径。
- 状态码与响应体大小。边缘返回 200 但体积远小于源站，是缓存空页或截断的典型信号。
- 关键响应头：
Cache-Control、Age、X-Cache、Via、Content-Length、Last-Modified。这些字段能说明响应来自缓存还是回源、缓存了多久。 - 抓取来源标识。保留 User-Agent 和来源 IP 段，用于判断是百度抓取还是其他流量，但不要仅凭 UA 下结论。
具体动作：在发现疑似异常后，立即对同一 URL 从至少两个不同网络位置发起请求，记录状态码、响应体大小和上述响应头，同时导出对应时段的源站日志。结果如何影响下一步——如果边缘响应与源站响应在状态码或体积上持续不一致，就可以把问题定位到边缘节点，进入修复和复测；如果两侧一致，则说明异常不在边缘，应转向日志口径、抓取频次或页面本身的变化。
取舍：先修边缘还是先保留证据
两种做法都合理，取决于异常是否仍在持续。
- 异常仍在持续时，先保留证据再修。因为一旦刷新缓存或重启节点，异常响应头、
Age值和错误页内容可能消失。保留方式包括：对异常 URL 截图或保存完整响应文本、导出边缘访问日志、记录复现命令和复现时间。 - 异常已停止、只影响少量 URL 时，可以先修再补证。代价是事后只能靠源站日志和索引状态推断，无法直接证明边缘曾返回错误。此时应尽快记录修复前后的索引状态变化，作为间接证据。
一个假设例子：某页面源站返回 200、正文 80KB，边缘某节点返回 200、正文 2KB，Age 为 86400。若只看到源站日志，会判断一切正常；若保留边缘响应头和体积，就能证明缓存内容异常。这个例子的数字仅用于说明对照方法，不代表任何真实阈值。
这些现象不能单独证明边缘有问题
百度抓取量下降、收录延迟变长，可能有多种解释：抓取配额调整、页面质量变化、站点整体改版、robots.txt 或站点地图变动。请求量归零也不能单独证明处理正确，它可能是抓取暂停、日志丢失或过滤规则误伤。
还需注意：robots.txt 的抓取限制不等于可靠的索引移除；站点地图不保证收录；HTTPS 不保证安全无漏洞或排名。这些事实说明，边缘异常只是收录延迟的可能原因之一，证据要能排除其他解释才有用。
建议保留的最小证据包
如果只能保留少量材料，按以下顺序：
- 异常 URL 清单，注明发现时间和复现次数。
- 同一 URL 的源站与边缘响应对照，含状态码、响应体大小、关键响应头。
- 对应时段的源站与边缘日志片段，时区已统一。
- 复现步骤和网络位置说明，便于他人复核。
- 修复动作及修复后的复测结果，用于判断问题是否真正关闭。
保留这些证据的目的不是证明“百度有问题”，而是让下一步动作有依据：能对照出差异，就修边缘并复测；对照不出差异，就回到抓取日志和页面变化上继续排查。
