AI 建站工具究竟应该生成什么

生成一个页面很容易。向任何模型要一个落地页，你都能得到：一个标题，三栏功能介绍，一个行动号召。截图里看起来不错。

生成一个网站则是另一回事，而这才是小商家真正面对的问题。面包店不需要一个页面。它需要一个能让人找到营业时间的地方，一份与柜台上实物相符的菜单，一个能送达有人查看的收件箱的表单，以及足够的结构，让搜索引擎能弄清这家店是做什么的、在哪里。

下面是我们对自己的要求清单，以及每一项真正的意义。

多个页面，彼此相连

一个页面无法为多个主题排名。如果面包店既想被"酸面包"搜到，也想被"婚礼蛋糕"搜到，那就是两个页面，各有两个标题、两段描述和两个首个标题，而且它们必须相互链接，因为没有任何链接指向的页面，也就没有任何东西能找到它。

这意味着生成器必须在写下第一个字之前先决定结构：有哪些页面，每个页面是做什么的，以及访客如何用两三次点击从首页到达任何一个页面。分类页面，比如服务页下面每项服务各有一页，是大多数手艺人和诊所想要的形态，也是一串平铺的区块无法表达的形态。

一个 h1，其下是完整的层级

每个页面恰好有一个 h1，其下的标题逐级下降，不跳级。这听上去像吹毛求疵，直到你发现它防止的问题：第一个区块碰巧不是首屏的页面，很容易最终完全没有 h1，而常规审查发现不了，因为页面看起来依然正常。

我们的检查方式是渲染每种区块的每个变体并断言其大纲，而不是读代码然后相信它。

给机器读的那一半

人能读、爬虫不能读的网站，只是半个网站。以下内容随页面一起生成，绝不事后补加：

• sitemap.xml，只列出公开的页面，不含仅限会员的页面。
• robots.txt 表达同样的内容，所以两个文件不会互相矛盾。
• 每个页面一个规范 URL，来自网站真实的域名，而不是恰好响应的主机。
• 描述商家的 ld+json：它是什么、在哪里、何时营业、卖什么。
• 访客看得见的面包屑，与结构化数据中的 BreadcrumbList 一致。描述页面上根本不存在的导航的标记，正是 Google 指南所警告的事。

"这些内容都来自渲染页面所用的同一份网站定义。没有第二个会产生偏差的数据源。

人们真正会输入的词

这是任何工程都无法提供的部分。写着"首页：欢迎"的标题，会在网站出现的每个搜索结果里浪费一行。罗列关键词的描述，则浪费一句话。

所以我们会把任务的形态详细告诉生成器：标题五十到六十个字符，开头写明商家做什么以及在哪个城市；描述一百五十到一百六十个字符，结尾给出一个点击的理由；每个页面只负责一个主题，因为两个页面瞄准同一个词会互相竞争，结果两败俱伤。

不靠 JavaScript 也能用

这里生成的网站都是服务端渲染，没有客户端路由。这是一个不时髦的选择，也是一个简单的选择：它让页面在信号差的手机上依然很快，让每个页面都可以被爬取，也让脚本加载失败时表单仍然能提交。

交互部分，比如菜单、图库和地图，是渐进增强的。它们改进的是一个本来就能用的页面。

也让智能体读得懂

越来越多的访客并不是人。我们生成的每个网站的每个页面都提供 markdown 版本：在路径后加上 .md，或发送 Accept: text/markdown。每个网站都会发布列出其公开页面的 llms.txt，其 robots.txt 会明确点名 AI 爬虫，而不是让它们从通配符里猜。

对于希望在有人问模型"在克拉科夫哪里能买到酸面包"时被推荐的商家，可被读懂就是全部的关键。

这里面不包括什么

没有编造的事实。没有评价，没有注册号，没有奖项，没有店主从未给过我们的价格，也没有并不存在的团队照片。生成的网站是真实商家对外形象的草稿，上面一条听起来可信的编造，比一个空白区块更糟。

这个约束偶尔会让我们失去一个看起来很惊艳的演示。但这算不上艰难的取舍。