图片也是内容，别只当作装饰
谈抓取和收录时，很多运营只盯着 HTML 页面，把图片当成附属品。但对教程站、电商站、内容站来说，图片本身就是信息的一部分，也是图片搜索的入口。图片处理不当，用户看到的和蜘蛛拿到的会是两套东西：用户看到的是图，蜘蛛看到的可能只是一串文件名，甚至什么都没有。
自查点一：图片有没有真的出现在初始 HTML 里
最常见的坑是懒加载。为了首屏速度，前端把图片地址挪到自定义属性里，等滚动到可视区域再赋值。用户感觉变快了，但如果页面依赖脚本渲染，蜘蛛拿到的初始 HTML 中可能没有任何图片地址。
- 用「查看网页源代码」而不是「审查元素」，搜索图片文件名，看它在不在图片标签里。
- 用带渲染能力的抓取工具再抓一次，对比两次结果差异。
- 如果确实需要懒加载，优先使用原生 loading 属性，它在 HTML 里保留真实地址。
一个简单的判断办法：禁用 JavaScript 打开页面，图片还在不在。如果不在，就要确认蜘蛛视角是否也看不到。
自查点二：文件名、替代文字与周边正文
图片能否被正确理解，主要看文件名、替代文字、周边正文和所在页面主题是否指向一致。
- 文件名：一串随机数字或相册编号，改成能说明内容的短名，用连字符分隔，不要堆关键词。
- 替代文字：描述图片里有什么，不是塞关键词的地方。纯装饰图可以留空。
- 周边正文：图片所在段落要能说明它想表达什么，别让一张图孤零零挂在两段无关文字之间。
自查点三：图片地址是否稳定、是否被误挡
图片地址变动频繁，是站长最容易忽略的问题。改一次目录结构，老地址全变 404，图片搜索的收录也会跟着塌。
- 检查 robots.txt 有没有顺手把图片目录、上传目录一起挡住。
- 检查 CDN 是否对图片加了防盗链或带时效的签名参数，导致蜘蛛拿到 403。
- 检查图片地址是否随版本号、时间戳频繁变化，能否保持一个稳定地址。
自查点四：体积与响应时间
图片体积直接吃带宽和响应时间。列表页一次加载几十张原图，服务器响应时间会被拉长，蜘蛛抓取时遇到超时的概率也会上升。建议上传时就生成多套尺寸，列表页用合适的小图，别把原图直接铺上去。同时留意图片服务器和主站是否共用同一个响应瓶颈。
自查点五：占位图与重复图
默认封面、默认头像被全站复用，会让大量页面在视觉和结构上高度雷同。抽查时可以按图片地址统计出现次数，某个地址出现几百上千次，基本可以判断是占位图。这类图可以保留，但别让它承担内容识别的作用。
一个能落地的自查流程
- 抽 10 到 20 个有代表性的页面，包括详情页、列表页、专题页。
- 看源码中图片地址是否存在，替代文字是否为空，文件名是否有意义。
- 用抓取工具跑一遍，统计图片请求的状态码，把 403、404 的地址单独列出来。
- 翻服务器日志，看图片目录的请求量和状态分布，确认没有被误挡。
- 把问题分成「影响抓取」和「影响体验」两类，前者先修。
修复优先级怎么排
优先处理被误挡和被懒加载藏起来的图片，它们直接影响蜘蛛能否发现资源；其次处理文件名和替代文字，影响的是理解准确度；最后才是体积优化，影响的是速度和抓取稳定性。三件事做不完的时候，按这个顺序推进，收益最稳。