做抓取排查时，多數人先看連結、狀態碼、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，不做關鍵詞堆积
六、別只看图片
字体文件、图标字体、第三方統計脚本、嵌入的视频播放器，逻辑和图片是一样的：它們都是被請求、被加载、被計量的资源。自查时不一定要一次全改完，按頁面模板一類一類来，先處理訪問量最大、结构最复杂的那几個模板，效果通常最明顯。
图片和媒体不是頁面的“装饰品”，它們同样會被請求、被渲染、被計入成本。把它們纳入常規自查，比等到抓取異常再去翻日誌要省事得多。
最後提醒一句：這些調整的目标是让頁面更轻、内容更完整，而不是為了迎合某個指标的短期波動。改完之後，结合訪問日誌看一段時間蜘蛛到訪和取图的记錄，再决定下一步動哪里。