現在的頁面越来越多依赖前端渲染：图片滑到才加载，列表滚到底才追加，正文点開“展開全文”才出現。對用戶来说体驗顺滑，對搜尋引擎蜘蛛来说，可能只看到一片空的容器。這篇文章從站点运营的角度，整理懒加载與無限滚動场景下的自查項，目的是让蜘蛛至少能拿到一份完整、可抓取的替代版本。

一、先分清三種“延迟”

它們的技術實現不同，出問题的地方也不同，分開查效率更高。

• 图片與视频懒加载：资源不是一開始就請求，而是進入视口才加载。
• 内容懒加载：正文、评论区、規格參數等模块，靠点击或滚動触發請求。
• 無限滚動：列表頁滚動到底自動追加下一批條目，地址栏 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，最後再處理图片懒加载的兜底。改完之後不必立刻期待變化，抓取和索引本身就有延迟，重点是让頁面在“不执行脚本”的狀態下，依然是一份说得通的内容。

懒加载是為了省资源，不是為了藏内容。判断标准很简單：把脚本關掉，頁面還剩不剩下你想让蜘蛛看到的東西。