# 我做一个网站之前，第一件事情不是写代码

URL: https://caijiao.org/posts/118
Source: docs/posts/118.md
Description: 我曾花两周写完一个图片工具站，上线后才发现它的搜索词拆不出 20 个页面。TinyWow 靠一个 PDF 转换器长到 250+ 工具，10015.io 的第一步是数自己书签栏里的工具数量，不是写下第一行代码。

去年我写过一个图片处理站。编辑器、拖拽上传、批量队列、进度条都做齐了，两周写完，上线之后三个月日访问没超过 40。

失败的原因不是做得差。是我把顺序搞反了：代码写完才去想用户会搜什么，然后发现这个方向总共只有"图片压缩""图片格式转换"两个有真实搜索量的词，其余的都是类别词——"好用的在线图片工具"这种。两个页面撑不起一个站，再多写十几个功能也没用，因为它们共用一个入口。

从那之后我把第一件事换掉了。

## 第一件事：把用户会敲进搜索框的那句话写下来

不是写定位，不是写 slogan，是把那句查询原样写下来。要具体到动词加对象："pdf 转 word""房贷月供 计算""mov 转 mp4"。

写完这句之后做一个很机械的动作：把它拆开，看能拆出多少条同样具体、同样有独立搜索量的句子。PDF 这个品类能拆出 merge、split、compress、to word、sign、unlock 几十个；图片压缩只能拆出两三个。

判断线我定在 20 条。拆不出 20 条的题，说明它只能做成一个孤岛页面——流量进来一次就断了，没法形成页面矩阵，也就没有积累效应。TinyWow 从 2019 年一个 PDF 转换器长成 250 多个工具，靠的不是后期努力，是它一开始就选了一个能拆的品类。

![TinyWow 官网首页截图](/images/2026-09/tinywow.com.png)

*TinyWow 首页的分类卡按工具数量排：PDF 45+ 最多，Video 和 AI Write 各 10+。*

举个具体的拆法。假设你写下的那句话是"房贷月供计算"，能拆出来的不只是"房贷计算器"本身：等额本息和等额本金的对比、提前还款能省多少利息、公积金组合贷怎么算、按贷款总额反推月供、LPR 调整后的月供变化。五六个页面是稳的，再往下还能按城市、按年限展开。

反过来，写"做一个好用的记账网站"就拆不动——用户不会搜这句话，它描述的是类别，不是动作。类别词没法开工，因为它不对应任何一个可以单独做出来的页面。

这件事不需要写代码，甚至不需要打开编辑器。一个下午，一个表格，就够了。

## 第二件：确认这一刀砍在浏览器里还是服务器上

题目能拆之后，第二件事仍然是决定，不是编码。

10015.io 的做法值得直接抄：**几乎所有工具在客户端运行，极少请求服务端**。这不是性能优化，是架构前提——一旦某个工具的运算必须走服务器，你的成本就随用户量线性增长，还要处理上传、排队、清理文件这一整套。

判定方式很具体：输入能不能完整进内存、处理能不能在几秒内结束、结果需不需要落盘。三个都答"是/不需要"，就把活留在浏览器。编解码和重计算交给 [WebAssembly](/webassembly/)，服务器只发静态文件。

这一步做完，后面"服务器买多大""每月烧多少钱"这两个焦虑基本就消失了。唯一要留意的是 wasm 文件往往不小，转码类工具动辄几 MB，需要做懒加载——用户点了才开始下载，别放在首屏。

判定结果最好写进文档里，写成一句话：这个工具的处理发生在浏览器内，服务端不接收文件。后面所有实现都对着这句话检查。它同时也是一条产品承诺的基础——TinyWow 敢明写"上传的文件 1 小时后自动删除"，正是因为大部分处理根本不需要在它那儿留痕。

## 第三件：把 sitemap 和 Search Console 先备好，再动业务代码

第三件事听着像运维，其实直接影响前两件事能不能验证。

拆出来的 20 个页面，需要一个 sitemap 明确告诉搜索引擎它们存在；上线之后需要 Search Console 看实际进来的是哪些词——你猜的和用户真的敲的往往不是一回事。[Google Search Central](/google-search-central/) 里关于索引和抓取的那部分是必读的，sitemap 与 robots 的写法在 [sitemaps 与 robots](/google-search-central/04-sitemaps-robots) 这一节讲得最细。

Search Console 的接入应该在写完第一个页面之后立刻做，别等站做完。原因很实在：从提交到有数据通常要等上一两周，等到站做完再接，你就白白少了一个月的真实查询词。[接入步骤](/google-search-central/02-search-console-setup)本身不超过半小时。

## 做完这三件，才知道要写什么

有一个副作用值得提前说：这三件事做完，你很可能会发现自己原本想做的那个东西不值得做。拆不出 20 个页面是一种，判定后发现必须走服务端、成本扛不住是另一种。

我后来把那个图片站关掉了，不是因为它做不完，是因为它在第一件事上就已经不成立。早两天做这个判断，能省下两周代码。

这三件事的共同点是都不产出代码，但都产出约束：第一件告诉你写几个页面，第二件告诉你计算放哪一端，第三件告诉你怎么验证前两件对不对。

terrific.tools 是个对照。它老老实实做了 12 个月，到 2025 年 11 月才迎来第一个完整变现月——广告 174.41 美元加桌面版 125 美元，不到 300 美元，同期 3.4 万次会话。12 个月换 300 美元，这里面有多少是"选错了题"造成的，作者自己大概也在复盘。

我现在还没验证的一件事：这套顺序是否同样适用于不依赖搜索流量的产品。Cakedesk 靠的是付费渠道和自然流量，Max Schmitt 2025 年发 12 个版本、239 份新授权，它的第一件事显然不是拆关键词。这两条路的第一个动作到底差在哪，我手上的样本还不够下结论。