在網址检查里点開“已抓取的頁面”，标题、導航、頁脚都在，唯獨正文位置是一個空的容器，或者只有一行“加载中”。這種現象在索引里通常表現為：頁面能被收錄，但正文參與不了匹配，流量自然起不来。問题基本不在收錄环节，而在于抓取發生的那一刻，正文有没有出現在 HTML 里。
第一步：確認蜘蛛拿到的 HTML 里有没有正文
很多人判断“頁面正常”的依據是浏览器能打開，但浏览器里看到的是脚本执行之後的结果，两者不是一回事。核對时要看原始响應。
- 看已抓取的 HTML：在網址检查里查看抓取到的源碼，或在服務器日誌里找到對應的抓取记錄，再用抓取工具以相同 UA 請求一次。
- 關閉 JS 打開頁面：浏览器禁用脚本後重新加载，如果正文消失，說明内容依赖脚本生成。
- 對比两種结果的差异：如果静態 HTML 里有标题和 meta、正文為空，基本可以定性為渲染問题，而不是 robots、canonical 或狀態碼的問题。
第二步：分清站点用的是哪種渲染方式
纯客戶端渲染
HTML 基本是個壳，所有内容靠接口返回後拼装。這種结构對抓取最不友好：即便蜘蛛执行脚本，也要面對排队、超时和资源加载失敗的風險，能否拿到正文並不稳定。
服務端渲染與预渲染
服務端渲染下，正文随 HTML 一起返回，抓到的就是最终内容；预渲染則是在构建或請求时生成一份静態版本给蜘蛛。两者都能让正文進入 HTML，区別在维護成本和更新时效。
混合模式
首屏服務端渲染、後續交互交给前端，是目前較常见的做法。此时要確認的是：核心正文是否落在首屏 HTML 里，而不是等用戶点击或滚動之後才去請求。
第三步：逐項检查渲染鏈路上的拦路因素
- 脚本和接口是否被 robots.txt 屏蔽：JS 文件或資料接口被 Disallow，渲染自然拿不到内容。
- 接口是否需要登入態或特定請求头：蜘蛛没有 Cookie，請求會被拒绝。
- 内容是否在懒加载里：只有滚動到视口才触發請求，抓取时不會被触發。
- 资源是否超时或体积過大：渲染有時間與资源预算，等待太久會被放弃。
- 是否有前端报错：一個未捕获的異常就可能让整块内容不再渲染。
修复的方向
- 把核心正文改成服務端渲染或预渲染輸出，交互部分留在前端。
- 短期内無法改造时，至少保證正文在首屏 HTML 中以可讀文本形式存在。
- 接口不要屏蔽抓取，或為抓取提供不含鉴權的只讀路径。
- 取消正文区域的懒加载，图片可以懒加载，文字不要。
- 改完後用網址检查重新抓取一次，確認原始 HTML 里能看到正文，再观察索引變化。
判断标准很简單：如果關掉 JS 後頁面就没了内容，那索引里大概率也不會有内容。
最後提醒一点，把正文放進 HTML 只解决了“能被讀到”這一半，标题唯一、内鏈入口通畅、頁面本身有獨立價值，仍然是收錄和展示的前提。渲染問题解决之後，索引狀態的更新還需要一段時間，不必因為第二天没變化就反复改動结构。