前端框架普及之後，一個很常见的現象是：頁面在浏览器里打開完全正常，标题、正文、图片一應俱全，但用抓取工具請求同一個 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 是空壳，其他優化基本都落不到實處。