先分清三種渲染方式
同一個頁面，用戶和爬虫拿到的 HTML 可能完全不同。先確認自己的頁面属于哪一類，再谈收錄，判断會稳很多。
- 服務端渲染（SSR）：請求返回的 HTML 里就带正文，爬虫不需要执行脚本。
- 预渲染或同构：首屏在服務端或构建时生成，後續交互交给 JS 接管，初始 HTML 里通常已经有主体内容。
- 纯客戶端渲染（CSR）：返回的 HTML 只有一個空壳和几個 script 标簽，正文要等 JS 执行、接口返回資料之後才出現。
收錄表現的差距主要来自這里。CSR 頁面要经過两步處理：先抓 HTML，再排队渲染。渲染失敗、超时或被拦截，最终進入索引的可能就是一個空壳。
核對顺序：先看抓到的 HTML，再看渲染後的结果
- 禁用 JS 打開頁面，或直接查看網頁源代碼，確認标题、正文、主要連結是否出現在初始响應里。
- 检查狀態碼、canonical、meta robots 是否由服務端輸出。這些信号如果靠 JS 注入，很容易在渲染环节丢失。
- 確認渲染所需的資料接口没有被 robots.txt 拦住。接口路径被屏蔽，等于正文永遠拿不到。
- 對比渲染後的 DOM 與接口返回的資料，看有没有因為登入態、地区判断或灰度策略返回空内容。
- 回到抓取日誌，看蜘蛛請求的是完整頁面，還是只带走了那份空壳 HTML。
抓取與收錄在這里最容易混在一起
日誌里看到蜘蛛来過，只能說明它抓住了那份 HTML。是否入库還取决于渲染這一步能不能拿到足够的主体内容。如果初始 HTML 里没有正文，渲染又依赖大量脚本和串行接口，頁面很可能長期停在“已發現”，或者干脆不進索引。這不是抓取失敗，而是抓到的版本没有可用内容。
渲染成本與抓取预算
搜尋引擎渲染頁面是有成本的，通常不會對每個 URL 都完整渲染一遍。頁面越依赖 JS，站点整体被渲染的比例就越低，新頁面等待入库的時間也更長。可以從這几處收敛：
- 首屏關键内容尽量服務端直出，交互部分再交给 JS。
- 减少首屏接口數量，避免多层串行請求。
- canonical、hreflang、结构化資料優先寫在服務端輸出的 HTML 里。
- 图片懒加载用原生 loading 属性，別让正文块在脚本执行後才挂载。
短時間内改不動框架怎么办
如果站点是纯前端框架搭的，短期改不成 SSR，可以先做预渲染：對内容型 URL 在构建或請求时生成静態 HTML，交互頁保持原样。這样至少让标题、正文、canonical 出現在初始响應里，收錄核對才有稳定的基准可對比。
判断标准很简單：禁用 JS 後打開頁面，如果核心正文、标题和主要連結都還在，收錄核對就少一层變量；如果只剩下一個空白容器，那就先把渲染問题解决，再谈其他收錄優化。
小结
核對渲染類頁面的收錄，顺序是先確認抓到的 HTML 里有什么，再確認渲染後能拿到什么，最後看日誌與索引狀態是否能對上。把“抓到了”和“内容够不够入库”分開看，很多看似矛盾的現象就说得通了。