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

网站如何被百度收录：源站正常而边缘节点异常时应保留哪些证据

先给结论：这类分歧通常不是“收录失败”本身，而是源站与边缘节点对同一 URL 返回了不同内容或不同状态码。要把它变成可核对的项目，至少保留三组证据：同一时刻的源站响应、边缘节点响应，以及百度抓取时命中的那一个响应。只保留其中一组，后续动作很容易做反。

先把“正常”拆成可核对的三层

团队里说“源站正常”，往往指服务器本身没宕机、发布流程跑通了；说“边缘异常”，可能指 CDN 回源失败、缓存了旧页面或对百度 UA 返回了验证页。这两句话可以同时成立，因为观察对象不同。

把资料整理成三层：

• 源站直连响应：绕过边缘节点，直接请求源站 IP 或回源地址，记录状态码、响应头、正文摘要。
• 边缘节点响应：通过正式域名请求，记录命中的节点、缓存状态、返回内容是否与源站一致。
• 抓取侧响应：从百度搜索资源平台的抓取诊断或日志中，确认百度实际拿到的状态码与内容片段。

三层都指向同一个 URL、同一时间窗口，分歧才有比较价值。否则“我这边正常”只是各自看到了不同层。

保留证据时，先固定变量再取样

边缘节点异常常带随机性：不同地区、不同运营商、不同时间命中不同节点。取样前先固定变量，否则证据无法复核。

1. 选定一个具体 URL，不要用首页代替问题页。
2. 固定请求时间窗口，例如同一小时内多次取样，并记录时间戳与时区。
3. 固定请求方式：是否带百度 UA、是否带 Referer、是否走 HTTPS。
4. 每次取样同时保存源站直连与边缘域名两组结果。

一个可执行动作：对同一 URL 在边缘域名下连续取样若干次，若其中部分返回 200、部分返回 403 或验证页，说明边缘层存在不一致，而不是源站整体不可用。这个结果会直接决定下一步是查缓存规则还是查源站发布。

哪些证据能区分“缓存旧内容”和“回源被拒”

两种原因的后续处理完全不同，可用响应头与正文特征区分：

• 缓存旧内容：边缘返回 200，但正文是旧版本；响应头里缓存命中相关字段与源站不一致；刷新缓存后短时恢复。
• 回源被拒：边缘返回 403、5xx 或验证页；源站直连正常；边缘日志显示回源请求被拦。
• UA 差异：普通浏览器正常，带百度 UA 时返回验证页或空内容。此时要同时保存两种 UA 的响应，不能只留一种。

注意：robots.txt 的抓取限制不等于可靠的索引移除，它只能约束合规抓取，不能替代状态码与内容核对。站点地图也不保证收录，它只是发现线索之一。HTTPS 同样不保证内容一定被正确返回，边缘层仍可能返回验证页或旧缓存。

把分歧转成项目里的核对项

当多个角色对同一事实理解不同时，不要继续争论“到底正不正常”，而是把结论写成可勾选的核对项：

• 同一 URL 的源站直连状态码与正文摘要。
• 同一 URL 的边缘响应状态码、缓存状态与正文摘要。
• 百度抓取侧实际命中的状态码与内容片段。
• 取样时间、请求 UA、是否带 Referer、是否走 HTTPS。
• 若存在差异，记录差异首次出现的时间点与对应变更。

假设一个场景：某页面源站直连返回 200 且正文为新版本，边缘域名在部分节点返回旧版本缓存，百度抓取侧拿到的是旧版本。此时若只依据源站正常就判断“无需处理”，抓取侧仍会持续拿到旧内容；若只依据边缘异常就回滚发布，又可能误伤已经正确的源站。先补齐三组证据，再决定是刷新缓存、调整回源规则，还是回滚发布。

需要说明的是，抓取量或某项统计短时归零，并不能单独证明边缘异常就是唯一原因，也可能是抓取配额调整、URL 结构变化或日志口径变化。因此证据要能相互印证，而不是只靠一个指标下结论。不同搜索引擎对边缘返回内容的处理方式需要分别核查，百度语境下应以百度抓取侧的实际响应为准。

把上述证据固定成每次变更都留档的核对项，下一次出现“源站正常、边缘异常”的分歧时，就能直接比较同一 URL、同一时间窗口的三层响应，而不是重新争论谁看到的才算事实。