做抓取排查时，多数人先看链接、状态码、robots 和站点地图，图片往往排在最后。但实际打开一个页面，图片和媒体文件经常占掉一半以上的体积。它们不像文字那样一眼能读完，出问题时也不容易发现：图片链接 404 不会让页面消失，只是安静地留一个破图；图床加了防盗链，蜘蛛取图时拿到 403，日志里多一行而已。这些小事积累起来，会实实在在影响页面加载和内容的完整呈现。

一、体积：先量，再改

同一张 3000 像素宽的原图，直接塞进 800 像素宽的容器里，浏览器照样要下载完整的原图。常见的做法是按最大展示尺寸的 1.5 到 2 倍导出，再转成 WebP 或 AVIF 这类现代格式。批量处理可以用 Squoosh、ImageMagick、sharp 等工具，没必要一张张手动改。

可以参考的经验线：首屏主图控制在 200KB 以内，列表页缩略图几十 KB，单个页面图片总量尽量别超过 1MB 左右。这不是硬指标，但明显超过这个量级时，移动端体验和抓取时的资源消耗都会变差。

二、文件名、alt 与周边文字

相机直出的 IMG_2847.jpg 对访客和搜索引擎都没有帮助。文件名用英文小写加连字符，写清楚图片是什么，比如 site-structure-diagram.webp。alt 要如实描述图片内容，让读屏软件和无法加载图片的场景也能理解，但不必把关键词硬塞进去——堆词的 alt 反而会让整页看起来像在凑字数。

另外别忘了图片周围的正文。图片下方的一句说明、图注、上下文里的解释，通常比 alt 更能说明这张图在讲什么。alt 是兜底，正文才是主体。

三、懒加载：蜘蛛能不能等到图片出现

loading="lazy" 本身是好事，能省带宽，但要注意两个常见坑：一是首屏图也加了懒加载，用户看到白屏，预加载的价值也没了；二是用脚本把 src 换成 data-src 时，没有留下可读的 src 或 noscript 兜底，脚本没执行的地方就什么也取不到。

还有一种更隐蔽的情况：图片托管在带防盗链的图床或 CDN 上，会拦截不带 Referer 的请求。可以自己验证——用命令行分别带和不带 Referer 各请求一次图片地址，看一下返回的状态码是不是 200。如果只有带 Referer 才正常，就要考虑换托管方式或放宽规则。

四、失效图片与站外图片

图片 404 不会让整页消失，但它会在日志里堆起一堆无效请求，也会让访客看到破图。建议定期扫一遍全站的 img 的 src、srcset，以及 CSS 里的 background-image，找出返回 404、301、403 的地址，统一处理。

站外图片还要多一层考虑：对方可能限流、开启防盗链，也可能哪天直接把图删了。重要的示意图、产品图、流程图，最好下载到自己的域名或对象存储里，别把长期展示的内容押在别人服务器上。

五、一份能照着做的清单

• 统计几个主要模板的图片数量和总体积，找出最重的三个页面
• 按实际展示尺寸重新导出，转成 WebP 或 AVIF，原图另存备份
• 补齐 width 和 height 属性，减少布局抖动
• 检查首屏图有没有被误加懒加载
• 用命令行验证图片地址在不带 Referer、不带 Cookie 时的返回状态
• 把关键的站外图片迁到自己可控的存储上
• 给有信息量的图片写清 alt，不做关键词堆积

六、别只看图片

字体文件、图标字体、第三方统计脚本、嵌入的视频播放器，逻辑和图片是一样的：它们都是被请求、被加载、被计量的资源。自查时不一定要一次全改完，按页面模板一类一类来，先处理访问量最大、结构最复杂的那几个模板，效果通常最明显。

图片和媒体不是页面的“装饰品”，它们同样会被请求、被渲染、被计入成本。把它们纳入常规自查，比等到抓取异常再去翻日志要省事得多。

最后提醒一句：这些调整的目标是让页面更轻、内容更完整，而不是为了迎合某个指标的短期波动。改完之后，结合访问日志看一段时间蜘蛛到访和取图的记录，再决定下一步动哪里。