很多站点的抓取与体验问题，最后都落在图片上。一页正文没多少字，模板图标、封面大图、相册缩略图加起来可能几十个请求；再碰上外链图床偶尔抽风，蜘蛛抓到的就只剩超时和破图。图片本身不会直接决定收录，但它会实打实影响页面体积、渲染时间和抓取节奏，值得定期做一轮自查。

一、先量体积：单图与整页

别凭感觉判断"图大不大"，用工具量一遍更省事。打开一个典型内容页，看两件事：单张图的体积，以及整页图片请求的总量。

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

二、格式与尺寸：别用大图缩小展示

常见做法是上传一张 2000px 宽的原图，再用 CSS 缩到 600px 显示。这样做用户看到的是小图，实际下载的仍是大图，带宽和解析时间都白花了。

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

三、懒加载与首屏

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

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

四、外链图片与图床

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

• 图床是否支持稳定的外链访问，有没有防盗链策略会误伤搜索蜘蛛。
• 图片地址是否会随账号、时间变化，一旦失效，页面上就是一片破图。
• 外链图片的响应速度不受你控制，必要时把关键图片收回自建存储。

自查时不妨随机抽十篇老文章，逐张点开图片地址，看看有没有 404、超时或者跳转到无关页面。老内容里的失效图，往往比新内容多得多。

五、alt 与文件名

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

• 写清楚图片表达的内容，一句话即可，不要塞一长串关键词。
• 装饰性图片可以留空 alt，避免读出无意义的文字。
• 文件名用简短、有含义的英文或拼音，别用一长串数字和乱码。

六、图片地址的重复与参数

图片处理参数（宽度、质量、裁剪方式）组合起来，很容易为同一张图生成大量不同地址。

• 固定常用的几档尺寸，不要每个页面各写一套参数。
• 检查缩略图地址是否被当成独立页面收录，必要时用规则屏蔽。
• 如果站点有图片较多、希望单独提交的图集，可以考虑维护一份图片地址清单，放进站点地图里集中提交。

七、服务器侧的两件小事

图片多还会带来两个容易被忽视的副作用。一是带宽和日志量上升，如果日志没有做轮转，磁盘会先撑不住；二是图片请求过多时，如果做了频率限制，正常用户也可能被误伤。自查图片的同时，顺手看一眼日志里图片请求的占比和状态码分布，能发现不少线索。

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

1. 每季度抽 5 到 10 个代表性页面，量一遍单图体积和整页请求数。
2. 检查新上传的图片是否走了压缩流程，有没有原图直传。
3. 随机抽查老文章的图片链接，记录失效数量。
4. 确认首屏图片没有被懒加载挡住。
5. 看一遍图片地址参数，是否产生了明显重复。

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