蜘蛛池入口頁的目标很單纯：让搜尋引擎爬虫能訪問到、能讀到内容、能顺着連結往下走。但很多入口頁在浏览器里看着正常，爬虫拿到的却是一具空壳，原因往往出在渲染方式上。這篇把“静態輸出還是 JS 渲染”這個問题拆開讲，给一個可执行的判断思路。
爬虫拿到的是响應体，不是浏览器画面
浏览器打開頁面时，先下载 HTML，再执行 JavaScript，把内容填進去，人眼看到的是执行之後的结果。搜尋引擎爬虫虽然也具备执行 JS 的能力，但那是有前提的：需要排队、需要額外资源，也可能因為各種原因没有执行。而蜘蛛池里的入口頁通常量大、内容薄、生命周期偏短，最不划算的就是让爬虫多绕一道。
判断标准很简單：不看浏览器里長什么样，看第一次响應里有什么。如果 HTML 源碼里只有几個容器标簽和一段脚本，正文、連結全靠 JS 拼出来，那這條路就多了一层不确定性。
两種做法各适合什么场景
服務端直出静態 HTML
- 响應体里直接带着标题、正文，以及指向目标頁的 a 标簽連結。
- 爬虫抓一次就拿到全部信息，不需要等待渲染。
- 内容体量小的入口頁几乎没有額外成本，主机压力也低。
- 調试直观：用命令行拉一次，就能看到爬虫能看到的版本。
前端 JS 渲染
- 适合内容由接口驱動、需要频繁變動的站点，但入口頁通常不属于這一類。
- 單頁應用如果只做前端路由跳轉，連結可能不是真正的 a 标簽，蜘蛛顺着走不動。
- 渲染服務本身可能被限速或被拦，等于给自己加了一道關卡。
容易出問题的几個细节
- 連結不是連結：用点击事件或路由跳轉實現的導航，爬虫识別不到 href，入口頁等于没有出口。
- 内容藏在接口里：正文靠前端請求資料再拼装，响應体里空無一物。
- 渲染超时或报错：脚本报错、第三方资源卡住，頁面就停在空白狀態。
- 懒加载過度：連結和正文都要滚動才出現，對自動抓取不友好。
上线前的自查步骤
- 用 curl 或 wget 拉一次原始 HTML，看正文和連結在不在里面。
- 在浏览器里查看源代碼（不是“检查元素”），確認内容不是执行後才出現的。
- 關掉 JavaScript 再打開一次頁面，看看還剩多少可讀内容。
- 检查跳轉是不是真的 a 标簽，href 是不是可訪問的路径。
- 必要时用搜尋引擎提供的 URL 检查工具，看一下抓取到的快照版本。
确實需要渲染时的折中办法
有些頁面离不開 JS，那就考虑预渲染或動態渲染：對普通用戶走正常流程，對识別出的爬虫 UA 直接返回渲染好的静態 HTML。這條路可行，但要注意两点：一是返回给爬虫的内容要和给用戶的一致，不要做两套；二是渲染服務本身要稳定，別在抓取高峰期掉线，否則一批入口頁會同时失效。
入口頁的第一原則是“能被低成本地讀懂”，而不是前端技術多先進。渲染越重，中間环节越多，出問题的机會也越多。
小结
绝大多數蜘蛛池入口頁，静態輸出就够了，而且更稳。只有在内容确實依赖接口、又無法在服務端预生成时，才考虑引入渲染方案，並且一定要先做完上面那几步自查。把“爬虫第一次請求能拿到什么”当成上线前的固定检查項，比事後翻服務器日誌找原因省事得多。