从文档到网站:把 20 篇文档变成 20 个页面,目录结构怎么设计?

一句话结论

文档变页面，不是把每篇文档套个模板，而是先设计一张「问题地图」，再让文档去填格。目录错了，页面做得再漂亮也只是把混乱搬到了公网。

这篇讲方法，也讲落点：在 2Ryun 里，它是「文档树入库 → 保存即提取 → 一键建站 / 一行脚本挂客服」这一条链。文末按你实际会点的顺序走了一遍。

先看一个常见的失败

一家做工业设备的公司，把产品手册拆成 20 篇文档，一键生成网站。上线后三个月，自然流量几乎为零，客户还是打电话问。

问题出在哪？打开站点地图就明白了：

/index /docs/1 /docs/2 /docs/3 ... /docs/20

页面上线了，但没有一个页面的地址、标题、结构，对应一个真实的人会问的问题。

搜索引擎看不懂 /docs/7 是什么；AI 引擎抓下来一堆没有主题的页面；客户搜「XX 型号密封圈更换周期」，落不到任何一页。

这就是本文要解决的问题：从文档到页面的那一步，真正的工作是信息架构，不是排版。

✦ ✦ ✦

一个必须先接受的前提：页面是「被评估的最小单位」

2026 年 10 月，Sierra 与 Meta 发布的 Personal Agent Protocol 里有一条机制值得注意：企业在网站上放一个标准文件（/.well-known/poppy.json），外部 Agent 就能知道「这家公司提供什么、该怎么接入」［R06］。

这条机制的前提是：你得先有一个结构清楚的站点。一个 /docs/7 这样的地址，Agent 读不出主题，人也记不住。

腾讯在 2026 年 10 月开放元宝搜索时，披露了它的入库评估方式：

「内容入库前，大模型会解析网页并保留标题、表格等结构，从站点、账号、页面三个层面评估质量，优先选择权威来源，过滤低质内容。」［R12］

这句话值得逐字读。它说的是三层：

• 站点
  这个域名背后是不是一个明确的主体？
• 账号
  这个主体有没有持续、可核验的身份？
• 页面
  这一页本身有没有清晰的主题和结构？

三层的顺序很重要——站点和账号先过关，页面才有被评估的资格。

所以「把文档变成页面」这件事，从来不是单页优化。你在做的是一个站点层面的结构：谁是这个站的主体、这些页面之间是什么关系、每一页负责回答哪个问题。

这也解释了为什么「一键生成 500 个页面」通常没用：它生成的是 500 个孤立的页面，不是一个站点。

✦ ✦ ✦

第一步：把 20 篇文档重新「按问题」分簇

先别管文档原来叫什么名字。把 20 篇摊开，每篇用一句话写出「它回答什么问题」。

一家设备公司的真实结果大概是这样：

20 篇，20 个问题。接下来做一件事：把它们按「用户旅程」重排，而不是按「资料类型」。

认知（我为什么要看）  └ 这台机器能解决什么 → 案例 → 选型理解（它到底是什么）  └ 型号/参数 → 技术原理 → 接口/兼容决策（买不买、怎么买）  └ 资质/检测 → 交付流程 → 报价说明 → 保修使用（买了之后）  └ 安装 → 调试 → 操作培训 → 维保 → 故障码 → 备件

这个重排会带来一个直接后果：原来并列的 20 篇，变成了 4 个层级和 20 个位置。有些位置是空的（比如「技术原理」你没写），有些文档要拆（产品手册太厚，得拆成型号页 + 参数页）。

空位就是内容计划的起点。

第二步：定层级——三层，别更深

信息架构里有个老经验叫「三次点击」，但它不是定律，只是经验。真正可靠的原则是：层级深度要匹配问题的抽象程度。

我的建议是最多三层：

一级：/products/                    产品总览（列表页）二级：/products/seal-series/        系列页（某系列是什么）三级：/products/seal-series/spec/   具体页（参数/安装/故障）

超过三层的代价：

