抓取本身是有时间预算的
搜索蜘蛛抓取一个 URL 时，不会无限等待。它大致会分配一个时间预算，从建立连接、等待响应，到读取正文和里面的链接，超出就结束这次抓取，留到以后再说。入口页如果响应慢、传输慢，最先受影响的就是这次抓取能否完整读完。
需要说明的是，不同搜索引擎、不同抓取设备的预算并不一样，也没有公开的固定秒数。所以这里讨论的是趋势，不是一条可以卡着用的及格线。
慢在哪一步，后果并不相同
1. 建立连接和首字节时间过慢
如果服务器在很长一段时间里都没有返回状态码，蜘蛛可能在收到响应之前就断开。这种情况在日志里常常表现为请求有记录、但没有完整的响应状态，或者反复重试。
2. 正文传输太慢或体积过大
响应头正常，但 HTML 体积很大、又没有开启压缩，蜘蛛读到一半就可能停下。此时页面后半部分的链接不会被处理，放在后面的目标 URL 也就等于没写。
3. 链接依赖脚本渲染
普通的图片、样式、字体拖慢加载，一般不影响链接发现；但如果目标 URL 是脚本执行后才插入到页面里的，脚本没跑完或超时，链接就不会出现。
链接的位置会被速度问题放大
同样是慢，链接放在 HTML 靠前和靠后，结果差别很明显。前面是一大段内联脚本或样式、目标链接堆在后面的入口页，在慢速场景下更容易出现“页面被抓了、链接却没被发现”的情况。
- 把目标链接尽量放在 HTML 靠前的位置
- 减少 head 里的阻塞脚本和大量内联样式
- 避免依赖脚本拼接后再渲染链接
- 控制单页 HTML 体积，重复结构不要硬堆
慢响应还会影响之后几次抓取
一次超时通常不会永久封死入口页，但可能带来连锁反应：蜘蛛对这个地址的抓取频次下降，重试间隔被拉长，同一批入口页的发现节奏也会整体变慢。如果同一台服务器上的多个入口页都很慢，表现会更集中。
慢不一定等于蜘蛛不来，但会让它在有限的抓取预算里，更少地读完你的页面。
怎么判断问题是速度引起的
- 看服务器日志里蜘蛛请求的响应时间，重点关注明显偏长和没有正常状态码的请求。
- 用命令行工具记录首字节时间和总耗时，例如比较 time_starttransfer 与 time_total。
- 把同一批入口页按快慢分成两组，观察目标 URL 被抓取的比例是否有明显差异。这只是观察，不能当成严格的因果结论。
- 临时精简某个入口页，再对比它前后几天的抓取记录。
可以着手做的几件事
- 开启 gzip 或 brotli 压缩，减少正文传输量。
- 入口页走缓存或 CDN，避免每次请求都回源做重查询。
- 把数据库查询、外部接口调用从入口页的渲染路径里移出去。
- 保持稳定返回 200，避免长时间 5xx 或反复跳转链。
- 如果入口页是程序动态生成的，注意生成逻辑本身耗时，别让它比网络传输还慢。
两个容易走偏的方向
一种是觉得“内容越多越好”，把大量脚本、统计代码、外部资源全塞进入口页，结果把抓取预算消耗在无关内容上；另一种是矫枉过正，把入口页做成几乎空白的跳转页，链接虽然靠前，但页面本身缺乏可用信息，抓取价值不高。
比较稳妥的做法是：让入口页保持轻、快、稳定，把目标链接放在显眼且靠前的位置，然后用日志持续观察目标 URL 的发现情况，按数据调整，而不是一次改完就当作已经解决。