入口页要完成的事很简单：让蜘蛛进来、看到正文和指向目标站的链接，然后顺着链接走。但这份内容到底是写在 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，取决于页面有没有真正的交互需求，而不是取决于前端脚手架的默认配置。