# 这个网站没有复杂功能，却做到了非常大的搜索覆盖

URL: https://caijiao.org/posts/74
Source: docs/posts/74.md
Description: Gusto 那个免费时薪工资计算器，靠搜索量 17000 的 "wage calculator" 拿到约 17776 月访问，访客清一色是正在核算薪资的小企业主。功能只是一次乘除。

Gusto 免费开放了一个时薪工资计算器。它没有账号体系，不需要登录，界面上就是几个输入框：小时工资、每周工时、加班费率。填完给你一个数。

![Gusto 官网首页截图](/images/2026-09/gusto.com.jpg)

*Gusto 首页直接摆出 Create free account 和 See demo——免费账户就是它的漏斗入口。*

Ahrefs 的数据里，"wage calculator" 这个词的月搜索量是 17000，这个页面月访问约 17776。

## 17776 个正在算工资的人

这个数字的分量比它看起来要重：这 17776 次访问的背后，几乎每个人都在同一个场景里——要给员工开工资，正在核一个数。Gusto 做的是薪资和人力服务，这批人恰好是它最想要的那批人。

一个功能极其简单的页面，成了整个公司最精准的入口之一。Shopify 也在用同样的方法，它的 /tools/ 目录里放了一批免费小工具，其中利润率计算器的峰值月访问超过 2 万。

两个例子的共同点是工具本身没有任何壁垒，谁都能做。时薪换算就是小时工资乘工时，利润率就是售价减成本再除售价。它们之所以有价值，是因为对准了一个搜索意图明确、且流量天然带商业属性的词。

## 交互简单不等于实现简单

说它"功能简单"是指交互简单，实现上要处理的坑不少。

第一是精度。22.5 乘 37.5 再乘 52，浮点运算会给出 43874.99999999999 这种结果，直接显示出来用户会以为你算错了。金额类页面要么在展示层做定点化处理，要么用 [Decimal.js](/decimaljs/) 这类库把精度问题从一开始就隔离掉。

第二是规则。加班费率怎么算、税前还是税后、按周还是按月计薪，各地算法不一样。页面要做到覆盖大，靠的不是把交互做复杂，而是把每套规则拆成独立页面——这和 Omni Calculator 的做法一致，它把年薪、时薪、利润率分别放在 /finance/annual-income、/finance/salary-to-hourly、/finance/margin 上，主词月搜索量分别 81000、42000、55000。

第三是落地速度。这类页面是纯静态的，HTML 在服务端生成好，交互脚本只负责输入和格式化，不需要等接口。用户输入一个数，[JavaScript](/javascript/) 在本地算出结果，全程不发请求。既省服务器，也避开了网络往返对响应速度的影响——对一个靠搜索吃饭的页面来说，这比多加两个功能重要得多。

第四是一致性。同一个公式如果前端算一次、导出报告时后端再算一次，两边精度处理不一致就会出现结果对不上。这类页面通常只保留一处计算实现，另一处直接复用，避免出现"页面上显示 43875、导出文件里是 43874.99"这种投诉。

## 覆盖做大的那一半，藏在文字里

功能只有一次乘除，凭什么能吃下几万个长尾查询？答案不在输入框里，在输入框下面那段说明文字里。

用户搜的不只是"wage calculator"，还有"加班 1.5 倍怎么算""每周 40 小时以外算不算加班""年薪 5 万折合时薪多少"。这些问法不会触发新功能，但它们每一个都需要页面上有一段对应的解释、一个对应的示例、一组对应的边界条件。覆盖是靠这些内容铺出来的，功能本身从头到尾没变。

这也是这类页面和"应用"的分界线：应用靠功能覆盖需求，页面靠内容覆盖查询。前者要写代码，后者要写清楚——两者的成本结构和能力要求完全不同。

还有一个容易被当成小事的设计：这些免费工具页通常不放注册墙、不放挽留弹窗，路径短到一次点击就能拿到结果。Gusto 那个页面没有"留下邮箱看完整结果"，说明它对这批流量的期待不是立刻转化，而是让用户记住这次体验。想学这招的独立开发者得先想清楚自己的流量靠什么接住——没有后端产品接着，拦截式转化只会把人赶走。

## 覆盖做大靠的是页面数，不是功能数

Omni Calculator 整站月访问按 Semrush 2026 年 6 月的估算是约 1429 万，支撑它的功能说到底也是"填几个数，出一个结果"。它没有社交功能，没有用户系统，没有内容社区。

它和 Gusto 那个页面的差距不在复杂度，在页面数量：一个是几千个计算器，一个是一个计算器。而页面数量背后是同一套机制——把计算逻辑抽象成配置，页面由模板生成，同一个计算器换 30 多种语言就多出几十个入口。

这两个例子放在一起，"没有复杂功能"和"搜索覆盖很大"之间的张力就消失了。决定覆盖半径的是你能把多少个具体问句变成独立可索引的页面；功能复杂度影响的只是转化率。页面能不能被稳定收录，则是另一件必须在模板层就做对的事，[Google Search Central](/google-search-central/) 里关于索引和质量信号的部分值得对着检查一遍。

## 我不确定的一点

时薪计算器这种页面流量精准，但变现路径很绕。Gusto 把它导向薪资服务，Shopify 把它导向电商工具，两者都有一个更贵的后端产品等着接住流量。

如果一个独立开发者做了同样的页面，17776 次访问能转化成什么，我至今没看到可信的公开案例。展示广告是一种答案，但从 Gusto 和 Shopify 的动作看，它们显然认为这批流量值得更好的用法。这个判断对不对，得等到有人把纯工具站的转化路径跑通才有结论。

---

*Gusto 与 Shopify 工具页数据来自 Ahrefs 公开案例；Omni Calculator 整站访问为 Semrush 2026 年 6 月估算。*