索引量查询：源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /82ea6f3ee046.html
📄
索引量查询：源站正常而边缘节点异常时应保留哪些证据
当索引量查询结果下滑，而源站日志显示抓取与响应都正常时，问题很可能出在边缘节点这一层：搜索引擎拿到的是缓存、CDN或WAF返回的版本，而不是你源站输出的版本。此时要做的不是改源站，而是先固定边缘侧的证据，再决定是清缓存、调规则还是回滚配置。
先分清源站正常与边缘正常是两件事
源站正常只能说明你的应用和数据库没问题，不能说明搜索引擎看到的内容和你一样。边缘节点可能因为缓存过期策略、压缩差异、UA识别、地区回源或安全规则，返回与源站不同的状态码和正文。判断是否属于这一类，需要同时满足两个条件：源站直连返回200且正文完整；通过边缘域名请求时出现状态码、正文长度或关键内容不一致。只满足前一条，不足以排除边缘问题。
假设一个场景：你从源站IP直接请求某文章页，返回200，正文包含标题和主体；通过边缘域名请求同一URL，返回200但正文只剩导航和页脚。这个对比本身就构成一条可用的证据，说明边缘层做了额外处理。下一步不是立刻清缓存，而是先记录这条差异，再扩大样本确认范围。
需要固定的四类边缘证据
证据要能复查，就必须带时间、URL、请求方式和返回内容。以下四类按优先级排列：
- 边缘响应头：记录状态码、Content-Length、Content-Type、缓存命中标识、回源标识、压缩标识。这些字段能区分是缓存命中旧版本，还是回源后被改写。
- 边缘返回正文的摘要：保存正文长度、关键标题是否存在、是否出现验证页或拦截提示。不必保存全文，但要能证明差异存在。
- 源站同URL的对照响应：同一时间、同一路径，从源站直连取得状态码和正文摘要，作为基线。
- 边缘配置的变更记录：缓存规则、回源规则、UA规则、安全策略最近一次改动的时间和内容。没有这条，就无法判断异常是配置引起还是偶发。
这四类证据缺一不可。只有边缘响应头而没有源站对照，无法证明差异；只有差异而没有变更记录，无法决定是回滚还是等待。
用一组对照请求缩小范围
单条URL异常可能是页面级缓存问题，多条URL异常才指向规则级问题。可以按下面的顺序做对照：
- 同一URL，分别用源站直连和边缘域名请求，比较状态码与正文摘要。
- 同一URL，分别带搜索引擎UA和普通浏览器UA请求边缘，比较返回是否不同。若不同，问题在UA相关规则。
- 同一URL，从不同地区或不同边缘节点请求，比较返回是否一致。若不一致，问题在节点级缓存或回源。
- 同一批URL中抽取正常页与异常页各若干，比较它们是否命中同一缓存规则或同一路径前缀。
如果只有带搜索引擎UA时返回异常，而普通UA正常，那么优先检查边缘层的UA识别与安全策略，而不是源站内容。如果所有UA都异常，且源站对照正常，那么优先检查缓存与回源配置。这个区分直接决定下一步动作：前者改规则，后者清缓存或回滚。
证据到手后怎样决定动作
不同证据组合对应不同处理，不能一律清缓存了事。
情况一：边缘返回旧版本，源站已更新。特征是响应头显示缓存命中，正文与源站当前版本不一致。此时清理对应URL的缓存并观察边缘响应头是否转为回源，是合理动作。清理后要重新取一次边缘响应，确认正文与源站一致，再决定是否需要调整缓存过期策略。
情况二：边缘返回拦截页或验证页。特征是状态码可能仍是200，但正文是安全提示。此时清缓存无效，需要检查安全策略与UA规则。动作是调整规则并重新请求验证，而不是反复刷新缓存。
情况三：边缘与源站一致，但索引量查询仍下滑。这说明边缘层不是原因，应转向其他方向排查，例如robots.txt是否被误改、页面是否被设为不可索引、站点地图是否失效。需要提醒的是，robots.txt的抓取限制不等于可靠的索引移除，站点地图也不保证收录，这两点常被误当成原因或解决方案。
每种情况处理完后，都要重新取一组边缘与源站的对照响应，确认差异消失。差异未消失就说明动作没打中原因，不应继续扩大操作范围。
把证据整理成可复查的最小记录
最终要留下的不是一堆截图，而是一份能让他人复现的记录。最小字段包括：时间、URL、请求来源（源站直连或边缘域名）、UA、状态码、正文长度、关键内容是否存在、命中的边缘规则、当时的配置版本。有了这份记录，即使换人处理，也能判断异常是否已修复，以及修复动作是否真的改变了边缘返回结果。
需要强调的是，请求量或抓取量归零不能单独证明边缘处理正确，它也可能是抓取预算调整、站点整体改动或统计口径变化的结果。判断依据始终是边缘与源站的对照差异是否消失，而不是某个单一指标的变化。
