路径最深的那几个视图，蜘蛛从没到达过
用 AI 生成一个单页应用，现在是几分钟的事：一段提示词，几十个文件，跑起来界面流畅、切换丝滑，体感像是做好了一整套产品。交到百度面前，蜘蛛打开它，抓走了一个页面，走了。你数了数项目里明明有六个视图，收录里只躺着一个 URL。
渲染方式导致的收录问题，前面的文章已经拆过一轮：CSR 的空壳 HTML，蜘蛛拿不到内容。单页应用是同一个技术家族里更麻烦的一位：它连“页面”这个概念都被合并了。本文讲清楚两件事：为什么单页应用的视图难以被当成页面收录，以及怎么在不推翻 AI 生成成果的前提下，把视图一个个变成蜘蛛能独立访问的地址。
一、单页应用：一个文档装下多个视图
单页应用（SPA）的核心特征一句话能讲完：整个站只有一份 HTML 文档，用户看到的所有“页面”都是这份文档里的视图切换。点击导航时浏览器没有请求新文件，是 JS 把旧内容从 DOM 里摘掉、把新内容渲染出来，地址栏的变化由前端路由接管。用户感觉在逛多个页面，物理上始终停在同一个文档里。
AI 生成的单页应用，三个特征往往同时存在
单一文档：整站只有一份 index.html，视图切换不产生新文档，服务器端并不知道这些“页面”存在。
前端路由：地址栏的变化由 JS 处理，默认生成的往往是哈希路由，链接刷新后能不能打开全看运气。
数据异步：哪怕是静态的展示内容，也习惯性写成先加载骨架、再填数据，初始 HTML 里一行正文都没有。
这三个特征是 AI 的高频默认组合：框架模板自带 SPA 模式，路由声明式注册，数据请求挂在组件生命周期里。开发体验无可挑剔，但对百度来说，站点的“页面数量”从生成那一刻起就少了一大截：六个视图共享一个文档，一条 URL 承担全站信息的收录，相当于六个柜台只开一个窗口。
二、同一份文档，两个世界
1用户看到的完整，蜘蛛看到的空旷
用户打开时
脚本加载完，界面完整弹出：导航、列表、详情都在，点一下切换视图，动画顺滑，像在使用一个装在浏览器里的应用。用户不会意识到地址栏从未真正加载过第二个文档。
蜘蛛打开时
拿到的是一份还没执行脚本的基础文档：正文区域是空的占位容器，导航项是绑定事件的按钮而不是可抓取链接。它把首页记下来，没有别的路可走，转身离开。
差距的根源在于蜘蛛的两个习惯：它不点击按钮，只跟随 HTML 里真实的链接；它也不等待异步数据，页面打开瞬间是什么内容，它看到的就是什么内容。视图里写了八百字的产品说明和三处导航，它一个字、一条路都拿不到。这就是单页应用收录问题的第一层：不是内容不足，是内容从未交到它手上。
第二层问题更隐蔽：就算内容问题解决了，视图和地址的关系还错着位。用户切换到的每个视图，在蜘蛛眼里可能都属于同一个地址，收录时没有地方安放，索引里自然只剩一条记录。
三、视图要有自己的地址
2三种路由形态，三种命运
前端路由大概分三种形态，单页应用生成时用的是哪一种，直接决定了视图能不能被独立收录。把它们的差异摆在一起看，选择就清楚了。
| 路由形态 | 地址表现 | 对百度的友好度 |
|---|---|---|
| 哈希路由 | 地址带 # 号，如 /app#/about，切换时页面不刷新 | 蜘蛛通常把 # 前后视为同一个文档，后面的视图不单独收录，做再多也只有一个地址 |
| History 路由 | 地址是常规路径，如 /about，但服务器要把子路径统一重写回同一文档 | 地址干净、可被别人引用；重写没配好的话用户直接访问就是 404，内容问题也依然存在 |
| 每视图独立文档 | 每个视图对应一个真实存在的 HTML 文件，如 /about/index.html | 地址、内容、标题各自独立，收录条件天然成立，是三种形态里最稳的一种 |
对照下来，方向已经清楚：把每个需要被搜索和引用的视图，落到一份真实存在的独立文档上。这不是推翻单页应用的体验，而是给它配上一套蜘蛛能读懂的“分身”：用户依然在享受丝滑切换，蜘蛛拿到的是一份份有地址、有内容的页面。
另外还有个小细节容易被忽略：History 路由的项目在服务器没配重写时，用户刷新子路径页面会直接报错，这既是体验事故也是收录事故。做单页应用，服务器里那几行重写规则应该和前端路由一起交给 AI 生成，别留在部署时手工补。
四、三条路，把视图变成可收录页面
3按投入从轻到重，挑一条走
把视图落成独立文档，行业里已经有成熟的路径。三条路的改造深度不同，适合的项目阶段也不同，不需要全部用上，选一条匹配现状的就行。
怎么选，看三个问题就够了：希望被搜索的视图有几个、站点现在有没有已经带排名的页面、能接受的改造量是多少。想被搜的视图少于五个、又不想动前端框架，第三条路往往最划算；整个产品都以搜索流量为生命线，第二条路值一次性投入。
五、四个让蜘蛛迷路的做法
4预渲染做完了，这些习惯还在漏内容
路径选对了不等于问题自动消失。几个动作在单页应用项目里太常见，每一个都会把刚修好的收录通道重新堵上，值得在交付前逐个对照。
导航写成了绑定点击事件的按钮，整站没有一个可跟随的链接，蜘蛛进门即死路；六个视图共用一份标题和描述，收录结果全是同一句话的复制品；站点地图里只提交了首页一条地址，预渲染生成的独立文档没被主动告知；关键说明文字做进了图片和背景图里，HTML 里干干净净。这四件事凑齐，等于把单页应用改回了原点。
这四条里，导航的问题权重最高：链接是蜘蛛在这个站里唯一的走法，视图再多、内容再好，入口不是一个真实链接，就等于不存在。检查方法也很直接，打开浏览器的无脚本视图或查看渲染前的源码，看看导航里有多少个 href。数字少于视图数量，就还有活要干。
六、交付前的六项检查
5把收录条件写进生成要求里
最省事的做法不是交付后补救，而是在提示词阶段就把收录条件写给 AI。这六项既是可以直接写进生成要求的验收标准，也是上线前的自查清单。
- 每个需要收录的视图对应一个独立 URL，复制到浏览器直接访问能正常打开
- 每份独立文档有自己的标题和描述，不是全站共用一份
- 导航里的每一项在源码中是真实链接，不依赖点击事件也能被跟随
- 首屏正文在初始 HTML 里就存在，骨架屏只用于交互后的加载过程
- 站点地图列出全部独立视图的地址，新视图发布时同步更新并推送
- 视图之间按主题互相链接，让蜘蛛从任意入口都能走到相邻内容
视图互引是很多单页应用项目最容易漏的一项：视图虽然独立成页了，彼此之间却还是孤立的，全靠导航栏连接。独立文档解决的是“能不能被收录”，视图互引解决的是“蜘蛛愿不愿意走深”，两件事一起做，收录才有稳定的样子。
七、多站部署：每个应用各自成立
做站群的人用 AI 批量生成单页应用是常见节奏：一个站一个独立的小应用或推广页，界面各不相同，批量铺开。这种场景下有一条底线要先立住：每个应用各自独立部署、独立域名，应用之间不互相挂链接。跨站链接的性质依旧是站间互链，前面文章里的结论原样适用，不要因为形态换成了“应用”就重新试一遍。
批量部署时，收录环节的配置可以借助 UC 建站系统统一解决：每个站点独立部署、互不关联，给蜘蛛提供的 HTML 都是直出内容而不是空壳；百度 API 加 IndexNow 双通道推送负责把每个站的新视图递进抓取队列；多站看板把各站的收录和索引变化放在同一屏里，哪个站的视图没进索引一眼就能看出来。内容中台则负责批量生产和分发各个应用的文案素材。应用之间零关联、收录配置零遗漏，是批量铺应用最舒服的状态。
把结论说透：单页应用的收录问题，本质是视图和地址没有对齐。让每个要被搜到的视图落到一份独立文档上，配上独立的标题描述、真实的导航链接和相互的引用，剩下的交给推送和时间，收录会自己长出来。
回头看开头那个场景：六个视图只躺着一个 URL，不是百度对单页应用有意见，是它只能看见你交给它的东西。AI 负责把应用做得丝滑，你负责把地址和内容交到蜘蛛手上，分工明确，两边都不耽误。
下一次生成项目时，把那份六项清单直接放进提示词里，让每个视图从出生起就带着自己的地址和内容。改动提示词的成本，永远比上线后返工低。
