为什么流量很大的网站不一定赚钱？

Omni Calculator 在 2026 年 6 月的估算访问量约 1429 万，全站靠展示广告变现。它的广告负责人 Alexander Utz 讲过一句没有回旋余地的话：页面速度对他们来说没有商量余地，整个增长都依赖 SEO，Core Web Vitals 直接影响排名。

Omni Calculator 首页把 Math 做成了最大的入口，688 个计算器全在这一格后面。

再往下看一个体量小得多的样本。terrific.tools 做了 12 个月，2025 年 11 月才迎来第一个完整变现月，同期数据是 30 天里 2.6 万用户、3.4 万次会话、4.1 万次浏览，展示广告进账 174.41 美元，加上卖桌面版应用的 125 美元，合起来不到 300 美元。

两组数字摆在一起，"流量大就赚钱"这句话就开始漏风了。真正的分叉在于流量到达之后发生了什么，而不是流量本身有多大。

1429 万和 42.9 万之间，差的不是努力程度

把三个计算器站排成一列看：Omni Calculator 约 1429 万，Inch Calculator 459 万，Homewyse 42.885 万，都是 2026 年 6 月的第三方估算。它们在提供高度相似的服务，头部与末位却差了十倍以上。

这说明同一品类里的流量分布极不均匀，而且这种不均匀基本不受后来者的努力影响。对一个靠广告变现的站点而言，收入被这个分布直接钉死；对一个靠别的方式变现的站点而言，这串数字只是背景噪音，它关心的是人群构成而不是人群规模。

这种向头部集中的现象还带着一个副作用：后来独自入场的人很难靠做同样的事分到蛋糕。他能挪动的空间往往在大站覆盖不到的具体长尾上，哪怕每个词带来的访问只有几十个。

$6.89 这个单价，锁死了广告模式的上限

广告收入只有一道算式：月收入约等于会话数乘以每千次会话单价再除以一千。

terrific.tools 公开的数据里有两个口径值得对照。作者给出的口径是每千次会话 6.89 美元，自己的目标是做到 10 美元；而我拿实际入账的 174.41 美元除以 3.4 万次会话，得到约 5.1 美元，除以 4.1 万次浏览则约 4.25 美元。后两个数字是我按公开数据算的，不是作者口径，差额通常来自广告位填充比例与可见曝光的统计方式不同。

不管用哪一档往上推，结论都很难看。想在单月靠广告挣到 Data Fetcher 那种 23,000 美元，按 6.89 美元需要约 334 万次会话；就算按作者的目标值 10 美元，也要 230 万次会话，已经贴着 TinyWow 整站月访问量的估算区间（180 万到 230 万）。一个人维护的工具站，几乎没可能靠这条路径走到那里。

TinyWow 的中间地带：把流量分了一层给 $5.99

同样的大流量也有别的解法。TinyWow 月访问 180 万到 230 万，工具数量 250 多个，它的结构是免费层兜住所有人，再叠一个每月 5.99 美元的 Pro。

这个 Pro 层能有多少钱，取决于转化率。我这里做一个明确假设：假设付费转化率为 0.1%，200 万次月访问对应约 2000 个付费用户，也就是约 12,000 美元 MRR，恰好落在 Cloakist 与 Sotion 合计超过 $12k MRR 的那个量级上。0.1% 是我给的数字，没有公开数据支持，但它说明一件事：同样的大流量，有没有第二层变现装置，量级差在四十倍以上。

这也解释了为什么有些站明明可以靠广告活得很滋润，仍然要费力去做一个收费层：只有广告那一层时，收入永远停在线性增长的区间里，而 session 单价又被广告联盟掌握着，自己能调节的余地非常有限。

给收入让路的广告脚本，回头咬了 SEO 一口

Utz 那句话里藏着广告模式的内部矛盾：收入来源与流量来源压在同一个页面上，而两者的要求正好相反。广告脚本希望尽早加载、尽早竞价，可脚本体积越大，最大内容绘制越难看；注入瞬间挤走正文位置，又把累积布局偏移推高。Core Web Vitals 一旦掉下去，排名跟着掉，连第二天的展示机会都会变少。

工程上能做的都是琐碎事。给每个广告容器写死尺寸并用 min-height 占位，避免插入时把内容顶下去；非首屏的广告位延迟到首次交互之后再拉起脚本；第三方域提前 preconnect，加载方式用 async；静态资源交给 Nginx 统一配长缓存头和 Brotli 压缩。验证时别盯着当天收入，去 Google Search Central 里看 Core Web Vitals 的实测数据，那里的变化比账单早出现好几周。

会话本身也是有成本的

还有一个常被漏掉的事实。客户端就能跑完的任务，服务器边际成本接近零。10015.io 有 50 多个工具，几乎全部在浏览器里执行，极少向服务端发请求，所以它挂着 AdSense 拿约 300 美元 MRR 也毫不吃力。反过来，凡是转换、渲染、批量重算要占用服务器 CPU 的工具，每一次会话都在烧钱，流量涨上去账单同步涨上去，收入却未必跟着走。

把重计算通过 WebAssembly 压到浏览器一侧，服务端只留下用量记账，一台同等配置的机器能承受的会话上限可以抬高一档。

把服务器开销摊到每一次会话上再算一遍，有些流量其实是负资产：它带来几分钱广告展示，却消耗了处理器时间、日志存储和抓取配额。这道成本项正是"流量很大却不赚钱"里最容易被跳过的一段。

按这条算式往下走，会撞到一个尴尬的位置：流量还在涨，广告收入也跟着涨，可每一千次会话能换回的钱始终被单价按在同一个区间里。流量词越长越好听，账单却只认乘法。

流量数据需要单独看，也需要与成本放在一起看。Omni Calculator 那一千四百多万访问之所以能撑起来，前提是整个团队的增长都在同一个搜索引擎上，任何一个环节变慢都会同时体现在收入与成本两边。

数据来源：Omni Calculator、Inch Calculator、Homewyse 访问量为第三方估算（2026 年 6 月）；terrific.tools、10015.io、Cloakist/Sotion 数据来自创始人公开披露；Alexander Utz 的表述引自公开访谈。