很多站点在正文、内链和Sitemap上做得挺规范，但页面图片一多，搜索蜘蛛能发现的URL就明显少了一截。原因往往不在蜘蛛，而在图片的写法：本该出现在HTML里的地址，被挪进了JS变量、data-* 属性或CSS里。
一、懒加载：两种写法，结果完全不同
懒加载的目标是延迟加载资源，不是延迟暴露URL。区分点很简单：地址到底在不在HTML源码里。
- 原生懒加载：给图片加上 loading="lazy" 只是提示浏览器推迟请求，src 仍然写在标签上，地址照常可被发现。这是目前比较省心的做法。
- JS懒加载：常见写法是把真实地址放在 data-src、data-original 上，等滚动到视口才由脚本写入 src。蜘蛛不会滚动页面，也不一定执行这段脚本，地址就可能一直停留在属性里。
如果出于性能必须用JS方案，至少保留一个可抓取的出口：用 noscript 包一份带真实 src 的图片，或者让首屏图片直接写 src。别把整页图片都做成“滚动之后才存在”的形态。
二、响应式图片：srcset 与 picture 的取舍
srcset 用 w 或 x 描述符提供多套尺寸，浏览器按视口挑一套下载。这里容易出现两个误解：
- 以为蜘蛛只认 src。多数情况下 src 仍会被读取，作为兜底候选存在。
- 以为 srcset 里的每一档地址都会被逐一抓取。实际上不会，蜘蛛通常只取其中一部分，具体行为并不公开，也不必依赖它。
比较稳妥的做法是：srcset 只提供有限几档尺寸，而不是为每个宽度生成一个地址；src 指向固定文件，保证任何情况下都有稳定的URL。
picture + source 的结构类似。注意 source 的 media 与 type 条件不要写死到只剩一种极端场景，否则部分客户端拿不到图，蜘蛛看到的也只是空壳。
三、容易被忽略的几类图片入口
- 可点击的图片链接：图集、商品列表、上一条下一条按钮常以图片承载a标签。图片是懒加载时，链接地址仍写在 a 的 href 上，通常不受影响；但要确认 href 不是由脚本拼接的。
- CSS 背景图：写在样式表里的背景图，一般不会被当作页面资源去发现，也不适合承载关键内容信息。
- 视频与 iframe 的延迟加载：iframe 的 src 若被替换成 data-src，里面的页面就不会被访问到，连带其中的链接一起沉没。
- 图床或压缩服务的参数：同一张图通过 ?w=200&h=200 之类的参数派生出大量地址，既容易制造重复内容，也浪费抓取。建议固定几套尺寸，或统一收敛。
四、可执行的自查清单
- 在浏览器里禁用JS，打开一个典型内容页，看图片是否仍显示、图片链接是否仍能点。
- 查看页面源码，搜索 data-src、data-original，确认这些位置是否也有 src 兜底。
- 抽查列表页与图集页，确认翻页、下一张等入口是真实 href，而不是 click 事件。
- 给图片补上有意义的 alt 与周边文字说明，帮助判断图片与页面的关系。
- 如果站点以图片为核心内容且数量较大，考虑维护图片 Sitemap，把主要图片页与关键图片地址一并列出。
判断标准可以简化为一句：人关掉JS还能看到、点到的东西，蜘蛛大概率也能发现；只有打开JS才出现的东西，就要打个问号。
五、不要为了抓取牺牲体验
懒加载本身没问题，响应式图片也是必要的优化。问题出在把“延迟加载”做成了“延迟暴露”。在速度、体验和可发现性之间，比较省事的组合是：先保证HTML里有稳定、完整的地址，再用脚本去优化加载时机。改动之后建议观察一段时间服务器日志里图片与相关页面的抓取情况，用实际数据验证，而不是凭感觉判断。