图片懒加载会不会让搜索引擎看不见：目录站 loading=lazy 的正确用法

2026-10-23 约 1,642 字预计阅读 4 分钟 yiyunkj

那句最关键的话：它不会滚动，也不会点击

谷歌在《修正延迟加载的内容》这份文档里写得非常直白：如果要确保 Google 能看到页面上的所有内容，延迟加载的实现必须在相关内容进入视口时就加载它。紧接着一句解释了原因——这个方法不能依赖用户操作（比如滚动或点击）来加载内容，这一点很重要，因为 Google 搜索不会与你的网页互动。

这句话是所有懒加载规则的根。推导一下就很清楚了：

图片来源：网络，版权归原作者所有，侵权请联系删除

这条既是 SEO 规则也是性能规则。首屏大图几乎必然是 LCP 元素，给它加 loading=lazy 等于告诉浏览器「这个不着急」，结果是 LCP 变差。而且这张图通常也是你最想被图片搜索收录的那张。

目录站的实际切法：第一屏（大概前 2 到 3 行卡片）的缩略图用 eager，甚至给 LCP 那张加 fetchpriority=high；从第二屏往后全部 lazy。一页 300 个条目的分类页，这么切能省掉 95% 以上的图片请求。

判断「第几屏」要按移动端算。同一个像素高度，在手机上可能是第三屏，在 27 寸显示器上是首屏。宁可多 eager 几张，也别把首屏的图 lazy 掉。

这是个组合坑。懒加载让图片晚到，如果不给尺寸，浏览器先按 0 高度排版，图片到位后把所有内容往下顶。原本是为了性能，结果把 CLS 搞上去了。

做法很简单，每个 img 都写死 width 和 height，或者给容器 aspect-ratio。目录站的缩略图本来就是统一尺寸的，这件事应该写进模板，不应该靠编辑记着。

<img src="/thumb/xxx.jpg" width="120" height="90"
     loading="lazy" alt="某某设计工具官网截图">

响应式图片用 srcset 时，各候选图必须保持同一个宽高比，否则 width/height 属性算出来的占位比例是错的。

老牌懒加载库的常见套路是：

<img data-src="/thumb/xxx.jpg" src="placeholder.gif">

JS 跑起来之后把 data-src 换成 src。问题有两个：一是爬虫如果不执行 JS（或者执行时机不对），抓到的全是占位图；二是占位图一旦被索引，图片搜索里你的缩略图全是同一个灰色方块。

这个坑在目录站上尤其常见，因为缩略图多，早年的模板都是这么写的。检查一下你的模板源码里有没有 data-src，有就换掉。

不少目录站用无限滚动替代分页，用户体感好，但对收录不友好。谷歌给的要求是支持分页加载，每个分块有自己的永久唯一 URL，而且每次加载这个 URL 时内容保持不变。

具体就是用绝对页码，比如 ?page=12，不要用 ?date=yesterday 这类相对参数——相对参数下同一 URL 的内容会随时间变，爬虫抓到的和你现在展示的对不上。

分页页数的分面导航要不要收录是另一个话题，这里只强调：无限滚动本身不是问题，没有可索引的分页 URL 才是。

Search Console 网址检查 → 测试实际网址 → 查看已抓取的 HTML，搜索里面有没有你的图片 URL。如果只有占位图或者什么都没有，就是实现有问题。
PageSpeed Insights 跑一遍，看 LCP 元素是不是图片，如果是，回源码确认它有没有被 lazy。
CLS 超过 0.1 的话，先查懒加载图片的 width/height 有没有写全。补尺寸通常是见效最快的那个修复。

懒加载本身是官方推荐的性能实践，别因为怕影响收录就不用。真正的分界线只有一条：内容是在进入视口时加载的，还是在等一个永远不会发生的滚动。