最近一年，用 AI 工具做页面的人明显多了。企业客户自己拖一个后台就能生成落地页，做站的朋友拿对话式工具批量出模板，前几天还有个同行说，他半天时间生成了十二个行业站首页的初稿。切图和写样式这块确实被省下来了，这一点没什么好争的。
但热闹过后，问题开始集中冒出来：同样用 AI 生成的页面，有的上线几天就被抓取收录，有的挂了一个季度没有任何动静。把两边的源码拉出来一对比，差别不在设计好不好看，也不在内容写得怎么样，而在交付出来的东西到底是什么形态。
同样是 AI 生成的页面
源码拉出来，正文一行都没有。HTML 里只有一个空的挂载节点和一大堆 JavaScript 文件，文字、链接、标题全靠浏览器执行脚本之后才会出现。看起来一切正常，搜索引擎看到的是空页面。
换了交付方式的同款页面
设计风格差不多，但源码里标题、正文、内链都是实实在在的 HTML 标签。浏览器和爬虫拿到的是同一份内容，抓取诊断一次通过，不用额外做任何适配。
一、这类工具先分成四类，各自的交付物不一样
市面上做网页的 AI 工具数量很多，但按工作方式分，其实就四类。为什么强调"交付物"这三个字？因为工具本身不决定页面能不能收录，它吐给你的文件形态才决定。同样是"AI 做网页"，有的交付可以直接部署的静态 HTML，有的交付一套需要构建和部署流程的 React 项目，这中间的差别比工具名字大得多。
| 工具类型 | 工作方式 | 交付物 | 适合谁 |
|---|---|---|---|
| 对话式整页生成 | 一句描述或一张截图，直接生成整页甚至整个项目 | 多数是前端框架项目，需要部署流程 | 快速出原型、验证设计方向 |
| 编辑器内 AI | 在已有项目里写组件、改页面、补逻辑 | 跟随项目技术栈，可控性最好 | 有前端基础的迭代开发 |
| 设计稿转代码 | 设计文件直接生成前端代码 | 组件代码加样式，需要接入项目 | 设计和开发衔接的团队 |
| 建站平台内置 AI | 模板加 AI 填充，整站托管在平台 | 平台托管的整站，不少是静态输出 | 非技术背景、单站快速上线 |
四类工具里，讨论最多的是对话式生成那一类。像 Vercel 推出的 v0，现在的玩法是描述需求或者丢一张截图，直接生成 React 组件和完整页面，效率确实高。但这类工具默认的输出形态是前端框架项目，页面的浏览器渲染方式跟传统静态站点差别很大，如果直接把生成结果部署上线，就很容易掉进下面要讲的那个坑里。
另外三类反而没那么多麻烦：编辑器内 AI 的输出跟随项目本身，你的项目要是静态输出的，生成的东西也是静态的；建站平台的模板站大多本身就是静态页面；设计稿转代码出来的组件，接进什么架构就按什么架构的规则跑。工具选型先要看的不是生成的界面好不好看，而是交付的是什么形态的产物。
二、能不能收录，卡点在前端渲染那一层
搜索引擎抓页面，拿到的第一份东西是服务器返回的 HTML 源码。客户端渲染的站点，这份源码里只有骨架和脚本入口，正文要靠浏览器执行 JavaScript、再发起接口请求、拿到数据之后才渲染出来。人看起来没差别，爬虫看到的第一屏却是一片空白。
实际情况比"抓到空白"更麻烦一点。爬虫确实具备一定的脚本执行能力，但对复杂异步请求的等待时间是有限的，页面里十几个组件各拉各的接口，很可能等不到内容渲染完成就结束了抓取。更进一步，用前端路由做的单页应用，页面之间的切换不产生真实的 HTML 请求，一套路由下来，搜索引擎可能只认得出一个页面地址，站内链接怎么传递、层级怎么理解都成了问题。
页面标题和描述如果也是脚本动态写入的，读取结果大概率是模板里的默认值或者干脆是空的。这两项对页面来说相当于门面，全站几百个页面标题一模一样，等于把内容结构拱手交出去了。
# 把生成好的页面地址放进去跑一次，检查正文是否在源码里curl -s "https://你的域名/页面地址" | grep -c "页面上的一段正文"# 输出 0：这段文字不在服务器返回的 HTML 里，多半是 JS 渲染的# 输出 1 或更多：内容是直接写在源码里的，抓取没有障碍手动检查也很简单：浏览器里按查看源代码，注意不是审查元素。审查元素显示的是脚本执行之后的界面结构，看见内容不代表源码里有内容，这两个入口经常把人骗过去。在源码页里搜页面正文里的一个句子，搜不到就说明交付物是 JS 壳。
解决路径有几条：让服务器端渲染直接把内容拼进 HTML 再返回；或者在构建阶段把动态页面提前生成静态快照，也就是预渲染，这类方案改动小、生成的是纯静态文件，内容更新频率不高的站用起来很合适，代价是新内容要重新触发构建才会出现在快照里；再或者干脆换回静态输出，内容变化不频繁的站点本来就没什么必要上重前端。
网站后台里的抓取诊断类工具，可以对比同一地址在不同抓取方式下的返回结果。同一页面，渲染后的内容和源码内容差距越大，说明这个站对 JS 的依赖越重，收录上要下的功夫就越多。
三、AI 生成的页面里，这几类问题几乎每页都能遇到
把 AI 生成的页面当成新手写的代码来审，这个心态比较对。工具的输出在功能上通常能跑通，界面也齐整，但细节层面的窟窿不少，而且分布很有规律，翻来覆去就是那几类。
链接指向不存在的页面
脚手架把导航和栏目都摆好了，实际生成的只有两三个页面，剩下的入口点进去全是错误页。页面数量一多，这种空链接很容易被漏掉。
标题层级混乱
一个页面里出现好几个一级标题，或者一级标题压根没有，小标题全靠加粗文字和调整字号撑着。爬虫读不出页面在讲什么主题。
组件状态不一致
不同会话里生成的按钮和卡片，悬停效果、圆角、间距各按各的来，拼在一个页面里像几个人分头做的。这类问题在批量生成时尤其明显。
可访问性与交互缺口
图片没有替代文字，表单没有 *** 和提交中的加载状态，装饰性图形和内容图片混在一起。视觉上过关，细节全靠人工补。
除了这些结构性问题，代码本身的规范性也要过一遍。AI 生成 HTML 时容易留下标签没闭合、嵌套层级错误、同页面 ID 重复、还在用旧式字符集声明之类的小毛病。单看每一处都不影响浏览，堆在一起就是质量分被磨掉的原因。
校验不用手写脚本：公开的标记校验服务可以把页面地址或者 HTML 文件直接丢进去检查，标签闭合、属性允许范围、嵌套错误这些一次报全；做工程化的团队用本地校验工具挂在提交环节，生成一批就过一批，别等全站铺开再回头筛。
实际用下来最省事的办法，是把检查项固定成一段提示词，让工具自己先过一遍再交付。下面这几条是我们每次都会带的：
- 页面内所有链接都必须指向已经生成的页面，不允许出现占位链接；
- 全页只允许一个一级标题，层级按顺序往下排，不允许跳级；
- 每张图片带替代文字，每个表单带 *** 与提交状态；
- 标题和描述按页面内容单独生成，不许全站共用一套；
- 生成结束后自查一遍标签闭合与属性规范，把问题列表先打出来。
批量生成最忌讳"生成完再统一改"。改一处样式规则，可能牵扯几百个页面的组件写法，成本比生成本身高得多。检查项要放进生成环节，宁可每次多花几分钟，也别攒起来返工。
四、接进站群批量场景，做法要换一换
一个企业站做几张页面，对话式工具加人工修改够用了，改完检查一遍就能上线。站点数量到了两位数、三位数，玩法就得换：让 AI 自由发挥生成整页，等于每个站都开盲盒，语义结构、链接规则、样式命名各行其是，后续维护的成本会失控。
批量场景下更稳的路子是"骨架固定、内容填充"：页面结构按模板来，标签层级、结构化数据的位置、内部链接规则全部预先定死，AI 只负责往内容区里写东西。这样生成出来的每个页面都天然是可抓取的静态结构，不用再逐个验证渲染方式。
<!DOCTYPE html><html lang="zh-CN"><head><meta charset="utf-8"><title>页面标题（每页单独生成）</title><meta name="description" content="页面描述（每页单独生成）"></head><body><header>站点头部与主导航</header><main><h1>页面主题</h1><article><h2>小节标题</h2><p>正文内容由 AI 填充，标签结构保持不变</p></article><section><h2>常见问题</h2><p>问答内容</p></section></main><footer>联系方式与备案信息</footer></body></html>骨架里几个不能省的地方：页面语言声明、独立的标题和描述、一个一级标题、语义化的 article 与 section、页脚的联系方式与备案信息。这几项定死在模板里之后，AI 生成的内容再多样，页面底盘都是一致的。
我们管理站群的内容时用的还是 UC 建站系统那套架构，WordPress 打底，上面加一层 AI 管理层。骨架模板、语义结构、页面输出方式这些规则统一定义在中台里，同一份主题数据分发到不同站点时，由中台按站生成不同角度和结构的内容，出来的页面看着各不相同，底盘却是同一套标准。页面全部 HTML 直出，生成即完成，不用再为收录问题做额外处理。
站点各自独立部署，独立域名独立备案，模板也可以按站调整视觉；新页面生成之后走双通道推送提交，省掉等自然抓取的周期；几十个站的索引量、抓取异常在多站看板上统一看，哪个站哪类页面出了问题一屏就能定位。对比一下手工流程：以前给五个站更新模板，改样式、重新生成、逐个验证源码，来回要一两天，现在在中台改一次规则，全站页面按新结构重新输出。
五、上线前把四道检查跑完，问题就不会拖到收录阶段
AI 生成的页面和手工写的页面一样，上线前都该过一遍基本检查。区别在于前者出问题的概率更高、分布更集中，所以检查动作值得固定成流程，每次都按顺序走，不靠记忆。
查看源代码搜一段正文，或跑一次抓取命令。内容不在源码里的，先解决渲染问题再谈其他
把页面丢进标记校验服务，标签闭合、嵌套、重复 ID 一次过；工程化项目挂本地校验
用抓取诊断类工具对比返回结果，结构化数据用公开校验入口检查字段完整性
提交推送与站点地图，几天后回查抓取记录，把没进索引的页面挑出来复盘
这四道检查的顺序别打乱。渲染方式没确认就去做内容优化，是把功夫花在了爬虫看不到的地方；标记没校验就提交推送，等于把带伤的东西送进队列。整套跑下来，单个页面的时间投入大概十几分钟，比事后排查一轮污染了索引的页面划算太多。
回查这一步值得展开说：页面没进索引的原因通常分三类，抓取就没成功的、抓到了但判定没价值的、以及抓取和收录都正常但内容重复的。AI 批量生成的页面最容易踩的是重复那一类，同一个模板换几个词就出一批页面，内容相似度太高，收了一批进去，剩下的就停在队列里不动了。复盘的时候按这三类分开看，处理思路是两码事。
检查流程的价值不在某个单项工具，而在于让"生成"和"可上线"之间有一条明确的界线。流程固定下来之后，AI 的生成量越大，这套检查反而越省事，因为问题类型是收敛的。
六、账要重新算一遍：什么省下来了，什么反而更贵
工具的宣传口径通常是"几分钟生成一个页面"，这句话本身没错，但它描述的是从描述到初稿的时间，不含后面该做的活。把整条链路的时间摊开看，结论会平和很多：生成确实变快了，检查、修正、复盘的比重明显上升，总时长省了一些，但没有省到宣传语里那个数量级。
生成一个页面初稿
十几分钟
对话式工具反复调整到能看的时间
上线前检查修正
半小时上下
结构、链接、标记、渲染方式逐项过
手工做同等页面
半天往上
含切图、写样式、调兼容的老流程
所以这类工具真正的价值在于"把一个下午的工作压到一小时内"，而不是"不需要人"。算账的时候要把三块都算上：工具订阅费、检查修正的人力、以及返工成本。前两块是明的，返工那块藏在后面，批量生成之后最容易爆发，比如统一改了样式规则、统一调整了语义结构，需要把之前生成的页面再过一遍。
返工成本的根源几乎都是规则没前置：结构规则、命名规则、检查规则如果在生成第一批页面之前就定好，后面基本不需要回头大改；反过来，先让工具自由发挥一百个页面，再想统一，工作量比重新生成还大。
还有个不太被提的隐性成本：工具订阅的叠加。对话式生成一个订阅、编辑器补全一个订阅、设计工具一个订阅、图片素材又一份，单看每项都不贵，全部叠起来是一笔固定支出。站点数量少的时候，先用两三个核心工具就够了，别为了尝鲜把订阅开满。
七、按自己的场景选，别按工具名气选
聊到工具选型，很多人第一反应是问"哪个最强"。这个问法本身就偏了，四类工具解决的是不同环节的问题，脱离使用场景比强弱没有意义。更实际的思路是：先看自己是什么身份、要做多少页面、后续谁来维护，再对号入座。
| 场景 | 建议路径 | 注意点 |
|---|---|---|
| 单个企业站，没有技术背景 | 建站平台内置 AI，模板加填充 | 确认输出是静态页面、域名归属清楚、内容能导出，别被平台绑死 |
| 单个企业站，有前端人员 | 对话式工具出原型，人工改语义结构与细节 | 生成结果先过源码检查再上线，别把原型直接当成品 |
| 站群批量做站 | 固定骨架模板加内容中台，AI 只做内容层 | 规则前置，检查嵌入生成流程，别让每个站自由发挥 |
| 已有项目日常迭代 | 编辑器内 AI 补全，跟随现有技术栈 | 不同时段生成的组件状态容易不一致，统一走同一套组件规范 |
如果只是想先试试水，也不用急着做决定，拿免费额度跑两个真实页面，把这几个环节走完：
两个页面走完整流程，工具好不好用、坑多不多、维护成本能不能接受，心里基本就有答案了。比看十篇测评文章都直接。
"工具负责把页面做出来，能决定页面命运的，是它交到搜索引擎手里的那份源码。"
回头看这一年的变化，AI 做网页这件事本身没有问题，效率提升是真的，成本下降也是真的。要防的是把"生成完成"当成"上线完成"，中间那一步检查的动作，恰恰是这两年来回踩坑换来的经验。把渲染方式、语义结构、检查流程这三样定下来，工具换哪家都不慌；定不下来，工具越顺手，后续收拾的摊子越大。
