一个工具页面应该有哪些SEO元素？

10015.io 是个很值得拆的站点：Next.js 加 styled-components，50 多个工具，几乎所有计算都在浏览器里跑完，服务端基本只发静态文件，AdSense 月收入约 300 美元。

10015.io 首页没有价格入口，整页只讲一件事：把书签栏里那堆工具链接收进一个盒子。

这个架构在成本和体验上都是对的，但它暴露了一个常见误解——**一个能正常工作的工具，和一个能被搜索引擎完整理解的页面，是两件不同的事。**前者只需要输入框和计算逻辑，后者还需要一批"看起来多余"的东西。

页面上必须有可抓取的文字，哪怕工具本身是纯交互

工具页最容易长成这样：一个 H1、一个输入框、一个按钮、一个结果区，其他什么都没有。

从 HTML 的角度看，这个页面的正文内容接近于零。Google 抓到它，能确定的只有标题里那几个词，剩下的全部依赖 JS 执行后才出现。就算它被索引了，也没有足够的信息判断它满足的是哪个查询。

最低限度要补三段文字：这个工具是干什么的、怎么用它、结果怎么解读。三段加起来两三百字，写起来很快，但页面从"一个控件"变成"一个答案"。

用 JavaScript 做渲染没问题，前提是这三段文字在服务端返回的 HTML 里就已经存在，而不是等组件挂载后再插入。

验证方法很简单：关掉浏览器 JS，或者直接用命令行请求这个 URL，看返回的内容里有没有那三段字。搜不到的，就当作 Google 也可能搜不到。Search Console 的网址检查工具里有个"查看已抓取的页面"，看到的就是 Google 视角下的 HTML，比任何本地调试都准。

示例输入输出，是工具页最便宜的内容

比通用说明更有效的是一组具体数字。

一个时薪换算页面，与其写"支持自定义参数"，不如直接给出："每小时 50 元、每周 40 小时，按 52 周计算，年收入为 104000 元。"这句话里同时包含了输入格式、计算口径和结果量级，用户读完就知道自己会得到什么。

示例值还有个附带好处：它让页面在长尾查询里有东西可匹配。有人搜"时薪 50 年薪多少"，页面上正好有这组数字，靠的不是关键词堆砌，是示例本身。

示例值应该在配置里写死，构建时渲染进 HTML，不要靠 JS 随机生成——每次抓取看到的值都不一样，反而让页面失去稳定性。

示例最好配一个简短的解读。同样一组数字，加上"这里按每年 52 周计算，未扣除法定节假日"一句，就把计算口径讲清楚了，也顺带回答了用户最常见的疑问。

一个 H1、一个 canonical、一组相关工具链接

结构上要明确的几项：

H1 全站只有一个，内容要和标题一致但不必完全相同——标题受长度限制，H1 可以更完整。别用图片当 H1，也别让 H1 是站点名。

canonical 指向自己，指向的是不带查询参数的那个版本。工具页经常有 ?from= 之类的追踪参数，没写 canonical 的话，同一个页面会分裂成好几个 URL 互相竞争。

相关工具的内链放在页面底部，取同一父目录下的邻近条目。这是程序化站点唯一能自动化、又确实有用的内链形式。

还有两项容易漏：og:title 和 og:image 决定页面被分享到社交平台时的样子，工具页的 og:image 最好带一组示例数字，比纯 logo 的点击率高；移动端视口和按钮尺寸则直接影响 Core Web Vitals 里的 CLS——结果区在加载完成后突然把下方内容顶开，是最常见的布局偏移来源。

结构化数据用哪几种

工具页适用的类型不多，别贪多。主体用 WebApplication 或 SoftwareApplication，声明它的功能、是否免费、是否需要注册；再配一个 BreadcrumbList 把类别层级交代清楚。具体的字段写法和校验方式，JSON-LD 那部分有完整例子。

要不要加 FAQPage 是另一个问题，单独说。这里的关键是先保证主体的标记是准确的——标错类型的结构化数据，比不加更糟。

速度是工具页的硬指标，不是加分项

工具页的竞争对手往往就是另一个工具页，功能差不多的时候，加载速度直接决定谁留下用户。

Omni 的广告负责人 Alexander Utz 说过：页面速度对他们没有商量余地，整个增长都依赖 SEO，Core Web Vitals 直接影响排名。这句话放在一个把全部增长押在搜索上的站点里，是很实在的成本判断，不是口号。

重计算留在客户端是实现这一点的关键手段。把编解码、批量处理、数值求解编译成 WebAssembly 在浏览器里跑，服务端不参与，页面首屏就只依赖静态资源。10015.io 选的正是这条路。

上线前按这个顺序自查

我按"能不能被机器校验"排序：

能在构建期自动检查的先查——H1 是否唯一、canonical 是否指向无参数版本、结构化数据能否通过解析、正文文字是否超过 200 字、示例值是否为空。这几项写进 CI，每次构建跑一遍。

需要人工看的只有两项——三段说明文字是否真的有用，示例值是否贴近真实使用场景。这两项机器查不出来，但也是唯一能拉开差距的地方。

第三类检查放在上线后：Search Console 里看这一页实际吃到了哪些查询。如果拿到的查询和页面预期完全不沾边，说明页面上的文字没有把意图表达清楚，改的是文案不是技术。这套循环跑通几个页面之后，模板该长什么样就清楚了。

10015.io 技术栈、工具数量与 AdSense 收入数据来自作者在 Indie Hackers 的公开分享；Alexander Utz 表述引自公开访谈。