多数人只盯着 HTML 页面有没有被抓，很少留意同一批抓取里，蜘蛛还会去拿页面引用的 CSS、JavaScript、图片和字体文件。这些资源不参与“收录”，但会实实在在占用抓取额度、带宽和服务器连接数。
蜘蛛为什么要抓这些资源
搜索引擎要判断页面长什么样、内容是否完整，就需要把页面渲染出来。渲染依赖样式表和脚本，所以抓取 HTML 之后，往往还会按页面里的引用地址再去请求 CSS 和 JS。图片通常不是渲染必需，但在判断图片与页面主题相关性、生成缩略图等场景下也可能被请求。
换句话说，一次“页面抓取”在后端常常对应好几个 HTTP 请求。如果页面引用了十几个资源，实际产生的请求量可能是页面数的几倍。
资源抓取上常见的几个坑
- 资源地址带参数或时间戳：每次发布都生成新地址，蜘蛛会当成新资源反复抓取，旧地址还留在记录里。
- CSS、JS 被 robots.txt 挡住：抓不到样式和脚本，渲染出来的页面可能缺内容，判断容易出错。
- 资源放在第三方域名：跨域请求由别人的服务器承担，但对方响应慢或做了限速，渲染就会被拖住。
- 资源地址由脚本动态拼接：第一轮抓取时地址可能还不存在，回报 404，之后要靠重新发现。
- 体积过大的打包文件：单个文件从几百 KB 到几 MB，抓取和渲染都要花更长时间。
从服务器日志里看资源被抓的情况
在日志里筛 css、js、png、jpg、woff 这类后缀，能看到资源被抓的次数和返回码。几个判断点：
- 资源请求数远大于 HTML 请求数，说明页面里外链资源偏多，可以考虑合并或精简。
- 同一资源出现大量不同参数地址，多半是版本号或时间戳的写法有问题。
- 资源返回 403、404 的比例偏高，说明有地址写错，或者目录被规则误挡。
- 资源响应时间明显高于 HTML，说明静态文件没有走缓存或 CDN。
服务器稳定性：叠加起来的那部分压力
资源请求通常比 HTML 更容易命中缓存，但如果站点没做静态资源缓存，每个请求都会打到源站。抓取高峰时，HTML 与资源请求叠在一起，连接数和带宽会同时上涨。表现往往是首字节变慢、静态文件偶尔超时，进而影响整站的抓取节奏。
比较稳的做法是把静态资源交给 CDN 或反向代理，设置合理的缓存头，让重复请求不落到源站。源站只处理真正需要动态计算的部分，抓取压力会平缓很多。
抓取额度是整站共享的。资源请求多了，留给新页面和更新页面的份额就少了，这是不少站点感觉“蜘蛛来得少了”却找不到原因的地方。
几条实用建议
- 给静态资源加版本号时用文件内容哈希，写在文件名里，而不是每次都换查询参数。
- 确认 CSS、JS 不被 robots.txt 拦截，也别在资源目录上误加限制规则。
- 合并压缩脚本和样式，减少请求数量；图片按实际显示尺寸输出，别把大图缩着用。
- 静态资源统一走 CDN，源站日志里就能干净地看出 HTML 的抓取情况。
- 定期看资源被抓的返回码分布，把长期 404 的地址清理掉。
资源抓取本身不是问题，问题在于它是否被无意义地放大。把资源地址稳定下来、请求数量压下去、缓存扛住重复请求，蜘蛛花在整站上的时间才更划算。