前端框架普及之后，一个很常见的现象是：页面在浏览器里打开完全正常，标题、正文、图片一应俱全，但用抓取工具请求同一个 URL，拿回来的 HTML 里只有一行挂载节点和一串 script 标签。这类页面的收录问题，往往不是“质量不够”，而是搜索系统在第一轮根本看不到内容。
第一轮看到的是什么
处理一个 URL 大致会经过抓取、解析、渲染、索引几步。抓取阶段拿到的，是服务器直接返回的原始响应体；渲染阶段才会执行 JavaScript，把页面补全。渲染要消耗资源，通常有排队和次数上的限制，所以靠 JS 渲染的页面，从被发现到进入索引这条链更长，中间任何一环出问题，表现出来都是“抓了但没收”。
关键在于：如果原始 HTML 里几乎没有可读内容，系统在这一步能拿到的判断依据就非常少——很难判断这页讲的是什么、和其他页面有什么区别、值不值得再花资源渲染一次。
三种渲染方式的现实差别
- 服务端渲染（SSR）：返回的 HTML 里就带正文，抓取阶段即可拿到主要信息，后续渲染只做补充。
- 客户端渲染（CSR）：正文要等浏览器执行 JS 才出现，抓取阶段近乎空白，收录更依赖渲染资源，节奏更慢。
- 静态生成或预渲染：构建时就产出 HTML，成本最低，表现也最稳定。
如果站点是 CSR，也不必立刻重写，但至少要让核心内容在原始 HTML 中有一份可读版本，比如标题、首屏正文和关键说明。
自查：直接去看原始响应
最简单的办法是关掉浏览器 JavaScript，或者用命令行请求页面，查看返回内容：
- 页面主标题、正文首段是否出现在原始 HTML 中；
- 页面之间的差异内容（文章标题、商品名称等）是否写在 HTML 里，而不是渲染后才填充；
- 内链是否写死在 HTML 中。链接靠 JS 生成，会直接影响 URL 发现。
排查顺序建议
- 先确认抓取本身是否正常：状态码是不是 200，返回的是不是预期的 HTML，而不是空壳或错误页。
- 再看原始 HTML 有没有内容：完全没有可读文本时，先补预渲染或 SSR，再谈其他。
- 检查渲染依赖有没有被阻断：JS、CSS 文件如果被 robots.txt 屏蔽，渲染结果会和用户看到的不一致。
- 确认渲染后的内容能取到：有些页面执行 JS 后要等接口数据，而接口本身有限制，渲染出来仍是空的。
- 最后才看内容和质量层面：在能看到内容的前提下，再判断重复、薄内容、聚合页这些问题。
内容藏在交互之后，也会被漏掉
标签页切换、点击“加载更多”、无限滚动，这些交互之后才出现的内容，很可能不在首屏渲染范围内。希望被收录的信息，尽量让它默认展开，或者为每一块可独立访问的内容提供单独 URL。
容易被忽略的几个细节
- 首屏渲染时间过长，渲染超时后抓到的仍是空页；
- 同一份内容存在两种渲染结果（用户看到 A，抓取看到 B），造成理解偏差；
- 移动端与桌面端渲染逻辑不同，只优化了其中一端；
- 预渲染只对部分 UA 生效，测试环境和实际抓取表现不一致。
渲染方式影响的是“能不能看到内容”这一步，它不决定最终结果。内容能被看到之后，还有页面价值、重复程度、站点整体质量等判断在后面。
小结一下：JS 渲染的站点，排查时不要一上来就怀疑内容质量，先把“抓取阶段能看到什么”确认清楚。原始 HTML 里有内容，后面的讨论才有基础；原始 HTML 是空壳，其他优化基本都落不到实处。