做蜘蛛池和站点运营时，常遇到一种情况：入口页本身没问题，目标 URL 也能正常访问，但服务器响应很慢——首字节要好几秒才返回，或者偶尔直接超时。这时大家往往只盯着“蜘蛛来没来”，却忽略了另一个更实际的问题：蜘蛛到底有没有把这一页读完。
抓取单个 URL 是有时间预算的
搜索爬虫访问一个地址时，会给自己设一个等待上限。建立连接、握手、等待首字节、下载正文，都在这个预算之内。超过阈值，爬虫通常不会一直挂着死等，而是断开连接、把这次请求记成异常，转去做别的任务。所以“抓取失败”不一定表现为 5xx，很多情况下日志里只留下一次不完整的请求或一条超时记录。
同样是慢，结果并不一样
- 连接阶段就超时：页面根本没被读到，里面的链接自然无从发现。
- 首字节很慢但最终返回 200：爬虫可能仍拿到完整 HTML，但这次的响应耗时会被记录下来，影响之后对该站点的抓取节奏。
- 正文传到一半断开：拿到的是被截断的 HTML，后半部分内容根本没到本地。
- 时快时慢：最麻烦的一种，抓取成功率不稳定，排查时也很难复现。
只抓到半截 HTML，链接会被漏掉吗
会。爬虫解析链接依赖的是已经下载到的那部分 HTML。如果响应在文档前半段就断了，位于后半部分的链接很可能不在这一轮的解析范围内。这也是为什么有些入口页明明写了目标 URL，日志里却始终没有对目标地址的抓取记录——不是链接写错了，而是那一页根本没被读完整。
把链接放在前面，能降低这种风险
在页面结构上把关键链接尽量靠前，不要依赖后面的脚本渲染或异步加载，能在响应被截断时提高被发现的机会。这不是万能方案，但比全塞在页尾要稳一些。
入口页慢和目标 URL 慢，要分开看
入口页慢，影响的是“链接能不能被发现”；目标 URL 慢，影响的是“发现之后能不能被抓到”。两者的表现都是日志稀疏，但方向完全不同。排查时先确认是哪一端的问题，否则容易在错误的方向上反复折腾。
可以按这几步排查
- 看服务器访问日志里，是否存在大量耗时异常或未完成的请求记录。
- 检查页面是否体积过大，或在前部塞了太多阻塞脚本、同步接口调用。
- 检查后端是否存在慢查询、外部资源拖慢首字节返回。
- 确认 CDN 与回源是否正常，回源异常会明显放大延迟。
- 从不同网络位置多测几次，区分偶发抖动和长期常态。
优化方向
- 优先保证首字节速度，能静态化就静态化，减少动态拼装。
- 把需要被发现的链接放在 HTML 靠前的位置，减少对前端渲染的依赖。
- 给服务端设置合理的超时和降级策略，避免请求长时间挂起。
- 控制单页链接数量和页面体积，别让一页承担过多内容。
- 调整后持续观察一段时间，不要指望改一次就立刻恢复。
慢响应不只是访问体验问题，它会实打实决定爬虫能把页面读到什么程度。没被抓到的内容，对搜索而言约等于不存在。
总的来说，入口页响应慢或频繁超时，通常不会直接导致“蜘蛛从此不来”，但很容易造成“蜘蛛没读全”，从而漏掉页面里的目标 URL。把首字节速度和稳定性做扎实，往往比反复提交 URL 更有效。至于最终是否被收录，还取决于内容本身和其他多种因素，本文只讨论抓取这一环。