百度收录规则源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /072d1467e775.html
📄
百度收录规则源站正常而边缘节点异常时应保留哪些证据
当源站日志显示百度蜘蛛请求正常、返回200，但边缘节点或CDN侧出现5xx、超时、回源失败时，不能只看源站日志就判断“收录没问题”。要区分“百度根本没抓到边缘异常”和“百度抓到了但被边缘拦掉”，需要保留三组证据：边缘节点的原始响应记录、百度侧可见的抓取痕迹、以及从多个网络位置复现的请求结果。缺少其中任何一组，都可能把边缘故障误判为源站故障，或反过来把源站问题归因给边缘。
先确认矛盾现象的真实形态
源站正常而边缘异常，通常表现为两种直觉相反的结果。一种是源站监控全绿，但百度抓取量骤降；另一种是百度抓取量没变，但索引量下滑。这两种现象指向不同的证据方向。
如果抓取量骤降，优先怀疑百度蜘蛛在边缘节点被拒绝或超时，需要看边缘的访问日志和状态码分布。如果抓取量没变而索引量下滑，则要怀疑百度抓到的内容与源站不一致，比如边缘缓存了旧版本、错误页或空白页，需要对比边缘返回的HTML与源站返回的HTML是否一致。
这个判断动作本身就会影响下一步：抓取量下降时，重点查边缘的连通性和限流策略；索引量下降时，重点查边缘缓存的内容正确性。两者需要的证据不同，不能混在一起查。
解释一：百度蜘蛛的请求根本没有到达源站
这种解释成立的条件是：边缘节点在百度蜘蛛发起请求时返回了错误，或者连接被重置，导致请求没有回源。常见的边缘侧原因包括节点故障、回源超时、WAF误拦、限流规则命中。
支持这个解释的证据包括：边缘访问日志中出现百度蜘蛛UA对应的5xx或499状态码；边缘的监控曲线在故障时段出现错误率上升；从多个外部网络位置用相同UA请求边缘节点，能复现错误。如果这些证据同时存在，而源站日志在对应时段没有收到该请求，就可以比较有把握地判断请求被边缘截断了。
需要保留的具体材料：边缘节点的访问日志片段，包含时间、UA、请求URL、状态码、响应时间；边缘的错误率监控截图或导出数据；从至少两个不同网络位置发起的请求记录，注明请求时间、使用的UA、返回状态码和响应体前若干字节。
解释二：请求到达了源站，但百度拿到的内容不对
这种解释成立的条件是：边缘节点成功回源并返回了200，但返回给百度的内容与源站当前内容不一致。可能是缓存了旧版本，可能是边缘做了内容压缩或转码导致结构损坏，也可能是边缘返回了一个默认页或错误页但状态码仍是200。
区分这种解释的关键证据是内容比对。从边缘节点请求一个URL，保存返回的HTML；再从源站直接请求同一个URL，保存返回的HTML。逐段对比标题、正文、canonical、robots meta、结构化数据。如果边缘返回的HTML中缺少正文、canonical指向错误、或者robots meta变成了noindex，那问题就不在连通性，而在内容一致性。
这里有一个容易忽略的细节：边缘返回200不代表内容正确。状态码正常但内容被替换，百度仍然会按错误内容处理。保留证据时要同时保存响应头和响应体，不能只记录状态码。
用一组可区分的证据把两种解释分开
下面这组检查可以同时覆盖两种解释，并按结果分流。假设故障时段为T，百度抓取量在T之后下降。
- 导出边缘节点在T时段的访问日志，筛选百度蜘蛛UA，统计状态码分布。如果5xx或超时占比明显上升，偏向解释一；如果状态码以200为主，偏向解释二。
- 从外部网络用百度蜘蛛UA请求边缘节点，记录返回状态码和响应体。如果复现错误，解释一成立；如果返回200，继续下一步。
- 对比边缘返回的HTML与源站返回的HTML。如果内容不一致，解释二成立；如果内容一致，说明边缘侧当前正常，问题可能已经恢复或出在其他环节。
- 检查源站日志在T时段是否收到来自边缘回源IP的请求。如果源站没有收到对应请求，解释一更可信；如果源站收到了且返回200，但边缘返回给百度的不是这个内容，解释二更可信。
这个顺序的作用是：先用状态码把范围缩小，再用内容比对确认是否涉及索引层面的影响。如果第1步就发现大量5xx，就不需要做内容比对，直接查边缘连通性；如果第1步状态码正常，第3步的内容比对才是决定性的。
保留证据时容易犯的三个错误
第一个错误是只保留源站日志。源站日志只能证明源站收到了什么、返回了什么，不能证明百度最终拿到了什么。边缘节点是百度蜘蛛和源站之间的实际接触点，边缘侧的证据不可替代。
第二个错误是只截取状态码，不保存响应体。状态码200配合一个空白页或错误页，在收录层面和5xx的后果可能不同，但都需要内容证据才能判断。保存响应体时注意记录字节数和关键字段，不要只写“返回正常”。
第三个错误是用robots.txt的抓取限制来代替索引移除。robots.txt只控制抓取，不控制已收录URL的移除；如果边缘异常期间百度已经抓到了错误内容并建立了索引，后续修复边缘后，旧索引不会因为robots.txt而立即消失。这时需要保留的是边缘修复前后的内容对比证据，以及百度侧抓取痕迹的变化记录，而不是把robots.txt当作清理手段。
证据齐了之后怎么决定下一步
如果证据指向解释一，下一步是修复边缘节点的连通性或调整限流、WAF规则，并在修复后从多个网络位置重新请求，确认百度蜘蛛UA能稳定拿到200。修复动作的结果会直接决定是否需要进一步检查源站：如果边缘恢复后百度抓取量回升，源站侧通常不需要额外处理；如果边缘恢复后抓取量仍不回升，才需要检查源站是否有其他限制。
如果证据指向解释二，下一步是清理边缘缓存中受影响的URL，并确认回源内容与源站一致。清理后同样要从边缘侧请求并保存新的HTML，与源站比对。这个动作的结果会影响索引恢复的判断：内容一致后，百度重新抓取到的才是正确版本；但已收录的错误版本何时更新，取决于百度后续的抓取和索引处理，不能仅凭一次缓存清理就断定收录会立即恢复。
无论哪种情况，证据保留的时间窗口应覆盖故障发生前后各一段，至少包含故障时段、修复动作时刻、修复后的一次完整验证。这样在后续排查中才能回答“修复前后百度分别拿到了什么”这个核心问题。
