蜘蛛池入口頁的作用很單一：让抓取端顺着連結繼續往前走。頁面好不好看不是重点，重点是連結有没有出現在返回的 HTML 里、需不需要額外請求才能拿到。渲染方式的選擇不是技術偏好問题，而是抓取成本問题。
抓取端到底拿到了什么
多數搜尋引擎爬虫不會像真實浏览器那样把頁面完整跑一遍脚本。它先請求 HTML，從源碼里找連結和文本，再判断是否值得繼續渲染。同一套模板，用不同方式渲染，抓取端看到的可能是两回事。
三種渲染方式的差別
- 静態 HTML：連結和文本直接寫在源碼里，一次請求就能拿到。抓取成本最低，改動最直接，适合结构简單的入口頁。
- 服務端渲染（SSR）：HTML 在服務端拼好再返回，抓取端看到的和静態頁接近，但渲染開销由服務器承担。入口頁多的时候，要留意响應時間和並發压力。
- 前端渲染（CSR）：源碼里只有骨架和脚本，連結要等脚本执行完才出現。對抓取端来说，這等于多了一层不确定：有的渲染，有的不渲染，有的是延迟渲染。
怎么快速判断自己的入口頁属于哪種
- 用命令行直接抓源碼：curl -s 頁面地址 | head -c 2000，看連結是否已经出現在返回内容中。
- 關掉浏览器脚本，或者直接看 view-source，頁面结构和連結還在不在。
- 對照抓取日誌：入口頁有訪問记錄，但目标頁長期没有到達，常常說明連結不在首屏 HTML 里。
- 检查首屏内容是不是异步接口填進去的，比如列表資料靠前端請求返回。
渐進增强是更稳的做法
如果必须用前端框架，優先把連結和關键文本放在服務端輸出的 HTML 里，脚本只负责交互增强。這样即使渲染没被执行，抓取端也能顺着連結走。列表頁可以静態輸出第一頁，翻頁和篩選再交给脚本接管。
预渲染與動態渲染的适用场景
頁面數量可控、模板變化不频繁时，可以用预渲染把结果提前生成好；請求来源比較复杂时，也可以考虑對抓取端返回渲染完成的版本。這類方案维護成本更高，需要保證不同版本内容一致，否則容易出現頁面内容對不上、連結失效的情况。
常见誤区
- 認為浏览器能看到，爬虫就能看到。执行环境不同，不能直接画等号。
- 入口頁引入大量第三方脚本和統計代碼，拖慢首屏輸出，把预算耗在等待上。
- 用前端路由拼連結，没有可抓取的 href，只能靠脚本点击触發。
- 正文和連結全靠异步接口返回，抓取时拿到的只是空壳。
落地建议
- 入口頁尽量用静態 HTML 或服務端渲染輸出，連結寫成标准 a 标簽。
- 控制頁面体积，把非必要脚本去掉或改為延迟加载。
- 新做的入口頁先小批量上线，對照日誌確認目标頁有到達，再考虑扩大規模。
- 定期抽查线上源碼，確認渲染方式在上线後没有被改坏。
渲染方式本身不會带来收錄，它只决定抓取端能不能顺畅發現連結。把入口頁做“能被讀到”，比做“看起来很完整”更實际。
把渲染方式当抓取鏈路上的一环来看，和响應速度、狀態碼、入口頁規模一起考虑，通常比單獨優化某一項更有用。