先分清“源码里有什么”和“浏览器里看到什么”
在浏览器里右键查看网页源代码，看到的是服务器返回的那份 HTML；而按 F12 打开的“审查元素”面板，展示的是脚本执行之后、经过浏览器加工过的 DOM。这两者经常差别很大。前者是抓取时优先拿到的东西，后者才是用户看到的画面。很多“内容不收录”的疑问，源头就在于把两者当成了一回事。
自查的第一个动作很简单：把正文里最核心的一段话复制出来，在查看源代码的页面里搜一下。搜得到，说明内容在初始 HTML 中；搜不到，就要考虑脚本渲染的问题。
几个常见的“正文藏在脚本后面”的场景
无限滚动与“加载更多”按钮
列表页只输出前十条，后面的靠滚动触发接口。用户滑得开心，但抓取端往往不会主动滚动，也不会去点按钮。结果是后续内容既没有入口链接，也没有可抓的地址。
选项卡与折叠面板
同一个页面用 Tab 切换“简介 / 参数 / 评价”，只有当前选中的那部分在 HTML 里，其余靠脚本注入。这类内容常常是页面里最有价值的部分，却默认藏在后面。
客户端路由
单页应用里，从列表点到详情，地址变了、画面变了，但请求的是同一份 HTML。如果没有服务端直出或预渲染，详情页的标题、正文都可能不在初始响应中。
自查的几条实操路径
- 用命令行工具抓一次页面，例如用 curl 输出 HTML，保存成文件后搜索正文关键词。
- 对照工具里的抓取方式报告，看看是否存在“仅通过渲染才发现的内容”。
- 在浏览器里禁用 JS 后刷新页面，看还剩多少可读内容。剩下的部分，大致就是初始 HTML 的成色。
- 逐条检查列表页的“加载更多”：这些后续条目有没有独立的、可点开的 URL。
- 把站点地图与实际可抓地址对一遍，确认动态加载出来的页面是否也在清单里。
处理思路：能让内容先在 HTML 里出现，就别赌渲染
- 关键内容优先直出。标题、正文首段、面包屑、主要导航，这些放在服务端渲染里最稳妥。
- 分页改成真实链接。“加载更多”可以保留，但至少提供一个指向下一页的 a 标签，让抓取端有路可走。
- 图片用标准 img 标签。懒加载可以加 loading 属性或脚本增强，但 src 别留空，替代文本写清楚。
- 选项卡内容考虑全部输出。用 CSS 控制显示隐藏，比用脚本按需注入更容易被读到。
- 单页应用考虑预渲染或服务端渲染。这一步成本不低，但比反复猜测抓取效果更可控。
- 别忘了站点地图和分页入口。即使渲染问题暂时解决不了，也尽量让地址本身可被发现。
别走到另一个极端
把所有内容一次性塞进 HTML 也不总是好事：首屏体积变大、加载变慢，反而影响体验。更实际的做法是先分清哪些是“必须被抓到”的核心内容，哪些只是交互增强，然后只对前者做直出处理。
另外，渲染方式只是影响抓取的因素之一，最终能否被抓到、以什么形式展示，仍由抓取方决定。自查的意义在于减少不确定性，而不是保证结果。
把“用户能看到”和“抓取端能拿到”当成两件事分别检查，是站点运营里性价比很高的一项日常工作。每次改版或上线新栏目之后跑一遍，问题通常能在早期被发现。