抓取和渲染是两步，第二步不一定發生
用前端框架搭建的站点，经常出現這種情况：浏览器里打開一切正常，查看網頁源代碼却只有一個空的容器元素和一堆脚本。搜尋引擎蜘蛛第一次抓取时拿到的就是這份源碼。多數主流搜尋引擎具备执行 JavaScript 的能力，但這個执行發生在抓取之後的渲染环节，属于第二步。第一步和第二步之間，存在時間差、资源限制和失敗的可能。
也就是说，能被抓取，不等于能被渲染；能被渲染，也不等于渲染结果和你看到的一致。把頁面当成“反正搜尋引擎會渲染”来處理，風險在于你無法確認第二步是否真的跑成功了。
先確認蜘蛛到底看到了什么
排查這類問题，第一步不是改代碼，而是確認現状。几個成本很低的办法：
- 關閉浏览器 JavaScript，或者直接查看網頁源代碼，看首屏正文是否出現在 HTML 里。如果源碼里找不到正文文字，那蜘蛛第一轮看到的大概率也是没有正文的版本。
- 用抓取工具或命令行拉取頁面，確認返回的 HTML 與源碼一致，排除本地缓存造成的错觉。
- 在搜尋引擎站長平台里使用 URL 检查類工具，查看“已抓取的 HTML”與渲染後的截图。這一項能直接回答渲染有没有成功。
- 翻服務器日誌，看蜘蛛是否請求了 JS 和 CSS 文件。如果日誌里只有 HTML 請求、完全没有静態资源請求，渲染基本不可能顺利完成。
這几步做完，問题通常能定位在發現、抓取還是渲染中的某一环，而不是笼统地归因為不被收錄。
几種典型的空壳情形
首屏内容全靠接口拉取
HTML 只负责挂载，标题、正文、價格、列表全部由接口返回後填充。接口一旦需要登入態、簽名、特定来源校驗，或者對高频請求做了限制，渲染就可能中断，頁面在索引侧呈現為一個没有實质内容的頁面。
關键的 JS 和 CSS 被 robots.txt 屏蔽
有的站点為了节省抓取资源，把脚本目錄、样式目錄甚至接口路径一起屏蔽掉。這個動作的本意通常是好的，但结果是渲染环节拿不到必要的资源，頁面结构無法成型。除非確認這些资源對頁面呈現没有影响，否則不建议屏蔽。
内容藏在交互之後
正文要点击“展開全文”、切換标簽頁、滚動到底部才加载。渲染工具不會主動去点按钮，這類内容在渲染结果里往往缺失。
渲染超时或报错
第三方脚本過多、接口响應慢、某個 JS 报错中断了後續执行，都會让渲染停在半路。這類問题在本地開發环境不容易复現，但在蜘蛛訪問的鏈路上很常见。
改動的優先級：從确定性最高的做起
- 把首屏關键内容放進 HTML。标题、主正文、核心參數這類决定頁面主题的内容，優先由服務端輸出。這一步收益最直接，也最不依赖外部條件。
- 保證渲染必需的资源可被抓取。核對 robots.txt，確認 JS、CSS 以及渲染时需要調用的接口没有被誤伤。
- 给關键内容加兜底。如果确實無法服務端渲染，至少用预渲染或静態化的方式，為内容頁生成一份带正文的 HTML 版本。
- 减少首屏對外部脚本的依赖。統計、客服、营销脚本尽量异步加载，不要阻塞主内容的渲染。
- 用無 JS 环境定期自查。把這一步放進上线前的检查清單，比事後從索引里倒推問题要省事。
不是所有頁面都值得投入渲染改造
服務端渲染、预渲染都會增加開發和维護成本，没有必要全站铺開。内容頁、商品頁、文章詳情頁這類承担索引任務的頁面，優先級最高；登入後的個人中心、後台管理、一次性的活動頁，通常不需要為索引做額外處理。取舍的标准很简單：這個頁面是否希望出現在搜尋结果里，且它的主要内容是否依赖客戶端执行。
渲染能力是搜尋引擎提供的一種便利，不是一份可以無限依赖的保證。頁面越少依赖 JavaScript 才能呈現，抓取與索引之間的不确定性就越小。
如果你在日誌里看到蜘蛛频繁訪問 HTML 却几乎不請求静態资源，或者 URL 检查工具里渲染後依然空白，可以先從空壳這個方向查起，而不是急着調整別的東西。