• 每多一层，导航面包屑就多一段，用户更容易迷路；
• 每多一层，页面之间的内部链接就更难做全；
• 每多一层，AI 抓取时的「主题归属」就更模糊——它不知道这一页属于哪个主题簇。

一个实用的判断法：如果某个页面需要第四层才能放，通常说明它应该被合并，或者它其实属于另一个主题簇。

第三步：定 URL——地址是给机器看的目录

URL 不是装饰。它是机器理解「这一页在站点里的位置」的第一信号。

四条规则：

1. 用语义，不用编号
   /products/seal-series/spec/ 而不是 /docs/7。
2. 层级与目录一致
   URL 的路径深度，应该等于页面的层级深度。
3. 稳定不变
   页面一旦有了外部引用，就不要改地址。要改必须做 301。
4. 一个语言一个前缀
   中文 /zh/、英文 /en/，不要靠参数区分。

一份可用的站点地图（Site Map）应该长这样：

这张表就是交付物。没有这张表就生成网站，等于没有图纸就砌墙。

✦ ✦ ✦

第四步：一页一意图，别做「万能页」

最常见的错误是把「产品手册」整本做成一页。结果这一页同时想回答选型、参数、安装、故障、保修五个问题，每个都答一半。

规则：一个页面只服务一个搜索意图。

怎么判断两个内容该不该合并？用「如果用户只想要 A，会不会被 B 干扰」来测。

• 「参数」和「安装」应该分开：查参数的人在做选型，查安装的人已经买了。
• 「保修」和「售后流程」可以合并：它们是同一个决策场景（出问题了怎么办）。
• 「型号对照」和「选型建议」应该合并：一个是事实，一个是判断，但用户是连着问的。

拆得太碎也有代价：20 篇变 80 页，每页只有 200 字，会被判定为低质。经验值是每页至少能独立回答一个问题、有 500 字以上的实质内容。

第五步：定模板——三种页面，三套结构

不要给 20 个页面各设计一次。归成三类，每类一套模板：

2Ryun 的站点构建会给子页面自动生成索引与分页（每页 1–60 条可调，默认 10），静态包会切成 page/N/index.html。

「结论在前」这条最重要——AI 抓取时，第一段往往是它判断「这页讲什么」的依据。

转化页最容易被做成「营销页」，然后失去信息价值。建议至少保留一段实质内容（比如「适合/不适合」的判断），否则它只是一个表单。

第六步：把导航做成「三条路」

用户到任意一页，都应该有三条路可走：

1. 向上
   面包屑（我在站点的哪个位置）
2. 横向
   相关页面（同一簇里的兄弟页）
3. 向下
   这一页引出的更具体问题

第三条最容易被忽略，也最值钱。比如「故障处理」页，应该链到「备件清单」（可能要换件）和「售后流程」（可能要报修）。这些链接不是给人看的装饰，是给爬虫看的主题关系。

2Ryun 的站建设计系统支持 NAV / FOOTER / HEADER / SIDEBAR 占位符与全局 CSS/JS，改一次导航，全站跟着变；设计有 10 个快照可回退。这套机制的意义就是：结构是一处定义的，不是 20 页各写一遍。

✦ ✦ ✦

第七步：上线前跑四个检查

再加一条技术检查：每页是否有独立的标题、描述、canonical。2Ryun 的发布流程会做逐页 head 审计并补齐 canonical / og:url / description / Organization，同时为每页生成 Markdown 版本（地址后加 .md），并在 head 里声明 rel="alternate" type="text/markdown"。

后面这条不是小事：当 AI 引擎来抓取时，给它一份干净的 Markdown，比让它从 HTML 里剥导航栏要友好得多。

常见坑

坑一：按原文档结构直接生成

文档是给「读完整本」的人写的，页面是给「带着一个问题」的人看的。这两套结构天然不同。

坑二：列表页只放标题

列表页是主题簇的入口，需要一句簇定义。没有定义的列表页，在机器看来只是一堆链接。

坑三：一个文档树建多个站

