蜘蛛抓取的不只是 HTML
很多人查看服务器日志时，只盯着 HTML 页面的请求，看到一条 GET /article/123 就算完成了一次抓取。但现代搜索引擎的抓取通常分两步：先取回 HTML，再根据 HTML 里的引用去请求必要的资源。第二步经常被忽略，却直接影响页面能不能被正确理解。
哪些资源会进入抓取请求
蜘蛛对不同类型的资源态度并不一致，大致可以这样理解：
- CSS：一般会被请求。它决定页面结构，缺失时渲染结果可能和用户看到的不一样。
- JS：与渲染相关的脚本会被请求，尤其是同步加载、位于首屏、参与生成链接的脚本。
- 图片：主要图片通常会被抓，但优先级低于 CSS 和 JS，体积很大的图片不会每次都取。
- 字体、统计脚本、广告位：多数情况下不取或很少取，除非它们阻断了渲染。
需要强调的是，资源抓取和页面抓取往往使用不同的配额。资源请求不会直接吃掉页面的抓取预算，但会拉长单次渲染的时间，间接影响蜘蛛在同一站点上的抓取效率。
三种常见的资源问题
1. 关键 CSS 或 JS 被 robots.txt 屏蔽
为了“省流量”而屏蔽 /static/、/assets/ 这类目录是很常见的做法。结果是蜘蛛拿到的 HTML 缺样式、缺脚本，渲染出来的页面可能接近空白，链接也点不出来。屏蔽静态目录之前，先确认这些文件是否参与了页面渲染。
2. 懒加载图片只写了 data-src
把真实地址放在 data-src、data-original 里，等 JS 滚动时再替换 src，用户端体验没问题，但蜘蛛未必会触发滚动。可考虑给首屏图片保留正常的 src，或者用 noscript 提供兜底地址。
3. 长期 404 的资源文件
页面引用的图片、脚本被删除后返回 404，每次渲染都会产生一串失败请求。数量少时影响有限，成百上千个页面都引用同一个坏文件时，就是在持续消耗抓取资源。
降低无效资源请求的做法
- 合并压缩 CSS 与 JS，减少单页的请求数量。
- 给图片设置明确的宽高，避免布局抖动引发的额外计算。
- 把首屏必需的资源内联或前置，非关键脚本延迟加载。
- 定期检查资源文件的可访问性，及时清理失效引用。
怎么验证资源抓取是否正常
服务器日志里，资源请求和 HTML 请求是分开记录的，可以按文件后缀筛选，看蜘蛛访问资源时的状态码分布。如果大量资源返回 403 或 404，说明渲染环境从一开始就是不完整的。也可以对照抓取统计中的资源下载失败提示，判断问题出在 robots.txt 还是服务器配置。
资源抓取不是越多越好。目标不是让蜘蛛把每个文件都取一遍，而是让它在合理的请求量内，拿到足以正确渲染页面的那些文件。