很多站点在文字内容和结构上做了不少功课，图片却常常被当成“顺手传上去就行”的素材。等到页面变慢、正文配图变成空白、图片搜索几乎没流量时，才发现问题早就埋下了。图片和媒体资源属于站点运营的一部分，它既影响加载速度，也影响搜索引擎对页面内容的理解，值得像检查标题和链接一样定期过一遍。
图片为什么值得单独自查
图片文件通常占页面总字节数的大头。一张未经压缩的相机原图，可能比整页 HTML 加 CSS 还大好几倍。蜘蛛抓取页面时会受带宽和等待时间限制，用户打开页面时也一样。把图片管好，往往比换服务器更快见效。
另一方面，图片本身就是内容。文件名、alt 文本、周边的正文，都是帮助搜索引擎判断这张图讲什么的线索。图片搜索带来的访问量不如网页搜索稳定，但对教程、菜谱、产品、设计素材这类站点来说，是很实在的入口。
自查清单
1. 体积与格式
- 主图是否还在用未压缩的 PNG 或大尺寸 JPEG？可以考虑 WebP、AVIF，并保留降级方案。
- 是否开启了服务端或 CDN 的图片压缩？压缩前后拿同一张图对比一下体积。
- 缩略图和原图是否共用了同一个文件？列表页加载整张原图很常见，也很浪费。
2. 尺寸与显示
- HTML 里写的宽高是否和实际文件尺寸差距过大？用 CSS 缩小的图，浏览器依然要下载完整文件。
- 是否设置了宽高属性或宽高比，避免图片加载完成后页面大幅跳动？布局抖动会直接影响停留体验。
- 移动端和桌面端是否用了同一张大图？可以用 srcset 给不同屏幕提供不同尺寸。
3. 懒加载的边界
懒加载能省带宽，但用错位置反而伤内容。首屏主图、正文第一张图如果也被延迟加载，用户和蜘蛛都可能先看到空白。
- 首屏图片建议直接加载，不要延迟。
- 确认懒加载是浏览器原生属性，还是脚本实现；脚本方案要保证在脚本未执行时图片仍可访问。
- 注意停留在占位状态的图片，检查是否存在加载失败却没有报错的情况。
4. 文件名与 alt
- 文件名是否有意义？把 img-2031.jpg 换成“不锈钢保温杯-500ml.jpg”成本很低。
- alt 是否描述了图片内容，而不是堆砌关键词？纯装饰性图片可以留空 alt。
- 图片周围的正文有没有呼应？图和文字讲同一件事时，理解成本最低。
5. 图片的抓取路径
- 图片是否被 robots.txt 或防盗链规则挡住？有时蜘蛛拿不到图，只因为规则写得比预想中更严。
- 图片是否放在独立域名或对象存储上？跨域配置和缓存策略要一起检查。
- 重要图片是否只在脚本里动态插入？纯脚本插入的图片，发现路径会更长。
处理顺序建议
- 先看体积最大的二十张图，通常能解决大部分速度问题。
- 再补 alt 和文件名，尤其是栏目页、商品页、教程页的主图。
- 最后统一懒加载和响应式规则，避免一页一个写法。
图片自查不需要一次做到完美。先把首屏和流量最高的几类页面处理干净，比全站推倒重来更实际。
把检查变成习惯
新增内容时顺手命名文件、写 alt、控制尺寸，成本远低于事后回头补。可以每季度抽几个栏目翻一遍图片，看看有没有失效的图床链接、突然变大的文件、或者长期空着的 alt。这些细节不直接决定排名，却会持续影响加载体验和内容可读性，属于运营里回报比较稳定的那部分工作。