什么情况下应该把网站从100页扩展到1000页？

有个具体的判断方式我觉得最好用：某天晚上你批量生成了 20 个新页面，一个月后回头看，其中 17 个各自都拿到了流量。

这不意味着这 20 个页面写得多好。它意味着这套模板已经被验证过了——给它新的数据，它就能复制出新的入口。这时从 100 扩到 1000 是顺势而为；在这之前扩，大概率是把还没想清楚的东西批量复制。

Omni Calculator 的答案：把计算器写成配置

Omni Calculator 的做法值得整套照抄思路，不一定照抄实现。它把一个计算器抽象成一组配置——公式、单位、文案、示例都是配置项，页面由模板生成。2026 年 6 月的第三方估算里它月访问约 1429 万，支持 30 多种语言。

Omni Calculator 首页把 3925 这个数字放进了标题——页面矩阵的规模就是它最重要的自我介绍。

这么做带来的直接结果是：页面数等于"问题数 × 语言数"。加一个语言不是翻译一个站，是让所有页面多出一整套版本；加一个新计算器也不是写一个页面，是加一份配置。

Inch Calculator 是同一个思路的窄版本：只做尺寸和工程量估算，月访问 459 万。它验证了另一件事——哪怕只有一个动词，只要能拆的输入组合足够多，也撑得起几千页。

反过来值得警惕的是 Homewyse 这种：月访问 42.885 万，做的也是严格单一的场景，但因为"报价"这个词群只有几个大而模糊的说法，能拆出来的页面数量天然有上限。这类站扩到一千页，多出来的会是硬凑的。

扩展之前，先把模板组件化

从架构上看，从 100 到 1000 不是写十倍的页面，而是把生成方式重写一次：让每一个新页面的产出都不依赖手写代码。React 做这件事最顺手——输入区、结果区、说明区、示例区各自独立，页面只是组件加数据的组合。抽完之后加页面才等于加数据。

同时有两处容易忽略的准备：

每个页面的钩子字段要预先留好。 唯一的单位、唯一的边界值、唯一的示例，这些将来要用在结构化标记上，现在不进数据表，以后批量补会非常痛苦。

渲染必须是构建期完成的。 一千个页面如果靠浏览器端渲染，性能不可能合格。Omni Calculator 负责广告的 Alexander Utz 说过一句很实在的话：页面速度对他们来说没有商量余地，整个增长都依赖 SEO，Core Web Vitals 直接影响排名。这句话在一百页时不觉得重要，到一千页时会决定生死。

语言也是一个槽位，但别急着开

Omni Calculator 支持 30 多种语言，这让它的页面数乘了一个不小的系数。看起来很诱人，实际是复杂度最高的一类扩展。

每加一种语言，不只是翻译文案。单位体系可能跟着变（华氏与摄氏、英制与公制），示例里的数字也要本地化，更麻烦的是各语言版本之间要靠 hreflang 说清楚对应关系，否则同一份内容会出现几个互相抢排名的版本。

我的建议是把它排在第一千页之后。先在一个语言里把模板跑通，确认每一页都能拿到流量，再平移第二种语言。 顺序反过来的话，出问题的时候分不清是翻译质量不行还是页面本身不行。

一千页静态站的三个开销

真到这个量级，开销集中在三处，都需要提前量过：

构建时间。 全量重建几千页，几十秒到十几分钟都有可能，取决于每个页面有没有额外的取数动作。写的过程中还要注意：别让任何页面在构建时依赖外部请求，一次失败就整个站发不出去。

sitemap 分片。 单个文件有 URL 数量上限，组织方式上建议按目录切：哪个目录更新了就重新提交哪一份，抓取预算花在真正改动的地方，写法见 /google-search-central/04-sitemaps-robots。多语言站点还要处理 hreflang 的对应关系，别让各语言版本互相抢着被索引。

索引优先级。 页面多了以后不可能全部优先级相同。目录结构这时候又一次起作用：它天然把页面分成组，让你能说出"这批重要，那批是长尾"。

至于基础收录规则，任何时候都以 /google-search-central/ 的官方文档为准。

扩了会亏的两种情况

一种情况是模板本身还没跑通。一百页拿不到流量，问题一般在模板上，扩产只会让沉没成本变大。

另一种情况是每加一页都要手写代码。这说明抽象没做完，此时扩规模等于把维护负债放大十倍。正确顺序是先做到"加页面等于加一行数据"，再谈数量。

把这两扇门守好，剩下的就没什么神秘的：需求没覆盖完、模板已被验证、边际成本接近零，三条同时成立，就从 100 往 1000 走。分批上线，别一次性放出一千页——一次放新页面太快，看不清是哪一批起了作用。

Omni Calculator、Inch Calculator、Homewyse 流量为 Semrush 2026 年 6 月估算；Utz 的表述引自其公开访谈。