很多人盯着收录数找原因，最后发现问题不在页面本身，而在服务器给蜘蛛的那几百毫秒里。抓取是一个有预算、有超时、有并发上限的动作，页面响应慢，蜘蛛能带走的页面就少，能进入索引的页面自然也会少。

蜘蛛抓一个页面的时间账

蜘蛛访问一个 URL，大致要经历：建立连接、等待首字节（TTFB）、下载响应体、再决定要不要抓页面里的其他资源。其中对抓取效率影响最大的通常是连接和 TTFB 这两项。TTFB 从 200ms 涨到 1.5s，单次抓取占用的时间可能多出好几倍，而蜘蛛在同一个站点上的并发数和总时长都是有限的。

结果就是：同样的抓取配额，能覆盖的 URL 数量变少。表现往往是重要页面更新后迟迟不重抓，新页面要排很久的队才被第一次发现。

多慢算慢：几个可以参考的刻度

• TTFB 稳定在 500ms 以内：通常不会成为抓取瓶颈。
• TTFB 长期在 1s 以上：抓取量容易被压住，页面量大的站点更明显。
• 单页完整响应经常超过 5 到 10 秒：容易踩到蜘蛛的超时阈值，这次抓取基本白跑。
• 大量请求超时或返回 5xx：除了浪费额度，还可能让蜘蛛主动降低对这个站点的抓取频率。

这些只是经验刻度，不是标准答案。真正的判断依据，应该是你自己日志里的响应时间分布和抓取频次变化。

超时和 5xx 会被怎么记账

超时不等于 404。404 是明确的“这个地址没有内容”，蜘蛛一般会把这条记录划掉；超时和 5xx 是“这次没拿到，下次再看”，蜘蛛会保留这个 URL 并稍后重试。区别在于，重试同样要消耗抓取额度。

不同状态码的差别

• 503 加 Retry-After：用于计划内维护，明确告诉蜘蛛什么时候再来，相对友好。
• 500 / 502 / 504：通常是故障信号。持续大量出现时，蜘蛛会判断站点不稳定并放缓抓取。
• 429：明确的限流响应，蜘蛛一般会退让，但返回 429 的页面本身也没有真正被抓到。

如果站点确实承受不住抓取压力，用 robots.txt 的 crawl-delay，或在服务端按 UA 限速，都比让请求一个个超时要可控得多。

先排查什么

• 数据库慢查询：列表页、详情页、搜索结果页的查询耗时分开统计，不要只看平均值。
• 外部依赖：接口调用、CDN 回源、第三方脚本阻塞了首字节输出。
• 缓存命中率：缓存穿透或频繁失效，会让每个请求都回到源头重新计算。
• 抓取高峰是否撞上业务高峰，日志里的耗时是否同步变长。
• 是否有页面在抓取时触发大量关联查询，比如一次拉取几百条推荐内容。

从日志里怎么确认

把蜘蛛访问日志按状态码分组，统计一段时间的分布：2xx、3xx、4xx、5xx 各占多少，平均响应时间和 P95 响应时间分别是多少，然后对比同期抓取频次的变化。如果 5xx 或超时比例上升的同时抓取频次下降，基本可以确认是稳定性拖累了抓取。

抓取量下降不一定就是服务器慢，也可能是站内 URL 膨胀、参数泛滥或内链结构变化。但服务器指标是最容易量化的一个，值得先排除掉。

别把收录数当成唯一指标

响应速度改善后，抓取频次往往先回升，收录数随后才有变化，中间还隔着页面质量判断和重复内容筛选。把服务器指标、抓取日志、索引覆盖率放在一起看，比盯着一个数字反复猜要靠谱得多。