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

网站不被收录原因，源站正常而边缘节点异常时应保留哪些证据

先给结论：源站返回正常而边缘节点异常时，优先保留能证明“同一 URL 在不同节点上响应不同”的原始证据，而不是先改 robots.txt 或提交删除请求。判断取舍的核心条件是异常是否可复现、是否只影响部分节点；可复现时保留对照证据再动手，不可复现时先做低频监测并记录时间点，避免把偶发抖动当成站点级故障。

两种做法成立的条件与代价

第一种做法是立即在源站侧做拦截或屏蔽，让抓取请求只走源站。它成立的条件是：你已经能稳定复现边缘节点的异常响应，并且确认异常响应会返回错误状态码或空内容。代价是边缘节点承载的缓存、压缩和地域就近能力同时失效，抓取压力全部回到源站，如果源站容量有限，可能把局部问题放大成整体不可用。

第二种做法是先保留证据、暂不改动线上配置，只对异常节点做定向观察。它成立的条件是：异常间歇出现，或只影响少数地域节点，站点仍能通过其他节点正常响应。代价是异常期间部分抓取请求可能持续拿到坏响应，收录恢复被推迟。选择依据不是哪种做法更“正确”，而是异常的可复现程度和源站的承载余量。

必须保留的四类原始证据

无论选哪种做法，下面这些证据都应在改动配置之前留存，因为一旦调整节点或回源策略，现场就无法还原。

• 同一 URL 在源站直连与边缘节点分别请求的完整响应头，重点是状态码、Content-Length、Content-Type、缓存相关字段和回源标识字段。
• 带时间戳的响应体片段对比。若边缘节点返回空 body 或错误页，保存其前若干字节即可，不必保存整页。
• DNS 解析记录与节点归属。记录请求实际落到哪个 IP 或哪个边缘集群，这是区分“源站问题”和“节点问题”的关键。
• 抓取工具或日志中该 URL 的请求记录，包括请求时间、来源 IP 段、返回状态。若日志显示同一时段源站直连正常、边缘请求异常，这条对照本身就很有价值。

实施动作上，建议先固定一个测试 URL 和一个对照 URL，在同一分钟内分别向源站和边缘节点发起请求，把两组响应并排保存。这个动作的结果会直接决定下一步：如果差异稳定出现，可以进入节点侧排查；如果两组响应一致，说明问题不在边缘，应转向别处。

一个注明假设的短例子

假设某站点源站对 /a 返回 200 且正文完整，而某边缘节点对同一路径返回 200 但正文为空。此时若直接提交 URL 删除请求，等于把“节点返回空内容”误判为“页面已失效”，反而可能延后恢复。更稳妥的顺序是：先保存两边的响应头与 body 片段，再确认该节点是否只影响这一类路径，最后才决定是临时回源还是等待节点修复。这个例子的数字仅用于说明对照方法，不代表任何真实站点的表现。

例外与容易误判的信号

有些现象看起来像边缘异常，其实另有合理解释。抓取量或请求量在某个时间段归零，可能是抓取调度正常波动、日志采样丢失或统计口径变化，不能单独作为节点故障的证据。同样，边缘节点返回 200 也不代表内容正确，空 body、被替换的跳转页、错误的编码都可能在 200 状态下出现，所以状态码必须和响应体一起看。

还要注意，robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录，这两点在排查时容易被当成快捷手段。若异常节点返回的是 5xx，先确认它是节点自身错误还是回源超时被包装成 5xx，两者的处理方向不同。不同搜索引擎对边缘异常响应的处理方式也需分别核查，不要用一家的表现推断另一家。

证据齐备后怎样决定下一步

当对照证据显示差异稳定、且源站余量充足时，可以临时让异常节点回源或摘除该节点，同时继续记录恢复后的响应，确认抓取请求是否回到正常状态。当差异不稳定或源站余量紧张时，应先保持配置不动，用低频定时请求持续采样，等异常模式清晰后再决定。无论哪种路径，保留改动前后的响应对照，才能在下一次出现类似现象时快速区分是节点问题还是源站问题，而不是重新从零排查。