很多站点的抓取與体驗問题，最後都落在图片上。一頁正文没多少字，模板图标、封面大图、相册缩略图加起来可能几十個請求；再碰上外鏈图床偶尔抽風，蜘蛛抓到的就只剩超时和破图。图片本身不會直接决定收錄，但它會實打實影响頁面体积、渲染時間和抓取节奏，值得定期做一轮自查。

一、先量体积：單图與整頁

別凭感觉判断"图大不大"，用工具量一遍更省事。打開一個典型内容頁，看两件事：單張图的体积，以及整頁图片請求的總量。

• 單图体积：正文配图控制在 100KB 上下通常够用，封面图可以放宽，但几百 KB 甚至上 MB 的原图直接上传，基本没必要。
• 整頁請求數：一個頁面挂三四十張图，即使每張都不大，叠加起来也會拖慢渲染，移動端尤其明顯。
• 重复加载：同一張图在列表頁、侧栏、相關推荐里各加载一次，如果地址不同，浏览器就没法复用缓存。

二、格式與尺寸：別用大图缩小展示

常见做法是上传一張 2000px 宽的原图，再用 CSS 缩到 600px 顯示。這样做用戶看到的是小图，實际下载的仍是大图，带宽和解析時間都白花了。

• 按展示尺寸准备图片，或使用服務端的图片處理能力按需裁剪。
• 照片類優先用 WebP 等压缩率更好的格式，图标類考虑 SVG。
• 保留一份原图存档即可，不要在頁面里直接引用它。

三、懒加载與首屏

懒加载能减少首屏负担，但要用對位置。首屏可见的主图如果也加了懒加载，用戶和蜘蛛看到的可能是一块空白占位，反而更糟。

• 首屏图正常加载，屏幕外的图延迟加载。
• 懒加载占位图要有明确尺寸，避免加载完成後頁面大幅抖動。
• 如果站点依赖前端渲染，注意確認懒加载逻辑不會让图片地址在初始 HTML 里完全缺失。

四、外鏈图片與图床

把图片放在第三方图床或對象存储上很常见，但要多留一道心。

• 图床是否支持稳定的外鏈訪問，有没有防盗鏈策略會誤伤搜尋蜘蛛。
• 图片地址是否會随帳號、時間變化，一旦失效，頁面上就是一片破图。
• 外鏈图片的响應速度不受你控制，必要时把關键图片收回自建存储。

自查时不妨随机抽十篇老文章，逐張点開图片地址，看看有没有 404、超时或者跳轉到無關頁面。老内容里的失效图，往往比新内容多得多。

五、alt 與文件名

alt 文本是给看不到图的人（包括部分抓取场景）用的描述，不是關鍵詞堆砌位。

• 寫清楚图片表達的内容，一句话即可，不要塞一長串關鍵詞。
• 装饰性图片可以留空 alt，避免讀出無意义的文字。
• 文件名用简短、有含义的英文或拼音，別用一長串數字和乱碼。

六、图片地址的重复與參數

图片處理參數（宽度、质量、裁剪方式）组合起来，很容易為同一張图生成大量不同地址。

• 固定常用的几档尺寸，不要每個頁面各寫一套參數。
• 检查缩略图地址是否被当成獨立頁面收錄，必要时用規則屏蔽。
• 如果站点有图片較多、希望單獨提交的图集，可以考虑维護一份图片地址清單，放進站点地图里集中提交。

七、服務器侧的两件小事

图片多還會带来两個容易被忽视的副作用。一是带宽和日誌量上升，如果日誌没有做轮轉，磁盘會先撑不住；二是图片請求過多时，如果做了频率限制，正常用戶也可能被誤伤。自查图片的同时，顺手看一眼日誌里图片請求的占比和狀態碼分布，能發現不少线索。

八、一個可执行的自查节奏

1. 每季度抽 5 到 10 個代表性頁面，量一遍單图体积和整頁請求數。
2. 检查新上传的图片是否走了压缩流程，有没有原图直传。
3. 随机抽查老文章的图片連結，记錄失效數量。
4. 確認首屏图片没有被懒加载挡住。
5. 看一遍图片地址參數，是否产生了明顯重复。

這些事都不复杂，难点在坚持。把它纳入日常的内容發布流程——上传前压一下、發布後看一眼——比事後集中返工要轻松得多。