很多站点排查抓取问题，习惯先从内容、内链和 Sitemap 找原因，却忽略了一个更前置的条件：蜘蛛每次请求都得先拿到一个正常的 HTTP 响应。服务器端的抖动会直接改变蜘蛛对整站的处理方式，而且影响往往比想象中更持久。
四类响应，四种后果
从蜘蛛的角度看，一次请求的结果大致可以分成四类，处理逻辑差别很大：
- 404 与 410：明确告诉你页面不存在。短期会减少这类 URL 的抓取，长期会把它们从待抓列表里清出去。这属于信息有效，不算故障。
- 500、502、503、504：服务器端出错。蜘蛛无法判断是临时故障还是永久问题，通常先标记为待复查，过一段时间再试。
- 连接超时：请求发出去了，但久久没有响应。对蜘蛛来说这和 5xx 类似，只是它连错误码都拿不到。
- 连接被中断：响应头或部分内容返回后连接断开。这种情况最尴尬，蜘蛛拿到的是一份不完整的内容。
关键在于：4xx 是有效信息，5xx 和超时是无效信息。无效信息堆积多了，蜘蛛会认为这台服务器不稳定，从而主动降低抓取频率。
降频之后，恢复比下降慢得多
抓取速度被下调，不是当天出问题、第二天就能恢复的。蜘蛛通常需要连续观察到一段时间的稳定响应，才会逐步把抓取量提回来。有些站点会发现，故障持续了几小时，但抓取量的恢复花了两三周。
更麻烦的是连锁反应：抓取频率降低，意味着新 URL 被发现得更慢、更新页面的复查间隔被拉长、本来能抓完的页面抓不完。这时候如果再去调 Sitemap 或者加内链，效果会被服务器的下限压住。
内容层面的优化决定上限，服务器稳定性决定下限。当下限被压低时，上限的调整几乎看不出来。
几个容易被忽略的抖动来源
- 数据库慢查询：列表页、搜索页在高峰期响应时间从几百毫秒涨到几秒，蜘蛛刚好撞上就被记为超时。
- CDN 回源超时：边缘节点正常，但回源失败，蜘蛛拿到的是 5xx，而你在源站日志里可能什么都看不到。
- 限流策略过严：把正常蜘蛛和异常流量一起限掉，返回 429 或 503。
- 发布与重启：每次部署都有一小段时间返回 502，如果部署频繁，这个抖动会被持续记录。
- 备份与其他抓取工具：本地备份任务和第三方采集占满带宽，蜘蛛请求排队超时。
日常该看哪些信号
- 服务器日志里 5xx 的比例，按小时看，而不是按天看。
- 响应时间的 P95、P99，而不是平均值，平均值会把高峰掩盖掉。
- 抓取日志中的抓取频率曲线，看它在故障之后有没有明显下台阶。
- Sitemap 中 URL 的抓取覆盖变化，判断是不是有一批页面长期抓不到。
- 部署、重启、备份的时间点，和日志异常时间是否重合。
把稳定性做成可预期的事
不必追求零故障，但要追求故障时有明确行为：
- 计划内维护返回 503 并带上 Retry-After，比直接断连更友好。
- 为蜘蛛来源设置合理的白名单与限流阈值，不要和其他流量共用一套规则。
- 把数据库慢查询和回源失败纳入监控，不要只看源站返回的状态码。
- 部署时采用平滑重启，避免每次发布都产生一批 502。
抓取优化里，链接结构、Sitemap 和内容质量都重要，但它们都建立在蜘蛛能稳定拿到响应这个前提上。先把这个前提守住，再谈其他调整，顺序会顺很多。