这两年用 AI 写前端代码的团队越来越多，一个带页面、带路由、带数据看板的 CSR 应用，从需求到上线被压缩到几天甚至半天。上线那天打开浏览器一切正常：页面漂亮、交互顺滑、手机上也没问题。真正的意外发生在一两周之后：搜索一下自己应用的标题，前几页根本找不到它，站内页面一条都没被收录。
问题不在 AI 写的代码质量，也不在内容不够多，而在 CSR 这种渲染方式本身：它交付给浏览器的第一份文件里只有空壳，内容要靠 JavaScript 跑起来才出现。搜索引擎拿到这份空壳时，看到的东西和用户看到的完全是两回事。把渲染方式处理好，这个坑是可以在开发阶段就填掉的。
一、先把概念理清：CSR 应用到底指什么
CSR 这个缩写在不同圈子里指两样完全不同的东西，看到“CSR 应用”这几个字时先对一下语境，能省掉大量沟通成本。做前端和 SEO 的人说的 CSR，是 Client-Side Rendering，客户端渲染；做企业传播的人说的 CSR，是企业社会责任。本文讨论的是前者，也就是用 React、Vue 这类框架写出来、内容由浏览器端脚本渲染的应用。
CSR：客户端渲染
服务器只返回一个几乎空的 HTML 骨架和一堆 JS 文件，页面内容在浏览器里执行脚本后才生成。开发体验好，前后端分离干净，首屏之后切换页面很快。
SSR：服务端渲染
服务器把页面在后台拼好，直接返回带内容的完整 HTML，浏览器拿到就能显示，脚本再接管后续交互。对搜索引擎最友好，但要维护一套渲染服务。
SSG：构建时静态生成
在打包阶段就把每个页面提前生成好静态 HTML，部署到服务器或 CDN 上直接发。内容更新频率不高的站点很适合，页面天然对爬虫可见。
预渲染：把 CSR 补成静态
代码仍然是 CSR 的写法，只是在构建或部署环节用工具把页面先跑一遍，把渲染结果存成静态 HTML。改造量小，是很多 AI 生成项目的折中路线。
用 AI 制作应用时，默认产出的十有八九是 CSR 结构：脚手架一拉、组件一写、路由一挂，跑起来就是一个完整的客户端渲染应用。这套流程对开发者友好，AI 也最擅长，但它默认不考虑“搜索引擎看到什么”，收录问题从代码生成的那一刻就已经埋下了。
还有一种常见的误会是把客户端渲染和“不能做 SEO”直接画等号。事实是 CSR 应用完全可以做好收录，只是需要额外做一层处理，把内容以 HTML 形式递给爬虫。知道有这个环节，和不知道，是两种完全不同的结果。
二、爬虫打开 CSR 应用时，看到的是个空房间
一个打包后的客户端渲染应用，主页面的源文件其实长这样：
<!DOCTYPE html><html lang=“zh-CN”><head><meta charset=“UTF-8” /><title>企业官网</title></head><body><div id=“app”></div><script src=“/assets/index-8f3a2c.js”></script></body></html>用户在浏览器里看到的图文、导航、产品列表，全部由那个 JS 文件在本地执行后生成。搜索引擎的爬虫抓取页面时，拿到的是这个只有 <div id=“app”></div> 的空壳：没有正文、没有一个内链、没有可读的内容结构。有些爬虫会尝试执行页面里的脚本，把渲染后的结果再取一次，但这一步并不总是发生，执行深度和等待时间也受资源调度影响，属于“可能拿到，也可能拿不到”的状态。
这就解释了一个常见现象：CSR 应用里的内容明明比同类静态站更丰富，收录却慢一大截。收录的前提是“看懂页面讲了什么”，空壳页面在这一步就没东西可看，后面的一切优化都无从谈起。
判断自己的应用是不是纯 CSR，有一个直观办法：打开页面后查看源代码（不是开发者工具里的 Elements，而是“查看网页源代码”）。如果看到的是一份和上面类似的空壳，那页面内容对爬虫来说就是不可见的；如果源码里直接包含正文文字，说明已经有服务端或构建期渲染在起作用。
还有一种半截子情况值得警惕：首页做了预渲染，列表页和详情页没做。爬虫进来能看到首页，点不进内容页，站点整体的抓取深度上不去，索引里只留一个孤零零的首页。处理渲染问题要按整站视角，把需要被收录的页面类型统一盘一遍。
三、AI 在这个流程里能替你干掉哪些活
把“做一个 CSR 应用”拆开看，工作量集中在六块。AI 在前五块上的完成度已经很高，第六块需要你盯着。用对了，从零到上线的周期能压到一个周末；用错了方向，AI 生成的代码会把你带进反复返工的循环。
把技术栈、页面清单、路由结构讲清楚，AI 几分钟内就能给出可运行的脚手架：目录结构、路由配置、基础布局一次到位。
首页、列表页、详情页、表单页逐页描述需求，让 AI 生成组件代码和响应式样式。改版量大的时候，这类重复劳动最适合交出去。
把接口文档丢给 AI，请求封装、状态管理、加载与错误处理能一并生成。接口联调的时间从按天算压缩到按小时算。
让 AI 给项目加上预渲染插件、生成 sitemap、补上结构化数据代码。这一步是 CSR 应用能不能被收录的分水岭，要把它单独拎出来做，别混在页面开发里。
标题、描述、正文初稿都可以由 AI 起草，人负责核对事实与合规。涉及企业数据、资质表述的部分，必须以真实信息为准，AI 只做结构整理和语言润色。
构建命令、环境变量、部署流程能让 AI 写，但发布前的验收和上线后的观察必须人工把关：预渲染产物对不对、收录有没有起来，机器不会替你盯着结果。
有一类活不要交给 AI 独自决定：渲染策略和信息架构。前者决定收录和性能的下限，后者决定用户能不能顺利找到需要的东西，这两件事需要结合业务目标判断，AI 给出的默认答案（通常是纯 CSR）恰恰是收录表现最差的那一种。
换个角度说，AI 把“写代码”的门槛降到了几乎为零，剩下的门槛都集中在判断上：判断哪些页面必须被收录、判断用哪种渲染方式、判断上线后该验证什么。这部分判断力，才是用 AI 做应用时真正拉开差距的地方。
四、三条渲染路线，按用途对号入座
不是所有 CSR 应用都需要改渲染方式。先按用途分个类，需要搜索流量的走渲染增强路线，纯内部工具或登录后使用的应用，保持纯 CSR 反而更省事。
| 渲染路线 | 页面上线后是什么样 | 收录表现 | 适合的场景 |
|---|---|---|---|
| 纯 CSR | 源码为 HTML 空壳，内容全靠浏览器执行脚本生成 | 不稳定，取决于爬虫是否执行脚本，易出现收录延迟或只有首页被索引 | 后台系统、登录后使用的工具、不依赖自然搜索流量的应用 |
| CSR 加预渲染 | 构建时把页面先渲染成静态 HTML，浏览器端脚本再接管交互 | 接近静态站点，正文与内链对爬虫可见，是性价比最高的一档 | 企业站、展示型应用、内容更新频率不高的站点 |
| SSR 或 SSG | 服务器或构建阶段直接输出完整 HTML，交互逻辑照常挂载 | 最稳定，页面可见性与静态站无差别 | 页面数量大、内容频繁更新、对收录稳定性要求高的项目 |
三条路线的选择逻辑可以简化成一句话：需要被搜索到的页面，就让它以 HTML 形式存在。预渲染和 SSR 解决的正是这一点，区别只是“在什么时间点把 HTML 生成出来”。前者在构建阶段批量生成，后者在每次请求时实时生成。
对用 AI 起步的项目，预渲染通常是改造量最小的方案：代码结构不动，只增加一段构建配置和页面路径清单。已有文章、产品页这类内容页面会直接被渲染成静态文件，登录、表单这类交互页面保持原样。上线前把渲染产物里的页面逐一打开，确认正文、标题、内链都在，这个动作花不了半小时，价值却贯穿整个项目的生命周期。
五、从需求到上线，四步把应用做出来
把前面所有判断收进一条流水线，用 AI 做 CSR 应用这件事就有了稳定的节奏。四步的顺序对应“想清楚、写出来、补收录、验上线”，每一步都有明确的交付物。
先写下应用里所有页面，逐页标注“要不要被搜索到”。这份清单决定了后面哪些页面需要预渲染，是整条流程里唯一不能压缩的一步。
按页面清单给 AI 下指令：技术栈、路由结构、每页的功能与数据来源。分批生成、分批验收，比一次性要一个完整应用更可控。
装预渲染插件、配置需要生成的页面路径、生成 sitemap、给关键页面补结构化数据。这一步单独做、单独验，别和业务开发混在一起。
部署后逐个检查渲染产物的源码、提交 sitemap、持续观察收录与页面表现。发现问题回到第三步调整配置，不要动业务代码。
流程里最容易省略、代价又最大的是开头那一步。页面清单决定了预渲染的路径配置，也决定了上线后该拿什么标准验收。清单没列全，发布出去的详情页就还是空壳，等收录出问题再回头排查，成本要翻好几倍。
生成阶段和 AI 配合有个实用技巧：把“页面清单 + 每页的数据结构”整理成一份需求描述再开工，比边聊边写效率高得多。AI 生成的代码风格又高度一致，后续接手维护的人（哪怕是三个月后的你自己）也能快速看懂。
六、上线当天要做的六个验证
渲染配置做完不等于生效，部署上线也不等于被收录。在应用上线当天把这几项过一遍，出问题的当场就能回退修改，不用等到几周后从搜索表现里反推原因。
- 查看网页源代码：正文、导航、标题文字要真实出现在 HTML 里，而不是只在开发者工具里可见
- 页面标题与描述：每个需要收录的页面输出独立的 title 和 meta description，禁止全站共用一条
- 内链形态：链接要输出成标准的 a 标签，JS 跳转的“假链接”爬虫跟不进去，页面之间的通路会断
- sitemap 完整性：用工具核对文件里是否覆盖了全部要收录的页面，遗漏的页面补进构建配置
- 结构化数据：用 *** 校验工具跑一遍，语法错误会让标记整体失效
- 移动端与速度：用真实手机网络打开一遍，预渲染产物增加的首屏体积是否可接受
提交 sitemap 和主动推送只是把门敲开，什么时候被处理、处理到什么程度，取决于页面质量、站点历史和抓取资源等多项因素，没有任何方式能一键保证收录。把验证工作做在前面，剩下的交给时间，定期回来看数据即可。
六项验证里，第一项和第三项最容易被跳过一次就永远跳过。源码检查靠的是习惯，内链形态则要回到开发阶段去改：预渲染能把正文写进 HTML，但不会把 JS 跳转自动改成 a 标签，这类细节要在生成页面的时候就给 AI 交代清楚。
上线之后的观察节奏也要定下来：前两周看抓取和收录是否正常起步，两个月内关注页面的索引状态变化。同样是预渲染，用户交互顺畅、停留时间长、内容结构清晰的页面，后续表现会更稳，这些都是可以在迭代里继续打磨的部分。
七、手里不止一个应用时，把渲染策略变成统一动作
一个人用 AI 做应用，做着做着往往就不止一个：给不同业务线做展示站、给不同地区做落地页、给几条产品线各做一套门户。到了这个阶段，逐个文件地去调渲染配置就变成了负担，更合理的做法是把“收录友好”变成默认能力，新应用直接复用。
训练一套自己的提示词模板是起点：把页面清单格式、预渲染配置要求、源码验收标准写进模板，AI 每次生成项目都按这个标准来。这份模板本质上就是团队的技术规范，放在项目仓库里，谁来维护都不会走样。用 UC 建站系统承载这类站点是另一条更彻底的路线：页面以 HTML 直出，收录友好的前提天然成立，不需要为每个新站单独配置预渲染；内容中台把策略交给人的同时由 AI 完成差异化重组，一套后台支撑多个站点；多站看板把索引量、排名、流量放在同一处，哪个站点的曲线出现异常波动，不用逐个后台翻也能及时发现。应用多了以后，管理成本反而要靠集中来降，而不是靠加人。
回到技术本身，多应用场景的核心是把渲染策略和验收标准从“每次现场决定”变成“启动就默认执行”。预渲染路径配置做成模板，验证清单写进发布流程，新应用上线时不需要再问“这次要不要做收录优化”，因为默认答案就是做。
“AI 决定你做得有多快，渲染方式决定你被看到多少次。”
用 AI 制作一个 CSR 应用，技术上已经没有任何门槛，真正需要提前想清楚的是它要不要被搜索到。要，就在开发阶段把预渲染和收录配置当成必选项；不要，就安心享受客户端渲染带来的开发效率。最糟糕的情况从来不是选错路线，而是从没意识到这是一道选择题。
把这个判断放在项目启动的第一天，比上线后花三个月补救划算得多。应用的代码可以让 AI 生成无数次，但搜索表现需要时间慢慢积累，而起点就是那份源码里有没有正文。
