# 我拆解了一个网站的SEO结构，发现它最重要的不是首页

URL: https://caijiao.org/posts/72
Source: docs/posts/72.md
Description: Omni Calculator 的 /other/test-grade 主词搜索量只有 5900，月访问却 61086。整站 1429 万里它占不到 1.5%，首页只负责导航。

Ahrefs 抓过 Omni Calculator 的一组单页数据，其中一页我盯着看了很久：/other/test-grade，主关键词月搜索量 5900，月流量 61086。

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

*Omni Calculator 首页写着 3925 个免费计算器，Finance 一个分类就占 616 个。*

一个词的搜索量是 5900，页面却拿到 6 万访问。这不合理——除非这个页面的流量根本不来自那个主词。它来自上百个更碎的查询：成绩百分比怎么算、GPA 怎么换算、78 分对应几个绩点。主词只是从这一堆查询里挑出来的最大项，不是流量本身。

## 5900 的搜索量，撑出 61086 的月访问

同一份数据里还有几页，读起来更有意思。/finance/annual-income，主词搜索量 81000，月流量 50825；/finance/margin，55000 对应 49169；/finance/salary-to-hourly，42000 对应 45940。

后面两个页面的搜索量比流量还高。这说明主词的搜索量只能解释页面流量的一部分，剩下那部分来自同一个语义簇里的其他说法。把三个页面的数字加起来还不到 15 万，而 Semrush 给 Omni Calculator 整站的估算（2026 年 6 月）是月访问约 1429 万——我随手挑出来的四页，占不到 1.5%。

剩下的 98.5% 分布在几千个结构相同的页面上。

## 首页在这套结构里只负责导航

想清楚这个比例之后，"首页重要吗"这个问题就有了答案。

用户从搜索进来，直接落在能用的计算器上，算完就走。相当一部分人从没看过它的首页长什么样。首页承担的其实是另一件事：把几千个页面按 /finance/、/other/ 这样的目录归类，让爬虫能顺着层级往下爬。

对做站的人来说这个区别很实际。首页做得漂亮不带来流量，目录层级设计得对不对才决定收录率。几千个 URL 如果全部平铺在根目录，抓取深度和优先级都会失控；按语义分桶、桶内互链，爬虫的路径就清晰得多。

分桶还有个容易被忽略的收益：同一个桶里的页面可以互相链接。/finance/ 下的十几个计算器彼此互链，等于把权重在语义相近的页面之间传导，新页面上线后能借同桶页面已有的抓取频率被更快发现。平铺结构做不到这件事——几千个 URL 之间没有任何语义线索告诉爬虫哪些该优先。这部分的规则在 [Google Search Central](/google-search-central/) 里讲得比我这里细。

## 几千个页面不是几千次开发

最容易误判的一点：几千个页面不等于几千次开发。

Omni 的做法是把计算器抽象成配置——变量、公式、单位、说明文案、示例——页面由模板渲染。加一个新计算器，工作量是写一份配置和一段解释，不是写一个新页面。它能同时支撑 30 多种语言，靠的也是同一套机制：一份配置换一套文案，就多一个语种版本。

多语言带来的工程问题在 URL 和 hreflang 上。同一份配置要在 30 多个语种版本之间标注对应关系，标错一次，就会出现某个语种页面去抢另一个语种排名的情况。这部分没有捷径，只能靠生成时的校验脚本兜住——也说明配置化不只是省人力，它同时是唯一能规模化保证一致性的方式。

技术上真正的约束在前端。计算器要在用户输入时立刻出结果，这个活放在浏览器里做，用 [JavaScript](/javascript/) 处理输入解析和格式化就够了，服务器只发静态 HTML 和一份配置。金额类计算要额外小心浮点误差——0.1 + 0.2 那类问题在工资、利润率页面上会被用户当成 bug 报过来，展示层至少要做定点化处理。

## 「页面速度对我们没有商量余地」

Omni 的广告负责人 Alexander Utz 说过一段话，我记了很久：页面速度对他们没有商量余地，整个增长都依赖 SEO，Core Web Vitals 直接影响排名。

这句话要放在页面矩阵里读才有分量。一个站只有几十个页面时，慢一点无所谓；有几千个页面时，每个页面慢 200ms，就是几千个页面的排名同时往下掉。而计算器页面天生有个劣势——必须加载交互脚本，LCP 和 INP 比纯文本页难压。

这里有个很常见的浪费：所有工具共用一份打包产物，用户打开一个汇率换算页，却下载了全部几百个公式表。按路由拆包、只加载当前页需要的那一份配置，对 LCP 的改善是立竿见影的。把公式表做成静态资源、计算逻辑留在客户端、首屏不塞广告，这些选择不是洁癖，是几千页站点的生存条件。

页面级别的结构化数据也值得单独做。答案型页面在搜索结果里多一块富摘要，点击率差别不小，[JSON-LD](/json-ld/) 那套标记写进模板，几千页自动带上。

## 1429 万和 61086 之间差的是什么

回到开头那组数字。61086 的页面不是爆款，是整个矩阵里普通的一员。1429 万不是靠几个大页面撑起来的，是几千个"主词几千、长尾一大把、每月几万访问"的页面累加。

差别不在单页做得好不好，在于有没有一套能低成本复制页面的机制——配置化的计算器、语义化的目录、可静态托管的渲染方式。没有这套机制，做 30 页就是上限；有了它，页面数只是内容和时间投入的函数。

我没有答案的是这套机制的天花板在哪：是能被写成公式的问题总数，还是每种语言本地化的成本。Omni 做到 30 多种语言还在加，这个问题暂时只能放着。

---

*Omni Calculator 单页数据来自 Ahrefs 公开案例（/other/test-grade、/finance/annual-income、/finance/margin、/finance/salary-to-hourly）；整站访问量为 Semrush 2026 年 6 月估算；Alexander Utz 引语来自其公开访谈。*