很多站点在正文、内鏈和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里有稳定、完整的地址，再用脚本去優化加载时机。改動之後建议观察一段時間服務器日誌里图片與相關頁面的抓取情况，用實际資料驗證，而不是凭感觉判断。