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

URL: https://caijiao.org/posts/167
Source: docs/posts/167.md
Description: 10015.io 用 Next.js 加 styled-components 做了 50 多个工具，几乎全在客户端运行。问题在于：能跑起来的工具不等于能被索引的页面，工具页缺的往往是文字。

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

![10015.io 官网首页截图](/images/2026-09/10015.io.png)

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

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

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

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

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

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

用 [JavaScript](/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](/json-ld/) 那部分有完整例子。

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

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

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

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

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

## 上线前按这个顺序自查

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

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

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

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

---

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