不少蜘蛛池入口页为了省事，把正文、链接甚至跳转都交给 JavaScript 去生成。站点在浏览器里看着没问题，但蜘蛛拿到的可能只是一段空壳 HTML。这篇文章讨论入口页用 JS 渲染时实际会发生什么，以及怎么取舍。
蜘蛛拿到的第一份 HTML 才是关键
搜索引擎的抓取一般分两步：先按 URL 请求一次，拿到服务器返回的原始响应；如果页面需要渲染，才排进渲染队列，用类似无头浏览器的方式再跑一遍 JavaScript。问题在于第二步不是必然发生，而且通常有延迟和配额限制。
- 渲染队列有积压，新域名、低权重 URL 可能等很久，甚至等不到。
- 渲染会消耗额外资源，搜索引擎会控制每个站点的渲染次数。
- 如果初始 HTML 里既没有正文也没有链接，蜘蛛这一轮能“发现”的东西基本为零。
所以入口页的核心目标——被发现、被继续抓取——最好在第一份 HTML 里就完成。
入口页常见的三种渲染方式
服务端渲染或静态输出
内容在服务器端拼好再返回，蜘蛛拿到什么，用户大致也看到什么。入口页的链接、标题、可读文本都在这份 HTML 里，是最省事也最稳的做法，纯静态页面尤其如此。
客户端渲染
返回的 HTML 几乎是空模板，内容靠接口回来后插入 DOM。对用户没问题，对蜘蛛要看渲染服务的脸色。入口页如果只有一条 JS 跳转，比如 location.href 或框架路由，风险更明显：蜘蛛可能既不读内容，也读不到跳转目标。
混合渲染
首屏关键部分服务端输出，其余交互由 JS 增强。这是折中方案，入口页建议至少把链接和短文本放进初始 HTML。
判断标准很简单：把浏览器 JavaScript 关掉刷新一次，页面上还剩多少能读的文本和能点的链接？剩得越少，入口页的价值越依赖渲染服务，可控性就越低。
几个容易踩的误区
- 把蜘蛛等同浏览器。蜘蛛的渲染能力、版本、执行时间都和你的浏览器不同，本地测试通过不代表抓取时也能跑通。
- 用 JS 跳转代替 HTTP 跳转。能用 301/302 表达的跳转交给 JS 去做，等于把结果交给不确定的渲染环节。
- 内容藏在接口里。接口地址如果没在 HTML 里出现，蜘蛛没有理由去请求它。
- 依赖登录态或 Cookie。渲染环境通常不带你的会话，靠 Cookie 判断展示内容，蜘蛛看到的往往和你不一样。
- 第三方脚本过多。渲染超时经常卡在加载慢的外部资源上，页面越重，渲染越容易失败。
怎么验证蜘蛛看到了什么
- 关闭 JS 或禁用脚本，直接看页面源码里有没有正文和链接。
- 用 curl 或抓包工具请求一次，确认响应体里包含关键内容，而不是待填充的容器。
- 查看服务器日志，观察同一 URL 是否出现多次请求（一次取 HTML，一次取渲染资源），渲染请求频繁失败通常有迹可循。
- 使用搜索引擎官方提供的抓取测试工具，对比返回的 HTML 与渲染后结果。
给入口页的几点建议
- 蜘蛛池入口页优先用服务端渲染或纯静态输出，成本低、结果可预期。
- JS 做增强，不做地基：跳转、链接、核心文本放在初始 HTML 中。
- 减少首屏依赖的外部请求，降低渲染超时概率。
- 跳转、状态码、robots 相关指令按 HTTP 层面处理，别用脚本模拟。
- 改版后重新验证一次原始 HTML，避免构建流程改动把内容推到客户端。
入口页是否要渲染，本质是“把不确定性放在哪一环”的问题。把内容放在第一份 HTML 里，后面任何环节出问题，损失都有限；全部押在 JavaScript 上，就等于把入口页是否有效交给渲染队列去决定。