📍 WDQWDWQD987AAAAA:216.73.217.110
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /d50b94a72024.html
📄

网站收录检查：源站正常而边缘节点异常时应保留哪些证据

先给结论：源站返回正常、边缘节点却出现异常时，应优先保留能同时证明“源站确实正常”和“边缘确实异常”的对照证据，而不是只截一张异常图。可保留的最小证据集包括：同一URL在源站直连与经过边缘节点时的完整响应头、响应体片段、状态码、时间戳、请求标识，以及抓取工具的原始日志。这些证据的价值在于可复核：换一个时间、换一个出口、换一个人，仍能判断差异是否真实存在。

矛盾现象：源站200，边缘节点却返回异常

最常见的矛盾是：直接请求源站IP或回源地址，得到200和完整正文；通过边缘节点访问同一URL，却得到403、404、503，或者返回一个内容被替换、被截断的页面。直觉会认为“源站没问题，所以收录问题一定是搜索引擎的错”，但这个推断跳过了中间层。

这个现象至少有两种成立条件不同的解释：

• 解释一：边缘节点自身行为导致异常。边缘节点可能因缓存了旧版本、命中了一条过期的重写规则、对特定UA或IP段做了拦截，或者回源时携带了源站不接受的请求头。这种情况下，源站直连正常，但边缘返回的响应与源站不一致。
• 解释二：源站对“边缘回源请求”的响应与对“直连请求”的响应不同。源站可能根据Host、X-Forwarded-For、协议、SNI或请求方法返回不同结果。表面上源站正常，实际是边缘回源时触发了另一条分支，导致边缘拿到异常内容再返回给抓取方。

两种解释都表现为“源站正常、边缘异常”，但修复动作完全不同：前者要查边缘配置和缓存，后者要查源站对回源请求的处理逻辑。因此，网站收录检查在这一步的核心不是继续问“收录了没有”，而是先区分这两种解释。

能区分两种解释的证据：对照请求与响应头

区分的关键是制造一组可对照的请求，并保留原始记录。建议至少做三组请求，每组都保留完整响应头、状态码、响应体开头若干字节和时间戳：

1. 直连源站（绕过边缘）请求目标URL。
2. 经过边缘节点请求同一URL，使用与抓取工具相近的UA。
3. 经过边缘节点请求同一URL，使用普通浏览器UA。

如果第1组正常、第2组异常、第3组正常，说明异常与UA相关，更偏向解释一中的边缘拦截或规则命中。如果第2组和第3组都异常，而第1组正常，则要检查边缘回源时携带的请求头是否与直连不同，例如Host、协议、X-Forwarded-Proto、Accept-Encoding。此时差异出现在回源链路，偏向解释二。

响应头里几个字段特别有用：Age或缓存命中标识能说明边缘是否直接返回了缓存；Via或类似字段能说明请求经过了哪些中间层；X-Cache一类自定义头（如果存在）能区分命中与回源。没有这些字段时，用请求标识和响应时间也能间接判断：边缘直接返回缓存通常更快，回源异常通常伴随更长的等待或超时。

一个假设例子：某页面直连源站返回200，正文完整；经过边缘返回200，但正文只有一段错误提示。此时仅看状态码会误判为正常。保留响应体片段后会发现，边缘返回的正文与源站不同，且响应头里带有缓存命中标识。这个证据把方向指向边缘缓存了错误版本，下一步应检查缓存刷新和回源规则，而不是去改源站页面。

抓取日志与时间戳：让证据可复核

只保留截图不够，因为截图无法证明请求发生的时间、出口和请求头。应保留抓取工具的原始日志或可导出的请求记录，至少包含：请求时间（带时区）、请求URL、请求方法、请求头中的UA和Host、响应状态码、响应头、响应体长度或摘要、使用的出口IP或节点标识。

时间戳的作用是排除“不同时刻状态不同”的干扰。如果源站正常和边缘异常发生在不同时间，不能直接归因于边缘，也可能是源站在两个时刻发布了不同版本。因此，对照请求应尽量在同一时间窗口内完成，并记录每次请求的先后顺序。

另一个实际动作是保存边缘节点的节点标识或响应中可暴露的节点信息。如果同一URL在不同边缘节点表现不同，说明问题与节点或区域相关，而不是全局配置。这个结果会直接影响下一步：只刷新一个节点还是排查整个边缘网络。

常见误判：这些现象不能单独证明结论

网站收录检查中，几个现象容易被当成结论，但都需要其他证据配合：

• 抓取量或请求量下降。这可能是边缘异常导致抓取失败，也可能是抓取预算调整、内容更新频率变化或站点整体流量波动。单独看请求量归零不能证明边缘处理正确，也不能证明收录被移除。
• robots.txt 里加了限制。robots.txt 的抓取限制不等于可靠的索引移除。它只约束遵守协议的抓取方，已收录页面可能仍会出现在结果中，移除需要其他机制。
• 站点地图提交成功。站点地图不保证收录。边缘异常时，站点地图里的URL仍可能被抓取失败。
• 启用了HTTPS。HTTPS 不保证安全无漏洞或排名。边缘节点异常可能与证书链、SNI或协议协商有关，但HTTPS本身不是收录正常的充分条件。

这些现象只能作为线索，不能单独作为“边缘正常”或“源站正常”的证据。把它们与前面的对照请求放在一起，才能形成可复核的判断。

保留证据后的下一步动作

当证据能区分解释后，动作就有针对性：如果证据指向边缘缓存或规则，下一步是刷新对应缓存、核对回源规则和UA拦截规则，并再次用同一组对照请求验证；如果证据指向源站对回源请求的差异化响应，下一步是检查源站日志中来自边缘节点的请求，对比直连请求的请求头差异，修正源站分支逻辑后再验证。

验证时仍要保留前后两组证据，因为“修复后正常”也需要可复核的记录。若修复后边缘返回正常，但抓取工具仍显示异常，则要检查抓取工具自身的缓存或出口，而不是继续改边缘配置。整个流程的目标不是一次判断谁对谁错，而是让每一步都有可对照的证据，使下一步动作建立在可验证的差异上。