# 小流量网站有没有可能赚到钱？

URL: https://caijiao.org/posts/213
Source: docs/posts/213.md
Description: Cakedesk 在 2025 年卖出两百三十九份新授权、毛收入约合一万六千欧元，同期流量持平；Data Fetcher 只用六百个付费客户撑起两万三千美元月收入，一个人在伦敦运营。

能，而且这条路比看上去拥挤。德国自由职业者 Max Schmitt 做的 Cakedesk 是一个桌面端发票应用，一次付费 €69 永久使用，2025 年卖出 239 份新授权，毛收入约 €16,000，比这个数字更值得咀嚼的是他自己的描述：这一年流量持平，销量却涨了。

![Cakedesk 官网首页截图](/images/2026-09/cakedesk.app.png)

*Cakedesk 首页没有免费版字样，只有 Try for free 和 Buy now 两个入口。*

它与那些靠流量吃饭的站点的根本差别在于，算式里压根不出现访问量这一项。

这里的"小流量"不是谦虚的说法，而是具体到一天几十个人的程度：这类站的全部访客加起来，可能还不够一个大站一个小时的进人数量。它没有可以稀释失败的人群，也因此必须早早把每一次访问都当成具体的一个人来看待。

## €69 乘以 239 约等于 €16,000，中间没有 PV

69 乘 239 等于 16,491，与公开的约 €16,000 毛收入基本吻合，剩下几百欧通常用来自退款与支付渠道手续费，这是我补的解释，原作者没有拆分。2024 年的数字是约 170 份，一年增幅约 40%。

同一年里他发了 12 个版本，收到 44 个功能请求，只完成 13 个。功能数量显然不是推动这 40% 的原因。十几个版本里绝大部分改动都上不了更新日志的显眼位置，它们修的是安装流程、发票模板的细节、某个税率的取值方式。对一个开票工具来说，这些琐碎比多一个花哨面板更能影响付款决定。

他也没有把六十九欧元摆在一个需要反复说服的位置上。一个人决定要不要掏这笔钱，通常只有几分钟；这几分钟里他关心的是装好之后能不能立刻开出一张合规的发票，而不是功能列表有多长。

## 六百个客户撑起 $23,000 月收入，创始人独自住在伦敦

Andy Cloak 的 Data Fetcher 是一个跑在别人工作流里的 Airtable 扩展，公开数据是 MRR 23,000 美元、付费客户 600 个。用 23000 除以 600 得到约 38 美元，这是我按公开数字反推的客单价，不是官方给出的口径。

600 个人，规模接近一家中等公司的一个部门，连微信群都凑不满。把它和上一节的 Cakedesk 摆在一起看：一个是一年收入 €16,000，一个是月收入 $23,000，两者都不是靠每天几万次访问换来的，靠的是每一笔成交都能追到具体某个人身上。

对照组是 terrific.tools：2.6 万用户、3.4 万次会话，一个月的广告加软件收入不到 300 美元。用户数是前者的四十倍，收入是它的零头。

这两组数字相差悬殊，可它们各自都算得上正常。前者面对的是少数愿意为具体工作付费的人，后者面对的是进来转一圈就走的人，同一个开发者换个人群，结果会立刻改写。

## 渠道可以换，搜索意图不能丢

Cakedesk 在 2024 年跑得通的付费获客渠道，到 2025 年失效了，缺口由 Google 自然搜索补上。这句话对小流量产品尤其重要：投放渠道随时可能变贵或变无效，但只要产品占住的是"我要开一张发票"这类带明确意图的词，自然搜索这一层兜底就一直在。

把这类页面稳定地送进索引、让意图词被正确识别，正是 [Google Search Central](/google-search-central/) 文档覆盖的范围——站点地图、索引覆盖、结构化数据。做完不会立刻暴涨，漏掉一定吃亏，越是小流量的站点越经不起漏掉。

## 免费层只要接得住意图就够了

Gusto 的免费时薪工资计算器所在的词 wage calculator 搜索量是 17000，对应约 17776 次月访问，来的人全是正在核算薪资的小企业主。Shopify /tools/ 下的利润率计算器峰值月访问超过 2 万，来的人都在开店。

这类页面不承担变现任务，它们的作用是在搜索框里让人举手。17776 次访问放在计算器品类里排不上任何名次，Inch Calculator 是 459 万，可它的后续完全不同：每一次访问背后都有一笔即将发生的支出。

做这一层时有个容易拧的地方：既然访问量这么少，是不是该加更多功能把它填满？多数情况下不要。Gusto 和 Shopify 的计算器都只解决一个很窄的问题，窄到用户搜那一个词的时候心里想的就是它。覆盖面一宽，词就模糊了，进来的人虽然变多，愿意走到第二步的比例反而下降。

## 流量少意味着容错低，账要记到每一笔

访问量少的产品没有稀释错误的余地。一次注册失败、一次重复扣款、一封发不出去的授权邮件，直接反映在当月收入上。订单、授权、用量、到期日这些记录，放在 [SQLite](/sqlite/) 里拆成三张表就够用：客户表、权益表、事件表。单机上的 SQLite 撑到几十万行毫无压力，备份也只是复制一个文件。

金额千万别用浮点去累加。€69 乘以 239 在双精度下不会出错，可一旦掺进折扣、税率、退款分账，误差会累积到对不上账的程度，用 [decimal.js](/decimaljs/) 做定点运算是所有带账单系统的起步配置。开票场景里这一点尤其敏感：一张票上的税额如果与机内算法对不上，用户会立刻质疑整套东西的可靠性。

€16,000 分摊到一个人身上，是体面的一年；同样一笔钱分摊到两百万次访问上，几乎等于什么都没发生。区别只在于那些访客里，有多少人带着一张必须今天开出来的发票。

---

*数据来源：Cakedesk 数据来自 Max Schmitt 公开的年度总结；Data Fetcher 数据来自 Andy Cloak 公开披露；terrific.tools、Gusto、Shopify、Inch Calculator 流量为创始人披露或第三方估算。*