# 一个网站做到8000个页面，到底有没有必要？

URL: https://caijiao.org/posts/112
Source: docs/posts/112.md
Description: 按八千页分摊，1429 万访问落到每页不到两千。真正的成本是构建时间、sitemap 分片和抓取预算，而不是你写不写得完。

先把三个数字摆在一起（Semrush，2026 年 6 月估算）：Omni Calculator 月访问约 1429 万，Inch Calculator 约 459 万，Homewyse 约 42.885 万。

![Inch Calculator 官网首页截图](/images/2026-09/inchcalculator.com.png)

*Inch Calculator 首页搜索框的占位词是 calculate standard deviation——连示例都在引导长尾查询。*

我不用这三个站的准确页面数，因为没查到可靠的口径。但有一件事可以从侧面验证：这三个站的规模差异极大，而 Inch Calculator 只做尺寸和工程量估算，Homewyse 只做装修报价。同是单一动作，一个把站做到了另一个的十倍以上，靠的不是页面数量，而是那个动作能被拆成多少种具体说法。

因此"有没有必要"这个问题，问法应该换成：**八千个页面里，有多少个能各自回答一个别人没回答清楚的问题？**

## 八千页的第一个真实成本是构建时间

真到了这个量级，第一件会卡住你的事不是内容，是 CI。

假设每个页面静态生成平均 20 毫秒，八千页就是 160 秒；如果页面还需要在构建时查一次数据库或者拉一次外部数据，很容易变成十几分钟到半小时。这段时间里你改一行 CSS，就要等一轮完整重跑，迭代节奏会被彻底打散。

几个省时间的做法值得提前就做：

**构建与运行时解耦。** 页面生成时不允许发起外部请求，所有数据都从本地数据源读。外部依赖一旦进入构建过程，一次网络抖动就会让整个站发布失败。

**按变更集构建。** 改了一个目录下的三个页面，只重建这三个。实现方式各有各的做法，但前提还是那个——目录要分得干净。

**把构建放进容器。** 本地跑得动不代表换台机器还跑得动，把生成环境和工具版本固定下来很重要，[/docker/](/docker/) 做的正是这件事，顺带让 CI 和本地结果一致。

## 先做一次除法：八千页分摊下来是什么量级

有个很便宜的算术可以在动手前做一遍。

假设一个站真做成了八千页，就算它能达到 Inch Calculator 那个 459 万月访问的水平，平均下来每页每月也只有五百多次访问；如果能做到 Omni Calculator 的 1429 万，每页也就一千多。

这个量级意味着两件事。一，**绝大多数页面单独看都是"没什么流量"的**，八千页的意义只存在于总和里；二，既然每页价值这么薄，页面就必须便宜生产、便宜托管，任何需要人工写内容、人工校对的环节都会让这个模型当场失效。

反过来看 TinyWow：250 多个工具，月访问 180 万到 230 万，平均下来每个工具是几千次访问。它的页面贵得起来——每个工具都是独立开发的功能，而不是排列组合出来的。这两种模型没有优劣，只是不能混着做：拿组合模型的期望值去要求工具型页面，或者反过来，都会得到失望的数字。

## 第二个成本：这八千页里有几千页会被看到

第二个现实更难接受。页面不是发了就一定被索引，被索引也不代表会进入查询结果的候选池。规模越大，这个差值越明显。

能做的几件事都集中在"让抓取预算花在刀刃上"：

**sitemap 必须分片，而且要按更新频率区分。** 哪些页面天天动、哪些半年不动，写在 sitemap 里，让抓取更快知道该去哪。分片和字段写法见 [/google-search-central/04-sitemaps-robots](/google-search-central/04-sitemaps-robots)。

**内部链接要有主线。** 八千页如果只能从首页点进去，深层页面基本等于不存在。按目录建立交叉导航，让每个页面离首页不超过三四跳。

**别用 robots 去掩盖问题。** 有些人发现"未索引"变多了第一反应是屏蔽掉一批页面。这等于承认自己做了一堆没用的页面——正确的处理是删掉或合并它们，而不是藏起来。收录的基本规则仍然以 [/google-search-central/](/google-search-central/) 为准。

## 什么情况下八千页是合理的

只有一种情况我觉得站得住：**这个领域真的存在八千种具体说法，而且每一种的答案都略有不同。**

典型的例子是单位换算和量纲估算——Inch Calculator 就是靠这类组合撑起来的。用户搜的不是"换算"，是"3/8 inch 等于多少 mm"这种具体词组，每一个都对应一个确定的输入组合。

反面例子同样清楚。Homewyse 那类的报价场景，词群就那么几个，硬凑到八千页只会得到一堆没人访问、也没人链接的页面。这些拉低平均值的页面在整站信号下是要算账的：Google 在 2025 年把有用性改成了整站信号，规模化内容滥用（4.6.5）和低投入批量生成（4.6.6）处理的正是这种情况。

另一个参照是 TinyWow：它从 2019 年一个 PDF 转换器做起，现在 250 多个工具，月访问在 180 万到 230 万之间。它的页面数远少于八千，因为工具站的数量来自工具数，而不是排列组合。这两种模型的上限完全不同，混着做最容易翻车。

拷问自己一句就够了：如果我把其中三千页删掉，剩下五千页的流量会掉多少？答案如果是"几乎不掉"，那这三千页从一开始就不该生成。

---

*流量数据为 Semrush 2026 年 6 月估算；TinyWow 数据来自第三方估算工具 2026 年上半年。*