用搜尋引擎的 URL 检查工具或直接翻索引结果时，偶尔會遇到一種別扭的情况：标题、網址都對得上，抓取時間也很新，但快照里的正文几乎是空的，只剩導航、頁脚和一句加载提示。這類頁面常被誤判成“内容质量差”，其實更常见的原因是：搜尋引擎在收錄时看到的那份 HTML 里，本来就没有正文。
先把“空”分成三種
同样是空白，成因並不一样，先归類再排查會快很多。
- 初始 HTML 里就没有正文：服務器返回的源碼只有框架和脚本，内容要靠浏览器执行 JS 之後才出現。
- 有渲染，但渲染失敗：JS 能跑，可它要請求的接口被挡、需要登入態或依赖时效 token，执行完依然是空。
- 内容存在但没被算進去：正文靠滚動或点击才插入，或者被遮罩层、折叠面板藏起来，首屏之外的部分没進快照。
按顺序核對的四步
- 看無 JS 的源碼。用 curl 抓一次原始响應，或在浏览器里禁用 JavaScript 後刷新，看看正文是否還在。如果這时頁面是空的，問题就落在渲染环节，而不是内容本身。
- 看 robots.txt 是否挡了资源。有些站点只允许抓 HTML，顺手把 JS、CSS 或接口路径一起屏蔽了。渲染需要的资源取不到，頁面自然渲染不出来。
- 看接口的可抓性。資料接口是否需要 Cookie、登入態、Referer，或者 URL 里带了會過期的簽名參數。這類接口對普通浏览器有效，對爬虫往往無效。
- 看内容的触發方式。正文是否只在滚動到某個位置、点击“展開更多”之後才加载；折叠起来的内容是否连 DOM 都没生成。
几個容易忽略的细节
渲染不是無限期的
搜尋引擎愿意為頁面执行 JS，但通常有時間與资源上的限制。頁面依赖的脚本越多、請求鏈越長，渲染出完整内容的概率越低。把關键内容拆成多次异步請求，等于把風險叠加起来。
分頁與折叠最好给獨立 URL
如果長文被拆成“点击加载下一頁”，或者评论区預設收起，搜尋引擎很可能只看到第一段。给分頁、展開後的内容一個可通過連結直接訪問的地址，比依赖交互更稳。
同一頁面在不同引擎下表現可能不同
各家的渲染能力、资源配額和等待時間並不一致。同一個 URL 在一個引擎里快照正常、在另一個引擎里是空壳，這種情况並不罕见，核對时最好分引擎各看一次。
可以落地的調整方向
- 對正文頁做服務端渲染或预渲染，让初始 HTML 至少带上标题、正文主体和關键連結。
- 放開渲染所需的 JS、CSS 與資料接口，不要用 robots.txt 一刀切。
- 把核心内容放在首屏的 DOM 里，交互只负责展示，不负责生成。
- 改完後對比“渲染前源碼”和“渲染後 DOM”，確認差异确實缩小了。
- 保留一份抓取日誌，观察一段時間内的抓取與索引狀態，而不是看一次就下结论。
索引快照是搜尋引擎看到的那一份頁面，不是你打開浏览器时看到的那一份。核對收錄問题时，先對齐這两者，再谈内容质量。
前端渲染本身没有問题，問题在于有没有给爬虫留下一份能直接讀懂的内容。把這一层补上，剩下的收錄节奏交给時間就好。