现在的页面越来越多依赖前端渲染：图片滑到才加载，列表滚到底才追加，正文点开“展开全文”才出现。对用户来说体验顺滑，对搜索引擎蜘蛛来说，可能只看到一片空的容器。这篇文章从站点运营的角度，整理懒加载与无限滚动场景下的自查项，目的是让蜘蛛至少能拿到一份完整、可抓取的替代版本。

一、先分清三种“延迟”

它们的技术实现不同，出问题的地方也不同，分开查效率更高。

• 图片与视频懒加载：资源不是一开始就请求，而是进入视口才加载。
• 内容懒加载：正文、评论区、规格参数等模块，靠点击或滚动触发请求。
• 无限滚动：列表页滚动到底自动追加下一批条目，地址栏 URL 通常不变。

二、图片与视频懒加载的自查

这类最常见，也最容易修。

• 看初始 HTML 里 img 的 src 是不是空的或占位图，真实地址放在 data-src、data-original 这类自定义属性里。如果蜘蛛只读初始 HTML，它拿到的就是占位图。
• 检查是否用了 loading="lazy" 这类原生属性。原生懒加载由浏览器处理，一般不会把地址藏进自定义属性，风险相对小。
• picture 与 source 的 srcset 要能被读取，别只把地址写在脚本变量里。
• 用 CSS 背景图承载的内容图片，通常不会被当成内容图片处理，重要图片尽量用 img 输出。
• 可以在 noscript 里放一份不带懒加载的 img 作为兜底，但不要指望它一定被采用。
• 图片本身有独立价值（商品图、示意图、流程图）时，可以考虑用图片站点地图把地址直接列出来。

三、内容懒加载：别把正文藏在点击之后

有些站点把长文的第一段之外全部折叠，或者把参数表放在“展开”按钮后面。用户点一下无所谓，但如果默认状态下这些内容不在 HTML 里，蜘蛛也看不到。

• 优先做法是内容在初始 HTML 中完整输出，折叠只靠 CSS 控制显隐。
• 必须异步请求时，确认请求地址是普通 URL，可以直接访问，并且返回可解析的 HTML 或结构化数据。
• 评论区、问答区这类用户内容，如果对页面主题有价值，尽量让首屏能带出一部分。
• 用“查看源代码”和开发者工具里的“渲染后 DOM”两个视角各看一遍，两者的差异就是蜘蛛可能拿不到的部分。

四、无限滚动：给蜘蛛留一条翻页的路

无限滚动的核心问题是 URL 不变，蜘蛛无法把后续条目当成独立页面来发现。常见的处理方式：

1. 列表页保留传统的分页链接，比如第 2 页、第 3 页，滚动加载只是给用户的额外体验。
2. 每个详情条目都有自己稳定可访问的 URL，并把这些地址放进站点地图，让蜘蛛绕开列表页直接发现。
3. 分页链接用真实的 a 标签 href，而不是 onclick 或按钮。蜘蛛跟随的是链接。
4. 如果用“加载更多”按钮，同样给它一个可访问的 URL 作为回退。
5. 注意别让滚动加载产生大量内容重复的页面，参数组合要控制住。

五、一份可执行的检查清单

• 关掉 JavaScript，或用只抓取 HTML 的方式看一眼页面，正文、图片、链接还剩多少。
• 抽查几条新发布的详情页，确认它们在不滚动、不点击的前提下能被链接到。
• 在站点地图里核对详情页数量与列表总数，差距很大通常意味着有内容没被暴露出来。
• 翻一翻服务端日志，如果蜘蛛抓的基本都是列表页，详情页几乎没有记录，这是很典型的信号。

六、修复顺序

先修影响面最大的：详情页的独立 URL 与站点地图覆盖，其次把正文从点击后面挪到初始 HTML，最后再处理图片懒加载的兜底。改完之后不必立刻期待变化，抓取和索引本身就有延迟，重点是让页面在“不执行脚本”的状态下，依然是一份说得通的内容。

懒加载是为了省资源，不是为了藏内容。判断标准很简单：把脚本关掉，页面还剩不剩下你想让蜘蛛看到的东西。