# 一个小网站如何建立自己的关键词矩阵？

URL: https://caijiao.org/posts/75
Source: docs/posts/75.md
Description: Omni Calculator 的 /finance/ 下挂着年薪、利润率、时薪三页，主词搜索量 81000、55000、42000。矩阵是一份可枚举的配置表推出来的。

我第一版做汇率换算站时，觉得把 168 种货币塞进两个下拉框是最优雅的方案：一个页面解决所有问题，改一次模板全站生效。

上线三个月，只有三个词有流量，还都是品牌词。168 种货币里真有人在搜的几十个组合，一个都没拿到。

## 下拉框装不进长尾

问题出在 URL 上。用户搜"USD to JPY"，我给他的页面 URL 是 /currency/，标题是"货币换算"。这个页面对他那个具体查询来说太含糊——它不承诺任何东西，也不包含"日元"这个词。

搜索的运行方式是查询和页面一对一地对应。一个承接了 168 种可能性的页面，等于对每一种可能性都只承接了一点点，谁都不够。

Omni Calculator 的 /finance/ 目录是正面例子。它下面挂的三个页面各自独立：/finance/annual-income（年薪换算，主词搜索量 81000，月流量 50825）、/finance/margin（利润率，55000 对应 49169）、/finance/salary-to-hourly（时薪换算，42000 对应 45940）。三个词语义上离得很近，近到多数人会想合并，但拆开之后每一页都吃到了接近主词搜索量的流量。

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

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

## 目录名应该按用户心智起，不按内部分类起

/finance/ 这个命名值得单独说。它不是"计算类型 A"这种内部视角，而是用户心里那个大类别——跟钱有关的计算都在这儿。

这个选择影响两件事。一是爬虫对站点的理解：一个语义清晰的目录比一堆平铺 URL 更容易被归纳出主题。二是后续扩展时你知不知道新页面该放哪——如果目录是按内部分类起的（比如 /type-a/），加到第 200 个页面时一定会出现"这个到底算哪一类"的纠结。

判断方法很简单：把这个目录名念给一个不看后台的人听，他能不能猜出里面大概有什么。猜不出就换。

URL 那一层也有几条硬规则值得一开始就定死：全小写、用连字符分词、不用查询参数承载语义、不在 URL 里塞日期或版本号。这几条看着琐碎，但矩阵一旦铺到几百页，改一个 URL 规则意味着几百次重定向——而每次重定向都会损失一点权重，也会让已经收录的旧地址再存活一段时间。

## 矩阵是配置表的产物

"关键词矩阵"这个词有误导性——它听起来像一份需要人工去填的表格，实际上它应该是一张数据表的查询结果。

Omni 的做法可以这么理解：一个计算器的本质是一组变量加一个公式。当变量可以被枚举时，页面就可以被枚举。把"币种 A × 币种 B""材料 × 城市""单位 A × 单位 B"这样的组合写成配置，页面由模板渲染，几千个页面就是这份配置的自然展开。它同时支撑 30 多种语言，也是同一份配置换文案。

从工程角度看，你要维护的不是几千个页面，而是一份配置和一套模板。这决定了小团队能不能做矩阵——人工写几千页不可能，写一份配置加一份校验脚本可以。更关键的是，配置表逼着你在动手之前就想清楚变量有哪些、边界在哪，而这两件事恰恰是手写页面时最容易糊弄过去的。

## 规模上来之后先坏的是索引，不是服务器

页面数过了几千，最先出问题的通常不是性能。计算都在浏览器里跑，服务器只发静态文件，[JavaScript](/javascript/) 承担输入解析和格式化，加一页的边际成本几乎为零。

先坏的是索引。新页面从提交到被抓取再到进入索引，有明确延迟和配额；几千个 URL 超过单个 sitemap 上限后要分片；同一份配置的多个参数组合如果生成了内容高度相似的页面，还会互相抢排名，最后谁都排不上去。这些都属于基础设施，[Sitemap 与 robots](/google-search-central/04-sitemaps-robots) 那部分把分片规则、robots 写法和索引状态排查讲得很具体，值得在写第一批页面之前就看一遍，而不是等到几百页没收录再回头补。

页面层面的结构化数据也建议在模板里一次做对。[JSON-LD](/json-ld/) 的标记写进模板，几千页自动带上，比事后逐页补划得来。

## 我会怎么起步

挑一个能枚举的维度，手工写 20 个页面，每个页面对应一个真实问句，URL、标题、说明文字都写具体。这 20 页不是为了流量，是为了验证两件事：这类页面能不能被收录，收录之后排在第几。

这 20 页上线后我会盯两个指标：Search Console 里的展示量变化，和每个页面进入索引用了几天。展示量涨而点击不涨，说明标题和描述没写对；收录超过两周还没动静，说明站点整体权重不够，这时候加页面只会稀释抓取配额，不如先停下来补内链。

20 页跑通之后再上配置化。反过来做——先搭模板再批量生成几千页——一旦模板有问题，返工量是几千页。这是为什么我建议矩阵的第一版用最笨的方式手写：手写会逼你把每个页面之间的差异想清楚，而差异恰恰是模板里最难抽象的那部分。

还有一条我自己吃过亏的经验：先做同目录内的互链结构，再考虑外链。矩阵内部能不能把权重传给新页面，是几千页能不能都活下来的关键，这一步做晚了要花几倍力气补。

---

*Omni Calculator 单页数据来自 Ahrefs 公开案例（/finance/annual-income、/finance/margin、/finance/salary-to-hourly）。*