---
title: AI 建站工具究竟应该生成什么
description: 大多数 AI 建站工具只生成一个页面，而商家需要的是网站：相互链接的页面、一个 h1、sitemap、结构化数据和能发邮件的表单。这是我们的清单。
date: 2026-09-11
author: crea.site
tags: [product, seo]
---

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

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

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

## 多个页面，彼此相连

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

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

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

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

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

## 给机器读的那一半

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

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

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

## 人们真正会输入的词

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

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

## 不靠 JavaScript 也能用

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

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

## 也让智能体读得懂

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

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

## 这里面不包括什么

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

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