入口頁要完成的事很简單：让蜘蛛進来、看到正文和指向目标站的連結，然後顺着連結走。但這份内容到底是寫在 HTML 里發出去的，還是等浏览器执行 JS 之後再拼出来的，會直接决定蜘蛛第一轮抓取能拿到什么。
蜘蛛抓取时看到的到底是什么
大多數搜尋引擎蜘蛛發起請求後，拿到的是 HTTP 响應体，主体是 HTML。如果正文和連結依赖 JS 再請求接口渲染，蜘蛛第一轮可能只看到一個空壳，真正的連結一條都看不到。
常见的三種渲染方式，在入口頁上的表現差別很明顯：
- 服務端渲染（SSR）：响應体里就有正文和 a 标簽，蜘蛛一次請求即可完成發現。
- 静態生成（SSG）：构建时产出 HTML，效果接近 SSR，适合入口頁這種内容變動不频繁的頁面。
- 客戶端渲染（CSR）：HTML 里只有挂载点和 script，正文、連結都要等 JS 执行完才出現。
現在的搜尋引擎确實有渲染队列，會把部分頁面丢進無头浏览器做二次渲染。但那是排队的、有配額的、也會延迟的。入口頁的核心價值是“被尽快發現”，把這件事押在二次渲染上，不确定性偏高。
入口頁最怕被 JS 拦住的几類元素
判断标准只有一個：不看浏览器，只看响應体里有什么。
- 指向目标站的連結。如果 a 标簽是 JS 動態插入的，首轮抓取很可能不存在。
- 分頁和列表的“下一頁”。無限滚動尤其容易被漏掉。
- 正文段落。纯 CSR 的情况下，首轮几乎是空文本。
- canonical、robots meta 這類头部信息。最好直接寫在原始 HTML 里，靠 JS 注入容易出問题。
折中做法：首屏直出，交互再交给 JS
入口頁通常不需要复杂交互，把關键内容直出的成本其實很低。
- 入口頁用 SSR 或静態生成，保證 HTML 里有正文、有可爬的連結。
- 篩選、展開這類交互再用 JS 增强，但別让它承担生成連結的职责。
- 确實需要 CSR 时，至少给關键導航留一份服務端直出的兜底版本。
- 核對时看“查看源代碼”，而不是“审查元素”，两者看到的不是同一份東西。
怎么自查渲染是否挡住了蜘蛛
- 用 curl 直接請求入口頁，在响應体里搜尋那個目标連結是否存在。
- 關閉浏览器 JS 後再訪問一次，看頁面還剩多少可用内容。
- 翻服務器訪問日誌，看蜘蛛請求的是 HTML 頁面還是渲染接口。
- 用平台提供的抓取測試工具看快照，但要注意它展示的是渲染後的结果，不等于首次抓取看到的内容。
常见的誤判是：本地浏览器打開一切正常，就預設蜘蛛也没問题。浏览器执行了 JS，而服務器日誌里那一轮抓取可能只走到 HTML 為止，两者並不是一回事。
几個容易忽略的细节
- 入口頁结构简單、体积小，做 SSR 的成本通常不高，不必為了技術栈统一而全站 CSR。
- 按 UA 返回不同版本的動態渲染，對主流搜尋引擎已不太必要，反而容易出現内容不一致。
- JS 渲染依赖的接口若被限流或需要鉴權，渲染队列同样拿不到内容。
- 渲染耗时過長會被判定超时，蜘蛛放弃离開，這一趟等于白来。
寫在最後
入口頁的职责是让蜘蛛發現 URL，這件事本身並不需要复杂的客戶端渲染。把正文和連結放進首轮的 HTML，是成本最低也最稳的做法。要不要上 CSR，取决于頁面有没有真正的交互需求，而不是取决于前端脚手架的預設配置。