2026年了，商品图都做了懒加载，图片搜索里却几乎搜不到，是地址被藏起来了吗？

图片做懒加载本身不挡收录，真正让图片被漏掉的，是把真实地址从 src 挪进 data-src、滚到才补上的那种写法。2026 年 Google 和百度的图片索引，前提仍是「HTML 里能不能解析出可访问的图片地址」，而不是「用户滚到底有没有看到」。判断办法很直接：把 JavaScript 关掉再打开页面，图片节点上还有没有真实 URL。

图片懒加载为什么总被怀疑「把收录也懒掉了」

图片在搜索结果里有独立入口（Google 图片、百度图片），同时也是页面主题的补充信号。搜索引擎抓一个页面的预算有限，通常不会为了某个站点模拟一次完整滚动，把每个懒加载回调都触发一遍。于是「用户能看到」和「爬虫能读到」成了两件事：页面看起来一切正常，不代表图片被抓到了。

差别集中在一点上——真实地址是不是一开始就在 HTML 里。原生 loading="lazy" 仍然是 HTML 属性，浏览器推迟下载，但节点上的 src 可被解析；手写脚本把地址从 src 挪到 data-src、滚到才赋值，渲染前的 img 就是一个没有地址的节点。2026 年多数团队的做法是前者当默认，后者只在明确要省流量的局部使用。

• 基本能抓：图片节点始终带可解析的 URL，只是下载时机被推迟。
• 容易被漏：URL 只存在于 data-* 属性或 JS 变量里，要执行脚本才出现。
• 更难被发现：图片靠点击或翻页才请求，页面里又没有可发现的 a 标签入口。

原生属性和脚本替换，收录风险不在一个量级

两种做法最好不要混着改，先看清风险与代价，再决定动不动模板。

• 方案 A：原生 loading="lazy" —— 改动量小，常见区间是一行属性、单人半天以内；收录风险低；低端安卓上与浏览器自身的加载策略配合较好；回退就是把属性删掉，基本不牵动模板。
• 方案 B：IntersectionObserver + data-src —— 控制粒度细，可以自定义占位图和提前触发距离；但要自己补无 JavaScript、爬虫、不支持 IntersectionObserver 的分支；上线后发现收录不对，改回静态模板的返工量常见区间在一到三人天，模板越多越往上走。

按经验判断：图文内容站、商品详情与图库优先选 A；后台系统、登录后页面、爬虫本来就不关注的区域，选 B 更省带宽，也基本不用为图片收录操心。依据是图片在业务里承担什么角色，而不是哪种写法更新。

排查顺序：四步核对，别跳步

这套顺序的作用是把「感觉掉了」变成「知道掉在哪一步」。跳步最容易在错的地方改代码。

1. 看渲染前的 HTML：用查看源代码，而不是开发者工具的元素面板，确认 img 上是否已经有可解析地址。元素面板显示的是脚本执行后的结果，用它判断容易误判。
2. 关掉 JavaScript 再看一遍：无 JavaScript 状态下仍能看到图片地址，说明基础可抓取性过关，也能较快判断脚本懒加载有没有过界。
3. 核对地址与描述信息：看 alt 有没有写清图片内容、同一张图是否被无意义参数拆成多个 URL、承载信息的图有没有被做成 CSS 背景。
4. 用平台工具复核：在搜索资源平台做抓取诊断与 URL 检查，对照抓到的 HTML 与图片资源是否正常，检查项可按平台官方说明逐条核对。

哪些页面该为图片收录动手，哪些可以先放着

判断依据是「图片本身是不是流量入口或内容主体」，而不是「有没有用懒加载」。懒加载更像放大器，把原本存在的可抓取性问题放大了。

• 适合做：图文内容站、商品详情与图库、图片搜索是主要来源之一的站点、长列表里图片占比高的页面。
• 不必强做：只有一两张主图的营销单页、登录后才能访问的后台、内网系统、纯装饰且不传递信息的图片。
• 边界句：图片既不是流量入口、也不承担内容信息时，把它的收录优先级排到性能与成本之后是合理的；反过来，图片搜索是主要来源之一时，任何把地址藏进脚本的懒加载都要谨慎对待。

交付现场：几百张商品图上线后，才发现图搜几乎没进来

常见的一种约束组合是：素材一次给到几百张商品图、上线窗口只有两周左右、甲方还盯着首屏指标。可行做法是先保首屏一到两张主图不懒加载并按需预加载，其余统一交给原生懒加载，同时把「无 JavaScript 可视」写进自测清单。若中途为了省流量引入了一款第三方懒加载脚本，它往往把 src 整体抽走、滚到视口才补地址，上线一段时间后才发现图片入口几乎没有被收录。代价是回头要动模板、重新等抓取，返工周期按经验区间常见在一到三周不等，图片页越多越难压缩。

所以上线前把三件事写进清单更省事：首屏主图不懒加载、业务图在无 JavaScript 时仍有可解析地址、alt 与文件名能说明内容。

做到什么程度算合格

• 合格线：禁用 JavaScript 后，承载信息的图片仍有可解析地址；首屏主图不被推迟加载。
• 良好线：alt 描述准确、图片 URL 稳定、装饰图与内容图区分清楚，图片入口在搜索资源平台上能被稳定发现。
• 常见坑：只用 CSS background 承载信息图；同一张图带随机参数；首屏主图也被加上懒加载，首屏指标反而变差；懒加载只在滚动回调里补地址，却没有无 JavaScript 的回退路径。
• 验收口径：把「无 JavaScript 可视」当成一条硬性检查项纳入上线前清单，比事后看收录量变化更容易定位问题。

常见问题

图片改成 CSS 背景图，还能进图片搜索吗？

通常不会作为内容图片被收录，图片搜索主要依赖 img 元素及其中的地址。装饰图可以用背景图，承载信息的图建议用 img 并配 alt。

首屏主图也加 loading="lazy"，会不会拖慢首屏？

会。首屏主图被推迟加载时，LCP 常见会明显变差。首屏一到两张主图建议不加懒加载，必要时再配合预加载。

图片地址后面带一堆参数，会影响抓取吗？

抓取通常不会因此中断，但同一张图被多套参数拆成多个 URL，会分散图片索引信号。常见做法是只保留必要尺寸参数，避免随机串。

已经做了图片 sitemap，还要管懒加载吗？

两者不是替代关系。图片 sitemap 只能辅助发现，页面里可解析的 img 地址仍是主要入口，通常应一起做。

落地建议：先关掉 JavaScript 自检一遍图片地址，再按四步核对法定位问题，最后把「首屏不懒加载、业务图地址可解析、alt 写清内容」写进验收清单。若图片既不是流量入口也不承担内容信息，按经验区间把收录优先级排在性能之后是合理的，不必为收录牺牲首屏体验。