很多人在看抓取日志时，只关注状态码是 200 还是 404，却忽略了一种中间状态：请求已经进来了，但响应还没发完就断了。搜索蜘蛛对单个 URL 的抓取是有时间限制的，入口页一旦响应太慢，这次抓取就可能被记成失败或只完成一半，里面的链接自然也未必会被继续解析。
搜索蜘蛛的等待是有限的
搜索引擎不会无限制地等一个页面返回。抓取器通常设有连接超时和读取超时，超过阈值就主动断开连接，把这次抓取记为异常。不同引擎、不同抓取优先级下的阈值并不相同，官方也不会公开具体秒数，所以不要按某个固定数字去卡，而应该关注自己的响应时间是否稳定、是否有长尾的慢请求。
入口页变慢的常见原因
- 源站动态逻辑重：入口页每次抓取都要查库、调接口或做模板渲染，没有缓存兜底。
- 带宽与并发被占满：入口页和主站共用出口，正常用户流量高峰时抓取请求排在后面。
- CDN 回源慢：边缘节点等待源站响应，回源链路抖动会直接体现为抓取超时。
- WAF 或安全组件挑战：对首次请求下发 JS 校验或跳转验证页，抓取器不会执行这些脚本。
- DNS 与 TLS 阶段耗时：多线路解析到不可用节点，或证书链不完整，连接建立阶段就已消耗大量时间。
从日志判断“超时”而不是“被拒”
- 请求记录存在，但响应字节数为 0 或明显小于正常页面。
- 状态码出现 499、504 一类由服务端或网关侧中断产生的记录。
- robots.txt、sitemap 这类小文件抓取正常，只有大体积或动态入口页异常。
- 同一路径的抓取间隔被拉长，且每次记录都不完整，像是反复尝试又反复失败。
被拒通常是明确的 403、429，而超时更像是“抓了但没抓完”。两者在处理思路上完全不同：前者要查规则和限流，后者要查性能和链路。
一套可落地的排查顺序
- 先放一个纯静态、体积很小的测试入口页，观察是否稳定被抓取。如果它也超时，问题多半在网络或网关层。
- 逐步加回模板、查询和接口，找出让响应时间抬升的那一段。
- 从不同地区、不同运营商去解析和访问入口页，对比首字节时间，排除单点线路问题。
- 查看 CDN 和 WAF 日志，确认触发挑战、回源失败或回源超时的占比。
- 最后回到服务端，看慢查询日志、连接数、并发限制和工作进程是否被打满。
优化方向
- 入口页尽量静态化或加短时缓存，避免每次抓取都走完整动态逻辑。
- 控制单页响应体积，把非必要的图片、字体等资源移出关键路径，先输出 HTML。
- 检查是否对抓取来源单独做了限速或验证，误伤会表现为持续超时。
- 修复后观察抓取是否恢复。若恢复，说明此前是速度问题而不是内容问题。
不要指望靠“熬过搜索引擎的耐心”来解决问题。慢响应会被记录，抓取预算也是有限的，长期超时会让入口页在抓取队列里被降权处理。
抓取速度不是孤立的性能指标，它决定的是同一个抓取窗口内能走完多少 URL。与其纠结某一次抓取为什么失败，不如把入口页的响应时间稳定在可控范围内，再看日志里的抓取条数和覆盖路径有没有变化。