2Ryun 的约束是「一个文档树只能建一个站」。想建中英文两个站，就要两棵树——这不是限制，是逼你先把内容边界想清楚。

坑四：上线后不敢改结构

结构可以改，但改 URL 必须做 301 映射。改结构不改地址，等于留下 20 个死链。

用 2Ryun 把 20 篇变成 20 页

目录设计是脑力活，建站是体力活。产品里，体力活这部分基本被省掉了：

1. 先分簇，再建站。
   在文档树里按「问题」分一级目录（不超过 6 个），一层层往下放。这棵树就是站点的信息架构——建站之后再改目录，等于改站。
2. 整棵树建站。
   选中这个文档树构建站点，一个树只能建一个站。这就是为什么第 1 步不能省。
3. 选模板，定设计系统。
   78 套预设模板挑一套，或导入自己的模板与样式；NAV / FOOTER / HEADER / SIDEBAR、CSS 变量、全局 CSS/JS 都能改，保留 10 个设计快照可回退，首页设计可一键同步子页。
4. 列表页自动索引。
   子页面自动进索引并分页（1–60，默认 10），新增文档不用手工加链接。
5. 把导航做成「三条路」。
   用占位符 + 自定义插槽，把导航分成「我要开始 / 我遇到问题 / 我要集成」三条，而不是照抄目录。
6. 增量发布。
   按「页面指纹 + 设计指纹」只重发变更页；改一页不用全站重发，这是长期维护成本的关键。
7. 绑域名。
   先发在 /s/{site_id} 上验收，再绑自己的域名——分享卡、canonical、sitemap 会跟着换。

边界：一页只讲一件事，这不是排版建议，是收录规则。万能页（「产品介绍」里塞价格、案例、FAQ、招聘）在任何引擎里都很难被单独引用。

✦ ✦ ✦

FAQ

Q1：20 篇文档，最后应该变成多少页？

通常是 20–40 页。拆分来自「一页一意图」，合并来自「同一决策场景」。落到 60 页以上，多半是拆过头了。

Q2：文档里有表格，生成页面会丢格式吗？

取决于源文档结构。有表头、有明确行列关系的表格能保留；用空格或图片排的表格会丢。入库前把表格转成标准 Markdown 表格，是最省事的前置动作。

Q3：能不能先上线再优化结构？

能，但代价是地址会变。建议第一次就把 URL 定对——地址是最贵的沉没成本，改一次要重做 301、重提收录、重建外部引用。

Q4：列表页需要写内容吗？

需要。至少一段 100–200 字的簇定义，说清「这一簇解决什么问题、适合谁」。这段文字是列表页被引用的主要素材。

Q5：怎么知道结构对不对？

看两个信号：搜索进来的落地页是否分散在多个页面（说明结构被理解了），以及客服收到的「你们网站上没有」这类反馈是否下降。

从今天开始：先做 5 页

20 页是目标，5 页是起点。先验证结构对不对，再批量生产。

这篇用到的是 2Ryun 的文档树分簇、78 套模板、列表页自动索引与分页、按页面指纹增量发布——在同一个账号里就能跑通。

中文站 2ryun.wiki｜英文站 2ryun.com，注册即可免费使用。

第一步：选 5 篇最该被搜到的文档，按「问题」建 3 个一级目录；

第二步：建站、挑模板，把这 5 页发到 /s/{site_id} 上，自己点一遍导航；

第三步（可选）：把地址加 .md 打开看——如果那一页讲散了，这里会立刻暴露。

目录错了，20 页会错 20 次。先用 5 页把目录验对。

注册 2Ryun，免费开始建站

引用来源

1. ［R12］腾讯新闻《元宝搜索，正式开放》，2026-10-20：new.qq.com/rain/a/20261020A09GT300
2. ［R06］Sierra《Introducing Personal Agent Protocol》，2026-10-06：sierra.ai/blog/introducing-personal-agent-protocol；规范草案（/.well-known/poppy.json 机制）：sierra.ai/blog/poppy