有时會遇到這種情况：某個 URL 已经出現在搜尋结果里，标题也正确，但摘要和正文是空的，或者只剩導航和一行占位文字。点進去看頁面是正常的，因為浏览器执行了 JavaScript。問题不在“有没有收錄”這一步，而在抓取之後的渲染环节。
抓取到的版本和渲染後的版本，不是同一份
搜尋引擎先按 URL 請求服務器，拿到原始 HTML。如果正文是頁面加载後由 JS 寫進 DOM 的，原始 HTML 里就只有空容器。之後這批 URL 會進入渲染队列，用無头浏览器再跑一遍，這时才可能看到完整内容。
關键在于，渲染是排队执行的，不是抓完立刻渲染。队列有優先級，頁面越重、依赖越多，等待越久；渲染失敗、超时或中途报错，索引里留下的就可能是那份原始 HTML 的版本。
几個常见原因
- 正文完全由 JS 注入：不执行脚本的抓取看不到任何内容。
- JS、CSS 或接口路径被 robots.txt 挡住：渲染需要自己去請求這些资源，被禁止抓取後就拿不到資料。
- 内容要交互才出現：点标簽頁、展開折叠、滚動到一定位置才加载。
- 請求依赖登入態或特定請求头：渲染請求通常不带用戶會话。
- 超时或资源過重：首屏脚本太大、串行請求太多，渲染在超时前没跑完。
- 前端报错：接口结构變化、跨域限制、版本不匹配，頁面渲染到一半停住。
自查顺序
- 用 URL 检查類工具對比“原始 HTML”和“渲染後的 HTML”，看正文是否出現在後者里。如果两邊都空，問题在資料层，不在渲染层。
- 禁用 JS，或用 curl 直接請求该 URL，看返回的 HTML 里有没有正文。這一步最直观。
- 检查 robots.txt 是否誤封了 JS、CSS、图片或接口路径，這是最常见的隐性原因。
- 检查接口返回是否依赖時間、地区、登入態或随机參數。
- 看渲染日誌與頁面性能：首屏脚本体积、外部請求數量、有没有長時間阻塞。
處理方向
核心内容尽量在服務端輸出：标题、正文、價格、主要連結直接寫在 HTML 里。交互增强的部分可以繼續用 JS 做，但不應该由它决定頁面“有没有内容”。
需要滚動或点击才加载的列表，尽量保留一组可抓取的分頁 URL，而不是只有無限滚動。
noscript 里放一段提示，不能替代真正的服務端輸出，抓取工具也不會把它当成正文的备選。
如果正文只有执行脚本後才存在，就別把“是否收錄”当成唯一指标——索引里的内容是否完整，需要單獨核對。
最後一句
收錄只說明 URL 進了索引，不代表索引里的内容可用。對依赖前端框架的站点，建议把“渲染後的 HTML 是否包含正文”列為固定检查項，尤其在改版、換框架或調整接口之後。