# Guide页面和Tool页面应该怎么互相链接？

URL: https://caijiao.org/posts/160
Source: docs/posts/160.md
Description: Shopify 把计算器收在 /tools/ 下，峰值月访问超 2 万；Gusto 的 wage calculator 主词 17000 拿到月访问约 17776。Guide 承接信息型意图，Tool 承接动作型意图，链接方向要 Guide 指向 Tool，反向只链最相关的一篇。

先给两个真实数字：Shopify 把工具收在 `/tools/` 目录下，里面的利润率计算器峰值月访问超过 2 万；Gusto 的 wage calculator，主词搜索量 17000，月访问约 17776。

![Gusto 官网首页截图](/images/2026-09/gusto.com.jpg)

*Gusto 首页的演示界面停在发薪流程第四步：确认一笔 28684.58 美元的提款并提交 payroll。*

这两个例子有一个共同点——工具页面不是孤立存在的，它们挂在一个有内容主体的站点下面。工具带来的流量和内容的信任度是互相喂养的，而把它们连起来的那批内链，就是这个机制的接口。

## 两类页面接的是两种不同的意图

**Guide 页面**接的是"我想搞明白这件事"——利润率是什么、怎么算、多少算健康、和加价率有什么区别。用户在查资料，还没有要动手。

**Tool 页面**接的是"我现在就要算出来"——用户带着两个数字来了，要一个结果。

这两种意图的页面形态完全不同。Guide 需要结构、说明、例子；Tool 需要输入框、即时结果、尽量少的文字。硬把两者合到一个页面上，结果是两边都没做好：查资料的人觉得页面太薄，要算数的人找不到输入框。

分成两类页面之后，链接就成了必须解决的问题——否则它们就是两个互不相干的站，Guide 攒的信任度一点都传不到 Tool 上。

## 链接方向：Guide 指向 Tool 是自然的，反过来要克制

**Guide → Tool**：顺着读下去就该有这一步。一篇讲利润率计算的指南，在"怎么算"那一节后面放一个指向计算器的链接，是用户此刻最需要的东西。这个位置的点击率通常远高于页脚导航。

**Tool → Guide**：要克制。Tool 页面的用户带着明确任务来的，给他一堆延伸阅读会干扰他。只链一篇最相关的——计算器下面放"利润率怎么算"这一篇就够了，不要放五篇。

**Tool → Tool**：同类工具之间可以互链，但要真的相关。利润率计算器链到加价率计算器是合理的，链到一个 PDF 转换器就是噪音。

TinyWow 的处理方式值得参考：250 多个工具，每个工具页底部有一组同类工具的链接，数量控制得很紧，而且都落在同一个动作族里。它的直接访问占到 47.29%、搜索占 33.83%，说明用户在一个工具上获得信任之后，确实会顺着站内链接去用第二个。

## 锚文本要写动作，不要写"相关文章"

Guide 页里指向 Tool 的链接，锚文本写"用利润率计算器直接算"比写"相关工具"好得多。前者告诉用户和 Google 目标页是什么，后者什么都没说。

实现上，我在 [SQLite](/sqlite/) 的 `links` 表里给锚文本留了字段，默认取目标页的 H1，需要更自然的表达时手动覆盖。全站锚文本一致这件事靠人记是记不住的，必须靠数据。

## 面包屑解决的是层级，不是语义

两类页面混在一个站里，面包屑是最容易被忽略的一环。

`首页 > 工具 > 利润率计算器` 和 `首页 > 指南 > 利润率怎么算`——这两条面包屑把层级说清楚了，但用户从工具页跳到指南页时，靠的是正文里的链接，不是面包屑。

所以面包屑用 `BreadcrumbList` 标好层级就够了，语义关联要放在正文里做。两者混为一谈的结果是：正文里全是层级链接（指向分类页），真正相关的页面反而没有入口。

## 结构化数据要跟着页面类型走

Guide 页标 `TechArticle` 或 `Article`，带步骤的可以加 `HowTo`；Tool 页标 `WebApplication`。

这里有个容易犯错的地方：Tool 页面上如果有一段"怎么用这个工具"的说明，不要把整页标成 `HowTo`。页面的主体是工具，说明只是附属。类型标错会让 Google 对页面主题的判定偏移——本来能接住"算利润率"这个动作型查询的页面，可能被当成教程去参与另一类竞争，两边的排名都不上不下。分类型的字段模板在 [JSON-LD](/json-ld/) 里。

## 工具页的加载速度决定了这套链接能跑多远

Guide 把用户送到 Tool 页，如果 Tool 页要等两秒才出来，前面的铺垫全部浪费。

10015.io 的做法是把几乎所有工具都放在客户端运行——Next.js 加 styled-components，50 多个工具，计算全在浏览器里发生。重一点的编解码交给 [WebAssembly](/webassembly/) 跑，服务器只发静态文件。

这样做的好处不只是快：工具页可以做纯静态预渲染，HTML 骨架在构建时就完整，爬虫拿到的和用户禁用 JS 时看到的是同一个页面。Guide 页辛辛苦苦攒来的主题信号，才能真正落到这个 Tool 页上。

一套 Guide 加 Tool 的结构跑通之后，加新工具的成本就只剩下配置和文案，链接关系由构建脚本自动生成——这才是这个结构真正的复利所在。

---

*Shopify /tools/ 与 Gusto wage calculator 数据为第三方估算；10015.io 技术选型（Next.js + styled-components、50+ 工具、客户端运行）来自其公开说明；TinyWow 流量结构为 2026 年上半年估算。*