翻服务器日志的时候，多数人盯的是 HTML 的状态码和抓取频次，很少注意同一时间还有另一类请求：图片、CSS、JavaScript、字体文件，有时还有站内接口。它们由蜘蛛在渲染页面时顺带发出，不直接对应任何一个 URL 的收录结果，但确实占着服务器的连接和带宽，也让日志里的抓取画像变得不那么干净。
一次页面抓取，通常不止一个请求
搜索引擎在判断页面内容时，往往需要把页面渲染出来。这意味着抓一次 HTML，背后可能跟着若干个 CSS、JS 和图片请求。移动优先索引普及之后，渲染这一步变得更常规，资源请求也就跟着变多。对内容简单的小站，这部分开销可以忽略；但对图片密集、前端依赖较多的站点，资源请求数可能是 HTML 请求数的好几倍。
哪几类资源最容易被反复抓
- 带随机参数的图片：给图片 URL 拼上时间戳或随机数，等于每次生成一个新地址，缓存无法命中。
- 版本号频繁变化的静态文件：如果每次发布都改文件名又没有合理的缓存策略，蜘蛛每次访问都要重新下载。
- 未设置缓存的公共库：被全站引用的样式和脚本，如果没有缓存头，每个页面渲染都会带来一轮请求。
- 已被删除但仍有引用的资源：页面里还留着指向旧文件的链接，蜘蛛会一遍遍撞上 404。
这些请求会带来什么影响
最直接的是服务器负载。资源文件的体积通常比 HTML 大，并发请求叠加上去，带宽和连接数占用会明显上升。其次是日志噪音：如果按请求总数统计流量，资源请求会把页面抓取的真实情况稀释掉，让你误判蜘蛛对某个目录的兴趣。此外，当站点本身响应偏慢时，大量资源请求会让整体抓取节奏更吃力。
可以做的几件事
- 给静态资源设置较长的缓存时间，并用内容哈希写进文件名，让更新和缓存同时成立。
- 图片 URL 保持稳定，不要附加随机参数；需要多尺寸时用固定命名规则，而不是查询串。
- 清理页面里指向已删除资源的引用，别让蜘蛛反复拿到 404。
- 减少不必要的第三方脚本，能自托管就自托管，并固定版本。
- 不要为了省资源请求去 robots.txt 屏蔽 CSS 和 JS，这会直接影响页面渲染结果。
从日志里怎么看资源抓取
按文件扩展名分组，统计一段时间内各类资源的请求数量，再和页面请求数做个对比。重点看两件事：一是同一个资源在内容没有变化时被请求了多少次，如果回回都是 200 而不是 304，说明缓存没起作用；二是 404 资源的请求量，这通常意味着页面里还有坏链。把这两项降下来，抓取日志会清爽很多。
资源请求不一定算在抓取额度的账上，但它确实是你服务器的实际支出。把它当成抓取体验的一部分来管理，比事后从日志里找原因要省事。