蜘蛛第一次拿到的往往是源码
在浏览器里打开入口页，你看到的是 JavaScript 执行、接口返回、样式渲染之后的画面。但搜索引擎蜘蛛第一次请求时，拿到的通常只是服务器返回的原始 HTML。如果页面主体、列表、链接都靠前端异步加载，蜘蛛在源码里可能只看到几个占位节点和一段脚本。
搜索引擎确实有渲染能力，会把部分页面放入渲染队列，执行 JavaScript 后再读取 DOM。但渲染不是无限资源：它要排队、要消耗抓取预算，而且不同搜索引擎、不同站点权重、不同页面类型得到的渲染机会并不一样。对蜘蛛池入口页来说，把“蜘蛛能看到什么”完全押在渲染上，风险偏高。
源码与渲染后 DOM 的差异在哪里
可以做一个简单对比：用查看网页源代码的方式看原始 HTML，再用搜索平台的 URL 检查工具看渲染后的 HTML。常见差异包括：
- 列表、导航、分页链接只存在于渲染后 DOM，源码里没有可跟随的链接。
- 正文文字由接口返回，源码中只有“加载中”或空容器。
- 链接用点击事件加 JavaScript 跳转，源码里没有标准 href。
- 部分内容被懒加载或折叠，蜘蛛不滚动、不点击就看不到。
为什么入口页尤其不适合只靠 JS
蜘蛛池入口页的核心任务，是让蜘蛛发现更多 URL、顺着链接继续走。如果入口页的链接都依赖 JavaScript 生成，蜘蛛在源码阶段就可能找不到出口。即便页面之后被渲染，也要等队列、等资源加载；如果脚本被 robots.txt 拦截、接口需要登录态、CDN 返回了错误版本，渲染结果也可能不完整。
另外，入口页数量一多，渲染成本会被放大。假设每个入口页都要执行大段脚本、请求多个接口，搜索引擎分配给这些页面的渲染时间很快被消耗掉。结果不是“蜘蛛看不到”，而是“蜘蛛看得慢、看得少”。
判断入口页对蜘蛛是否可读的步骤
- 先看原始 HTML：禁用浏览器 JavaScript，刷新页面，确认核心链接和文字是否还在。
- 用搜索平台的抓取诊断或 URL 检查：查看抓取到的 HTML 和渲染后 HTML 的差异。
- 看服务器日志：如果蜘蛛频繁抓取静态资源、接口，却很少抓取入口页里的目标 URL，说明链接发现可能受阻。
- 做一次“源码链接提取”：只从原始 HTML 里提取 a 标签，看能提取出多少入口页和目标页。
实用调整建议
如果入口页必须使用前端框架，至少做到以下几点：
- 关键链接服务端输出：导航、列表、分页、目标页链接尽量写在原始 HTML 里，使用标准 a 标签和 href。
- 正文优先静态或预渲染：入口页的介绍文字、分类说明、聚合内容可以服务端渲染或构建时生成，不必等接口。
- 避免纯 JS 跳转：不要只用 onclick 或路由脚本跳转，蜘蛛不一定会执行点击。
- 检查资源可抓取：不要让 robots.txt 误拦 JS、CSS 或接口，否则渲染结果会缺样式、缺数据。
- 控制脚本体积和请求数：入口页不是应用主界面，能少一个依赖就少一个，给渲染留余量。
别把渲染当作收录捷径
JavaScript 渲染只是让蜘蛛多一种读取方式，不是收录或排名的保证。入口页真正稳定的做法，仍然是让服务器直接返回可读的 HTML：蜘蛛请求一次就能拿到文字和链接，不必等待二次渲染。把入口页做成“源码可读、渲染后更好”，比“源码空壳、全靠渲染”更可控。
先保证蜘蛛在源码阶段就能找到路，再考虑用 JavaScript 做体验增强。顺序反了，入口页就容易变成只给自己看的页面。