# 8000个页面的网站应该怎么设计？

URL: https://caijiao.org/posts/163
Source: docs/posts/163.md
Description: 8000 页的设计难点不在数量，在数据结构：Omni Calculator 把计算器抽象成配置、页面由模板生成，才撑得住 1429 万月访问和 30 多种语言。

先给结论：8000 这个数字本身不是设计难点，几千个静态文件谁都能生成。难点在于这 8000 个页面是否共用同一套数据结构。共用了，加一千页是改一次配置；没共用，加一千页是加一千份维护债。

## URL 层级要在写第一行业务代码之前定死

程序化站点里，URL 是唯一的稳定契约。上线三个月后你想改目录结构，代价是几千条重定向，而且每一条都会损失一点信号。

比较稳的层级是两层：`/类别/具体对象`，例如 `/finance/salary-to-hourly`、`/other/test-grade`。类别控制在十几个以内，具体对象可以无限扩张。别把参数塞进路径里做三级、四级——`/finance/salary/hourly/2026/us` 这种 URL 看着精确，实际上把本该属于页面的内容搬进了路径，一旦组合爆炸，清理无从下手。

有个例外值得单独说：地域和年份这类维度，只有当它们确实改变页面实质内容时才进路径。换算系数每年变、税法每年变，年份进路径合理；只是把页面上某个默认值换一下的，不进。

查询参数（? 后面的部分）留给真正的用户输入，不参与页面区分。这条划清楚了，后面 canonical 才知道该指向谁。

## 页面数据放构建期的 SQLite，还是运行时查库

八千页的规模，我倾向构建期全量预渲染。理由不是性能，是可验证性：构建产物是静态文件，能直接看、能 diff、能被 [nginx](/nginx/) 当纯静态资源服务，部署就是打一个镜像把 dist 目录扔进去，回滚是换一个镜像标签。

页面元数据——标题、描述、示例输入输出、所属类别、相关条目——在建站初期就放进 [SQLite](/sqlite/) 的一张表里。八千行对一个文件数据库来说毫无压力，好处是生成脚本、查重脚本、结构化数据生成脚本读的都是同一份数据，不会出现标题改了而 JSON-LD 没改的情况。

运行时查库只在一个场景下值得：页面内容依赖频繁变化的外部数据，且你需要 Google 每次抓取都看到最新值。多数工具站不需要这个，一天构建一次足够。

八千页全量构建的时间也要提前算。纯静态生成、每页 20 毫秒的模板渲染，八千页不到三分钟，完全够用；如果单页渲染要 200 毫秒，全量就是半小时，那就必须做增量构建——按类别分片，只重建变更的那一片。这个分片的边界最好和 sitemap 的分片边界一致，省得维护两套划分。

## 把"计算器"抽象成配置，页面只是配置的渲染结果

Omni Calculator 的做法值得抄：它不写几百个计算器，它写一套计算器引擎，每个具体计算器只是一份配置——输入字段有哪些、公式是什么、单位怎么换算、输出怎么格式化。页面由模板 + 配置生成，2026 年 6 月的估算访问量约 1429 万，覆盖 30 多种语言。

![Omni Calculator 计算器分类页截图](/images/2026-09/omnicalculator.com.png)

*Omni Calculator 首页的 Physics 分类挂着 546 个计算器，是 Chemistry 108 个的五倍。*

这套抽象的好处是可以横向加维度。加一种语言，是一次配置遍历，不是翻译 8000 个页面。加一个类别，是填一张表。

抽象层要留在两类边界上：一类是"计算逻辑"，纯函数，可测试；另一类是"页面呈现"，模板，可替换。这两类混在一起的站点，往往在第二年就没法加功能了。

配置里还要预留几个看似多余、后面一定会用到的字段：示例输入值、示例输出值、常见误解说明、相关条目 ID。这四个字段不是为了当下，是为了让页面在生成时就自带"内容"——程序化页面最怕的是整页只有一个输入框，那和空页面没什么区别。

配置本身建议存成结构化文件而不是代码里的对象字面量。存成文件才能被查重脚本读取、被非开发者修改、被版本控制清晰地 diff 出"这一版改了哪些页面的哪个字段"。

## 八千页的 sitemap 必须分片，分片边界要对应目录

单文件 sitemap 上限是 5 万条 URL、50MB 未压缩，八千页其实没到上限。但分片仍然值得做，理由是诊断效率：`sitemap-finance.xml` 收录率 98%、`sitemap-other.xml` 收录率 41%，问题定位直接到类别；全塞在一个文件里，你只能看到一个总数在涨或跌。

分片之后在 robots.txt 里声明索引文件位置，并在 Search Console 里逐个提交。这一套流程的细节在 [Google Search Central 的 sitemap 与 robots 部分](/google-search-central/04-sitemaps-robots)有完整说明。

## 上线节奏：按批灰度，不要一次全放

八千页一次性提交，你会同时失去两个观察窗口：看不出哪一类页面被忽略，也看不出索引速度是否正常。

按类别分五到六批，每批隔一到两周提交，每批提交后在 Search Console 里看已收录比例和"已抓取未索引"的数量。某一批的未索引比例明显高于前一批，说明这一批的模板有问题——通常是正文太薄或者和已有页面重复，这时停下来修模板，比继续铺量划算得多。

八千页从来不是一次做完的。Omni 那个体量也不是一天长出来的，它是把引擎打磨到"加一个计算器只需要填配置"之后，才谈得上规模的。先把前 200 页做到收录率 90% 以上，再去谈后面的 7800 页。这 200 页还有个额外作用：它们是模板的验证集，模板改一版，先看这 200 页的数据有没有掉。

---

*Omni Calculator 访问量来自 Semrush 2026 年 6 月估算，其"计算器抽象为配置、页面由模板生成"的模式来自团队公开分享。*