很多站点把正文做成滚動後才加载、点击才展開，或者塞進選項卡里。用戶在浏览器里看得到，抓取端拿到的响應里却可能是空的。讨论收錄之前，先確認内容是否出現在可抓取的响應中，這一步的優先級高于任何收錄指令的調整。
抓取端看到的，和你看到的不是同一份頁面
浏览器里内容可见，是因為 JavaScript 已经执行並把节点补進了 DOM。抓取通常分两步：先取初始 HTML，必要时再進渲染队列。如果内容只在用戶交互之後才請求，比如点击“展開全文”、滚動到底部才發接口，這些動作在抓取過程中一般不會發生，内容自然進不了後續流程。
驗證方法很直接：用“查看網頁源代碼”而不是開發者工具的 Elements 面板，在源碼里搜尋正文的第一句话。搜得到，說明内容在初始响應里；搜不到，問题就不在收錄指令上。
三種常见寫法，風險各不相同
data-src 與滚動触發的延迟加载
图片、评论、相關阅讀用 data-src 或 data-original 延迟加载时，初始 HTML 里的 src 往往是空的。图片類资源通常依赖 src 和 alt 被理解，空 src 基本等于這張图不存在。如果连正文文字也是滚動之後才注入，風險同理。
“加载更多”與無限滚動
這類内容通常由接口返回，URL 不發生變化，後面的條目在抓取端等于不存在。真實分頁連結是让這些 URL 被發現的常規手段，不能只靠一次滚動。
選項卡與手風琴折叠
判断标准只有一個：内容在不在响應里。如果所有面板的文字本来就寫在 HTML 中，只是用 CSS 控制顯隐，通常仍可被抽取；如果是点击时才去 fetch，那就和上一類情况一样。
折叠内容會被降低评價吗
隐藏不等于不能被索引。用 CSS 或脚本隐藏、但确實存在于 DOM 中的内容，一般仍會被處理，只是其在頁面中的分量可能低于首屏可见内容。也就是说，問题通常不在“折叠”這個動作上，而在“内容压根没加载”。先把後者修好，再决定是否把關键信息提到首屏。
建议的核對顺序
- 用“查看網頁源代碼”打開目标頁，搜尋正文中的一句原文，確認是否出現在初始响應里。
- 關閉 JavaScript 或改用纯文本方式抓取，看正文是否仍然存在。
- 查服務器日誌或抓取日誌，對比该 URL 的响應体积，明顯偏小往往意味着正文没被返回。
- 確認内容是否依赖点击、滚動等交互才發起請求；如果是，把核心内容改為服務端輸出。
- 检查“加载更多”是否有對應的可連結 URL，能被連結到才可能被發現。
- 最後再看 canonical、noindex 等指令，避免指令层面的结论掩盖了内容缺失這一真實原因。
可以落地的調整
- 标题、正文和關键信息預設寫入初始 HTML，懒加载只留给次要图片和非核心模块。
- 图片懒加载保留 src 或提供 noscript 兜底，不要让 src 長期為空。
- 列表使用真實分頁連結，“加载更多”作為体驗增强而非唯一入口。
- 選項卡内容一次性輸出，用 CSS 控制顯示，不要点击後再取資料。
- 上线後從站点地图里抽几個 URL 定期复查响應内容，確認没有悄悄退回空壳狀態。
如果站点确實依赖前端渲染，抓取端需要走渲染队列，收錄节奏會慢一些，渲染失敗时還可能只看到一個空壳。對核心内容来说，服務端直接輸出通常是最省事的做法。
收錄是结果，不是開關。先把内容稳定地送到抓取端，再讨论索引和检索表現；顺序反了，調整指令往往解决不了真正的問题。