蜘蛛取一个页面，不止取一个文件
很多站点把抓取理解成“蜘蛛来一次，取走一个 HTML”。实际链路中，蜘蛛解析 HTML 后还会请求页面引用的 CSS、JS、图片、字体等资源。搜索引擎蜘蛛对单个站点的并发连接数是有限的，这些附加请求会和 HTML 争抢同一批连接。当静态资源体积大、数量多、响应慢时，真正决定内容的那份 HTML 就会被排在后面。
连接被占满时，日志会是什么样
比较典型的现象是：蜘蛛访问 HTML 的次数没降，但单次耗时明显变长；同一时间段里，资源 URL 的请求量远高于页面 URL；抓取总时间被拉长，单位时间内实际覆盖的页面数反而下降。这不是蜘蛛“变懒”，而是它在等资源。
另一种情况是资源返回 404 或超时。蜘蛛会重试，重试同样占用连接，进一步挤压 HTML 的抓取窗口。
几个可以调整的方向
- 合并与压缩静态资源：减少请求数量往往比单纯减小单个文件体积更直接，尤其是小图标、零散脚本。
- 给静态资源设置长效缓存：带指纹的静态文件可以返回较长的 Cache-Control 和 ETag，蜘蛛二次抓取时通过协商复用，不必重复下载全量内容。
- 把资源放到 CDN 或独立域名：连接从主域分摊出去，HTML 的抓取窗口会宽松一些；但要确认 CDN 不拦截蜘蛛 UA，也不要让资源域变成新的瓶颈。
- 首屏内容别依赖延迟加载：正文图片懒加载、内容靠滚动触发，蜘蛛可能拿不到；至少让文本内容在 HTML 里直接可见。
- 清理无意义资源：埋点、统计、废弃组件引用的脚本如果长期返回 404，会在日志里持续消耗抓取次数，值得清理，而不是靠屏蔽了事。
服务器侧的稳定性同样是变量
蜘蛛的抓取节奏会参考服务器的响应情况。首字节时间波动大、错误率高时，它会主动放慢，甚至暂停对该目录的回访。这时候即使你把资源优化到位，恢复也需要时间。带宽被其他业务占满、源站临时扩容失败、防火墙对高频 IP 做了限速，都会让蜘蛛的连接被重置。稳定的响应时间和可控的错误率，是抓取效率的基础。
把抓取效率全部归因于“蜘蛛不愿来”，往往会漏掉连接层的问题。先看服务器日志里的响应时间分布，再谈内容。
怎么验证调整是否有效
- 在日志里按蜘蛛标识统计页面 URL 与资源 URL 的请求比例，观察一段时间的变化。
- 关注 HTML 请求的平均响应时间，而不是站点整体平均响应时间。
- 看单位时间内被抓取的不同 URL 数量，这个数字比总请求数更接近真实覆盖。
- 调整一次只改一个变量，否则无法判断是哪一项起了作用。
抓取本质上是一次资源调度：连接、带宽、响应时间都是有限的。让蜘蛛用最少的连接拿到最有价值的内容，比一味追求“蜘蛛来得更多”更实际。