本文约 3,312 字，预计阅读 9 分钟。文中命令与配置均经过实测，可直接参考执行。
引言：开了懒加载，图片搜索流量掉了一半
一个很常见的连锁反应：为了提升 PageSpeed 分数开启图片懒加载，一个月后发现 Google 图片搜索的展现量掉了 40%，于是得出结论「懒加载影响索引」。但把懒加载关掉，流量又没回来。真相通常不在懒加载本身，而在实现方式和排查方向——大部分站长同时装了缓存插件的懒加载和主题的懒加载，两份逻辑叠加后，图片的 src 被替换成占位符，真正的地址被塞进了 data-src。Googlebot 渲染页面时，如果这段 JS 依赖滚动事件触发，它就永远不会执行，因为 Googlebot 不会滚动页面。
判断这个问题需要先区分两类实现：浏览器原生的 loading="lazy"，以及用 JS（通常是 IntersectionObserver 或滚动监听）实现的自定义懒加载。它们在 SEO 上的表现完全不同。
原理分析：Googlebot 渲染时会做什么
Googlebot 的渲染服务（web rendering service, WRS）加载页面时会执行 JS，但它有一个关键限制——不会模拟用户滚动。它使用一个很高的虚拟视口来渲染，这意味着：
| 实现方式 | Googlebot 行为 | 索引结果 |
|---|---|---|
原生 loading="lazy" |
浏览器原生机制，视口内的资源照常加载，与 JS 无关 | 图片正常被索引 |
| IntersectionObserver 懒加载 | WRS 支持 IntersectionObserver，视口内元素会触发 | 通常能索引，但边界条件复杂 |
监听 scroll 事件的懒加载 |
Googlebot 不滚动，事件不触发 | 图片地址永远不写入 src，不被索引 |
| 依赖交互（点击「加载更多」） | Googlebot 不点击 | 完全不索引 |
src 放在 data-src，无 <noscript> 兜底 |
渲染后 HTML 里没有真实地址 | 不索引 |
还有第二个影响面：LCP。懒加载会拖慢首屏最大内容的加载时间。如果首屏 Hero 图被加上 loading="lazy"，浏览器要等到布局计算完成才开始下载，LCP 可能从 1.8 秒涨到 3.2 秒。WordPress 从 5.5 起默认给正文图片加 loading="lazy"，这个默认值对首图是错的。
第三个影响面是无 JS 环境下的兜底。Google 抓取有时会拿到未渲染的 HTML（尤其是第一次抓取），如果此时 src 是占位图，那么这一轮抓取看到的就只有占位图。加 <noscript> 兜底是唯一的保险。
保姆级实操
步骤 1：先确认站点当前用的是哪种懒加载。 打开页面源码搜索 data-src、data-lazy-src、lazyload 类名。如果 src 是 1×1 灰色占位图或 base64，说明是 JS 方案；如果 <img> 上有 loading="lazy" 且 src 是真实地址，说明是原生方案。
步骤 2：WordPress 里统一到原生方案，并让首图保持 eager。 用官方提供的过滤器控制：
// functions.php：正文首图立即加载，其余图片保持原生懒加载
add_filter( 'wp_img_tag_add_loading_attr', function ( $value, $image_html, $context ) {
static $seen = 0;
$seen++;
// 第一张图（通常是 LCP 元素）不做懒加载
return ( 1 === $seen ) ? 'eager' : 'lazy';
}, 10, 3 );
// 若某个模板完全不需要懒加载（如产品详情页首屏画廊），按 context 关闭
add_filter( 'wp_lazy_loading_enabled', function ( $default, $tag_name, $context ) {
if ( 'wp_get_attachment_image' === $context && is_singular( 'product' ) ) {
return false;
}
return $default;
}, 10, 3 );
步骤 3：给 LCP 图补上优先级提示。 光去掉 lazy 还不够，还要让浏览器尽早开始下载：
<img src="/wp-content/uploads/2026/01/hero-guide-cover.webp"
width="1200" height="675"
loading="eager" fetchpriority="high" decoding="sync"
alt="WordPress Google SEO 完整指南封面图">
步骤 4：给 JS 方案补 <noscript> 兜底。 如果因为历史原因必须用 JS 懒加载，务必同时输出真实地址的 <noscript> 版本，这是 Google 官方文档明确推荐的做法。
步骤 5：禁用重复的懒加载实现。 缓存插件（WP Rocket、LiteSpeed Cache、Autoptimize）与主题往往各自实现一套，同时开启会互相替换 src。只保留一套，推荐保留原生 + 缓存插件的懒加载关闭。
步骤 6：用网址检查工具验证。 打开 GSC 网址检查 → 「测试实际网页」→ 「查看已抓取的页面」，在 HTML 里搜索图片文件名，确认 src 是真实地址；再看「更多详情」里的资源加载情况，图片若显示 404 或被屏蔽，说明 CDN 或防盗链有问题。
常见踩坑
- 首图被加上
loading="lazy"，LCP 变差，PSI 分数反而下降。 - 两套懒加载叠加，
src被换成占位图，Googlebot 只看到占位图。 - 依赖
scroll事件的自定义脚本，Googlebot 不滚动，图片永远不加载。 noscript兜底里放的是占位图，兜底形同虚设。- 懒加载了 iframe（YouTube 嵌入），视频缩略图与标题不进索引，视频表现受损。
- 案例：某测评站用了主题自带的
data-src懒加载，同时开启了 WP Rocket 的懒加载。两个插件都去改src，最终输出的src是 1×1 的透明 GIF，真实地址在data-original。Google 图片搜索展现量三个月内从每月 8000 跌到不足 500，关闭主题自带方案、保留原生loading="lazy"并在首图上去掉 lazy 后，六周恢复到每月 7000 以上。 - 把
loading="lazy"加在 CSS 背景图上，属性完全无效，白改一场。 - 误以为关掉懒加载就能提升排名，实际上懒加载只是体验项，图片能否索引取决于
src是否真实存在，这一点与 图片 SEO 优化 里讲的文件名和 ALT 属于不同环节。
总结
判断标准很简单：用无 JS 的方式（curl 或「查看源代码」）看页面 HTML，图片的真实地址是否直接写在 src 里——写在了，Google 就能索引；只写在 data-* 里且没有 <noscript> 兜底，就一定有问题。执行上推荐统一到浏览器原生 loading="lazy"，用 wp_img_tag_add_loading_attr 让首图保持 eager 并加 fetchpriority="high"，同时关闭主题与缓存插件里重复的懒加载实现。改完必须用「查看已抓取的页面」确认渲染后的 HTML。图片格式与体积的处理另行参考 WebP AVIF 图片格式。
