做站点运营时，正文和链接通常被反复打磨，图片、视频封面、附件这类媒体资源却常被放到最后。但从服务器日志看，一次页面抓取里，图片请求往往占了不小的比例。如果这些请求大量落在失效地址、占位图或者第三方拦截上，被抓取配额就被消耗在没有产出的地方。
图片不参与排名，但会影响抓取效率
蜘蛛解析 HTML 时，会从 img 的 src、srcset 以及部分懒加载属性里提取资源地址，然后逐个发起请求。每一个请求都要走一遍 DNS、连接、响应流程，占用的是同一份抓取配额。正文页一天可能只更新一次，但如果页面上挂着几十张失效图片，蜘蛛每次来都要重新撞一遍墙。
这不意味着图片有问题就一定会掉排名，而是说它会持续拉低整站的抓取效率，让真正需要被重新抓取的页面排在后面。
几个高频问题
- 懒加载占位地址写进 src：真实图片放在 data-src 里，src 指向一张 1x1 透明图或空地址。蜘蛛拿到的是占位图，有时甚至直接是 404。
- 缩略图服务返回错误页：参数拼错或图片已被删除，接口仍然返回 200，内容却是一段错误提示文字，形成事实上的软 404。
- 外链图片被对方拦：图片托管在第三方域名，对方 robots.txt 禁止抓取，蜘蛛每次访问都被拒，白白浪费请求。
- 多尺寸重复存储：同一张图按 200、400、800 像素各存一份，HTML 里却没有任何尺寸说明，蜘蛛把三份都抓一遍。
- 命名与 alt 随意：文件名是 IMG_2381.jpg，alt 要么缺失，要么写着一串和内容无关的关键词。
自查的五个步骤
- 从访问日志里筛出图片扩展名的请求，看状态码分布和请求次数排名。
- 抽查首页、栏目页、内容详情页各一到两个模板，逐个看 img 标签的实际写法。
- 确认懒加载方案在禁用 JavaScript 时是否还有可读的资源地址。
- 检查图片 Sitemap 是否还在收录已经删除的图片地址。
- 核对所有外链图片域名，看对方是否允许抓取、是否设置了防盗链。
日志里先看三类请求
第一类是返回 404 或 410 的图片，说明地址已经废弃；第二类是返回 200 但体积异常小的，可能是占位图冒充真图；第三类是被 403 拒绝的，多半是外链或防盗链问题。这三类加起来，往往就是浪费的主要来源。
抽查典型页面时看什么
重点不是图片好不好看，而是地址是否稳定、是否指向真实资源。同一张图在列表页和详情页是否用了同一个地址，尺寸参数是否写死在模板里，图片尺寸和后缀是否对应。顺手把明显无意义的文件名改成能描述内容的英文或拼音短词，成本很低。
懒加载要留一条不用 JS 也能读到的路径
如果图片必须靠脚本才加载，至少保证 src 指向一张真实的占位图而不是空值，或者通过 noscript 给出真实地址。完全依赖脚本的写法，在渲染能力不足的抓取环境里就是一个空洞。
处理时的几个原则
- 能修就修，不留半成品：图片地址失效，与其换成空 src，不如替换成同类图片或直接删除该标签。
- 彻底废弃的返回明确状态码：让蜘蛛知道这个地址不会再恢复，而不是反复回访。
- 控制单页图片数量：列表页限制每页条目数，避免一个页面拖出上百个资源请求。
- 图片 Sitemap 只放值得被索引的图：图标、装饰性背景、广告位图片没有必要放进去。
图片资源的问题通常不会一次性暴露，而是以「页面更新越来越慢、日志里图片请求越来越多」的形式慢慢显现。定期看一眼，比等到抓取配额明显不够用再回头排查要省事。
把图片和媒体资源纳入常规自查清单，本质上是在做同一件事：让蜘蛛每次来访都有明确的收获，而不是把时间花在找不到、打不开、看不了的资源上。这项工作不需要额外工具，从日志和模板入手就能完成大半。