很多站点排查抓取問题时，目光都放在 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 比例和渲染等待上。定期做一次体积與失效引用的清理，比等到抓取效率下降再回头排查要省事得多。