不少站点把入口页做成前端渲染，链接由 JavaScript 在浏览器里拼出来。自己用浏览器打开一切正常，点得动、跳得走，于是默认搜索蜘蛛也一定看得到。实际情况要复杂一些：能不能发现链接，取决于渲染发生在什么时机、链接最终有没有落到 DOM 里，以及搜索引擎愿不愿意为这个页面消耗渲染资源。
先分清抓取和渲染是两步
现代搜索引擎处理一个页面，大致分两个阶段，而且这两步常常不在同一时间完成：
- 抓取原始 HTML：先请求服务器，拿到的是后端直接吐出的源码，此时页面上的 JS 一行都没跑。
- 渲染：把页面放进渲染队列，执行 JS、请求接口、生成 DOM，再从中抽取链接。
- 入队与跟进：只有渲染后出现在 DOM 里的 URL，才可能被加入待抓取队列。
关键在于：渲染是有成本的，队列有先后，不是每个页面都能立刻排上。如果入口页的链接只存在于第一个阶段的空白骨架里，而渲染又被延后甚至跳过，那这些链接在被抽取的那一轮就等于不存在。
哪些写法风险最大
- 纯客户端渲染的列表：HTML 里只有 <div></div>，链接全靠框架在浏览器里挂载。骨架里没有任何可读的 URL。
- 接口返回后才插入链接：先请求一个 JSON 接口，再用循环生成 a 标签。渲染时需要额外发一次请求，失败或超时就没有链接。
- 点击才生成：绑定 onclick 后用脚本跳转，DOM 里根本没有 href。这类地址对搜索蜘蛛来说不算链接。
- 懒加载＋滚动触发：链接排在视口之外，滚动才插入。渲染时的视口行为和真实浏览器不一定一致。
- 依赖用户状态：登录后才渲染的链接，蜘蛛没有会话，自然拿不到。
相对稳妥的做法
- 服务端渲染或预渲染：让入口页的 HTML 源码里就带着完整的 a 标签。这是最省心的方案，不依赖搜索引擎的渲染能力。
- 首屏同步输出链接：即使整体是前端应用，也尽量让关键链接在首次 HTML 响应中直接出现，后续再由 JS 接管交互。
- 保留一份静态列表：在页面底部或独立区块，用普通的 a 标签列出目标地址，不参与前端逻辑。
- 不要只在 noscript 里放链接：这条路径能否被采用，不同搜索引擎的处理并不一致，把它当成备份而不是主方案。
怎么验证搜索蜘蛛到底看到了什么
- 先看服务器日志里这个入口页的请求：返回的是完整 HTML，还是只有一张空壳。这一步只能确认抓取，不能确认渲染。
- 用带 JS 执行能力的抓取测试工具（搜索引擎官方提供的 URL 检查类工具）看一眼渲染后的 DOM，重点看链接在不在。
- 对比渲染前后的链接数量，如果差得很多，说明入口页对渲染的依赖过重。
- 观察目标页有没有出现来自入口页的抓取记录。注意这是相关信号，不是必然结果，别把时间上的先后直接当成因果。
蜘蛛池场景下的取舍
入口页本身的价值就在于“把 URL 摆到蜘蛛面前”，链路越短越可靠。在这类页面上堆前端框架、加接口请求，收益不明显，风险却实打实：一次渲染失败，整页链接就全丢了。更现实的做法是把入口页做得足够朴素——静态 HTML、直接可读的 a 标签、不依赖登录和交互。要做的复杂交互，放到目标页去实现。
判断标准可以很简单：把浏览器的 JS 关掉，刷新入口页，还能看到几个目标链接？如果答案是零，那这条链路就是把发现权完全交给了渲染，而渲染并不在你的控制范围内。
最后提醒一句：链接能被发现，不等于一定会被收录。入口页解决的是“看到 URL”，收录还要看目标页自身的内容质量、可访问性和站点整体情况。别把发现环节做得再漂亮，就当成收录的保证。