很多站点排查抓取问题时，目光都放在 HTML、状态码和链接上，图片和静态资源往往被忽略。实际上，一个页面里图片、CSS、JS 的体积和数量，直接决定浏览器要花多久才能把内容呈现出来；而图片地址的频繁变动，又会在服务器日志里留下成片的 404。这两件事一个影响抓取节奏，一个消耗抓取预算，值得单独做一次梳理。
图片体积为什么会牵动抓取
搜索引擎抓取 HTML 之后，通常还需要下载页面引用的资源，才能完整理解渲染后的内容。如果首页挂着几十张未压缩的大图，渲染队列就会被拉长，同样的服务器和带宽下，可用的抓取吞吐自然变少。这不是说图片一定会带来负面评价，而是资源越重，单位时间内能处理的页面就越有限。
更常见的情况是：图片本身拍摄质量没问题，却被放进了首屏关键位置，又没有做尺寸适配，移动端访客和渲染进程都要多等几秒。
体积与格式的自查方向
- 单张内容图尽量控制在 200KB 以内，商品图、轮播图按实际展示尺寸输出，不要用 2000px 宽的图去填 400px 的容器。
- 照片类优先 WebP 或 AVIF，图标和简单插画用 SVG，避免把矢量图形导出成 PNG 再放大使用。
- 检查是否重复上传了同一张图的多个版本，文件名带“-1”“-副本”“-final”的往往是历史遗留。
- 用工具批量扫描服务器或 CDN 上的图片目录，按文件大小排序，排在前面的几十个文件通常就是优化重点。
失效引用与 URL 稳定性
图片 URL 一旦变动，旧地址就会返回 404。如果这些图片分散在大量页面里，蜘蛛每次重爬都会撞上失效请求。短期看不出问题，长期会拉低整站的抓取有效率，也让日志里的错误比例失真。
比较稳妥的做法是：图片上线后尽量不改路径；确需迁移时保留 301 跳转，并在日志中确认旧地址的请求量确实降下来了。另外要留意编辑器自动生成的临时地址，比如带时间戳或随机字符串的图片链接，这类地址往往在内容发布后失效，是失效引用的高发区。
图片说明文字与周边内容
alt 属性不只是无障碍要求，也是图片内容被理解的重要线索。至少要让每张有信息价值的图片有一句描述性的 alt，而不是“图片”“img_01”。文件名同样如此，把“IMG_2043.jpg”改成能说明内容的英文或拼音短语，成本很低，收益却很直接。
图片周围如果有正文、图注、小标题，会帮助判断图片与页面的相关性。把图片孤立地放进一个只有图、没有任何文字说明的页面，理解成本会高很多。
懒加载与首屏的取舍
懒加载能减少初始请求，但用错位置会适得其反。首屏主图、文章头图如果也加了懒加载，渲染进程可能需要额外触发才能拿到图片，反而拖慢可见内容的出现。
- 首屏可见区域的图片：正常加载，必要时加 preload。
- 首屏以下的图片：启用懒加载，占位尺寸要和实际尺寸一致，避免布局抖动。
- 确认懒加载没有阻断图片地址被抓取，部分脚本实现会把真实地址放在 data- 属性里，需要确认解析是否正常。
缓存与分发
静态资源通常走 CDN，缓存策略设置得当能显著减少回源请求。检查几件事：Cache-Control 是否给了足够长的过期时间；带 hash 的文件名是否长期缓存；版本号更新后旧文件是否还能访问；CDN 是否因为配置错误对图片请求返回 403。
如果日志里图片请求大量回源，说明缓存命中率有问题，这既增加服务器负担，也可能让抓取高峰期的响应变慢。
一次可执行的自查清单
- 导出图片目录清单，按体积排序，先处理最大的 20%。
- 随机抽查 20 个页面，用开发者工具看资源瀑布图，记录总请求数和总字节数。
- 在日志中筛选图片类请求的 404，按 URL 归组，找出引用来源页面。
- 检查站点地图中的图片条目是否与实际页面一致，删除已下线的图片地址。
- 随机抽 10 张图，核对 alt 与文件名是否有描述性。
- 抽查懒加载实现，确认首屏图片不在懒加载范围内。
图片和静态资源的问题通常不会立刻暴露，它们体现在抓取耗时、404 比例和渲染等待上。定期做一次体积与失效引用的清理，比等到抓取效率下降再回头排查要省事得多。