很多站点在文字内容和结构上做了不少功课，图片却常常被当成“顺手传上去就行”的素材。等到頁面變慢、正文配图變成空白、图片搜尋几乎没流量时，才發現問题早就埋下了。图片和媒体资源属于站点运营的一部分，它既影响加载速度，也影响搜尋引擎對頁面内容的理解，值得像检查标题和連結一样定期過一遍。
图片為什么值得單獨自查
图片文件通常占頁面總字节數的大头。一張未经压缩的相机原图，可能比整頁 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。這些细节不直接决定排名，却會持續影响加载体驗和内容可讀性，属于运营里回报比較稳定的那部分工作。