很多站点把正文做成滚动后才加载、点击才展开，或者塞进选项卡里。用户在浏览器里看得到，抓取端拿到的响应里却可能是空的。讨论收录之前，先确认内容是否出现在可抓取的响应中，这一步的优先级高于任何收录指令的调整。
抓取端看到的，和你看到的不是同一份页面
浏览器里内容可见，是因为 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 定期复查响应内容，确认没有悄悄退回空壳状态。
如果站点确实依赖前端渲染，抓取端需要走渲染队列，收录节奏会慢一些，渲染失败时还可能只看到一个空壳。对核心内容来说，服务端直接输出通常是最省事的做法。
收录是结果，不是开关。先把内容稳定地送到抓取端，再讨论索引和检索表现；顺序反了，调整指令往往解决不了真正的问题。