在做 TrakToken 的过程中，搜索流量来得很快。这得归功于V站、知乎等地的高质量软文。想要有早期用户，你就必须得厚着脸皮介绍你的产品。有了用户之后，下一步怎么做？我的答案是，从凭借感觉做设计到系统化调整。

从结果来看，TrakToken 自然搜索已经成为主力获客渠道，但增长高度集中在首页和 Bing，查询层、归因和参数 URL 治理没有跟上流量增长。

本文试图介绍，从 SEO 相关角度，如何正确指导我们后续的产品迭代，如何持续构建数据驱动的产品迭代模式。并结合实际线上产品数据，给到说明。

TrakToken 是一个 LLM API 比价工具站，覆盖 60 家厂商 600+ 模型的定价数据，每日自动同步，提供价格对比、成本计算器、支出指数等功能。

一、数据能力

搜索可见性的数据分层

先看定义：搜索可见性实际上是一条管线。每一层回答不同的问题，对应不同的数据源。

层级 回答什么 数据源
需求/查询 用户搜了什么、展示了几次、点没点 GSC、Bing Webmaster
到站与归因 从哪来、落在哪个页面、渠道质量如何 GA4
行为解释 到站后做了什么、卡在哪、为什么走 产品分析平台
业务结果 是否完成决策、是否出站到厂商 同一平台的事件漏斗

这条管线的价值在于，将不同阶段的数据，拆成对应的数据指标和事件层级，高效定位问题，也方便作出取舍、屏蔽不必要细节。

工具选型的实际取舍

GA4 负责渠道归因。免费、接入门槛低、渠道自动分组。缺点是不收自定义产品事件，没法在 GA4 里看到"用户点了计算器然后出站到厂商"这个漏斗。

Vercel Analytics 负责页面和事件。零配置、自定义事件方便。问题是它和 GA4 的用户身份打不通。Vercel 里看到 509 个 calculator_result_viewed 事件访客，但没法知道这 509 人里有多少是从搜索来的。

PostHog 笔者还在尝试中。不过有些问题：一是服务器在海外，国内采集有延迟和丢失；二是功能和 GA4 + Vercel 高度重叠，基础分析和事件采集两边都能做；三是实际只覆盖了 8.25 天，数据量不够支撑任何结论。还有就是他们家的UI太反人性了，我曾经以为GA4的交互很垃圾，但没想到他们家更是。

不过 PostHog 代表的需求是真实的。需要一个单一平台串起落地页、行为动作以及站外动作的工具。

Bing Webmaster 是国内搜索的实际主力渠道。信息比 GSC 丰富，关键词报告直接能导出，排名、CTR、页面级数据一目了然。如果你的用户主要在国内，Bing 可能比 Google 更值得先看。

Microsoft Clarity 提供行为热力图和会话录屏，补充"为什么跳出"的解释。配置简单，免费。

口径对齐

同一时间窗口，Vercel PV 是 21,980，GA4 是 13,059。差了 68.3%。

这个差异天然存在，我记录了可能的原因（bot、拦截、SPA pageview 口径、采集缺口）。不过由于这些数据并未决定重大决策，所以还好其实。干过数据业务的朋友都知道，数据问题本质上是口径问题。同一数据同口径同窗口可比就行，在早期抓绝对的精准，是抓小放大。

二、数据基线

流量规模

28 天对齐窗口（2026-07-23 至 2026-08-19）：

窗口 PV visitor-days 变化
前 28 天 9,257 5,092 -
当前 28 天 22,030 11,606 +138%

渠道情况

渠道 Sessions 占比 Engagement Rate
Direct 2,539 47.4% 30.7%
Organic Search 2,350 43.9% 62.3%
Referral 210 3.9% 70.5%

自然搜索的参与率是 Direct 的 2 倍。说明搜索来的人带着明确目的，找到了想要的东西。

但深挖一层：Bing 贡献了约 92.6% 的自然搜索 sessions，Google 只有 130 个。其实Google 展示量不低（Kimi 页单页 2,958 次展示），但页面级 CTR 有问题需要单独修。

页面级资产

页面 Organic Sessions Engagement 判断
/（首页） 1,544 74.2% 最重要的搜索资产
/spend-index 194 56.2% 差异化品牌资产
/blog/china-llm-comparison-2026 66 25.8% 有入口但参与偏弱
/blog/moonshot-kimi-api-guide-2026 40 20.0% 同上
/providers/moonshot 27 48.1% 长尾入口

首页一个页面就占了自然搜索的 65.7%。任何首页改版都要先保护这个数字。

性能基线

网站要快，要好看，然后用户才会关注到你提供的价值。

CrUX 桌面端实测（P75）：

指标 值 阈值 状态
LCP 2.7s 2.5s 未通过
INP 71ms 200ms 通过
CLS 0.01 0.1 通过
FCP 1.8s 1.8s 临界
TTFB 1.0s 0.8s 需改进

LCP 差 0.2s 没过。瓶颈链路是 TTFB(1.0s) -> FCP(1.8s) -> LCP(2.7s)。TTFB 高是因为每次请求都在读 60 个 JSON 文件做合并计算，没有开 ISR。这个我认为，主要还是数据模型设计的问题，原先 AI 默认设计的数据流方式，当数据膨胀后，开始力不从心需要调整。

产品事件

事件 事件访客
compare_viewed 903
calculator_result_viewed 509
provider_clicked_out 228

产品功能有人用。但这些数字和搜索入口之间断着，跨平台无法归因。

三、SEO诊断

按依赖顺序找最早的阻断点，下游问题在上游没修之前不急着看。

搜索引擎看到的是空壳

首页、计算器、对比工具三个核心页面，用户打开看到完整功能，搜索引擎爬取时拿到的 HTML 里几乎没有实际内容。对不执行 JS 的爬虫来说，这些页面等于空白。

同时，25 页样本中 9 页缺少 self-canonical 标签，参数 URL 已经泄漏到搜索结果（/calculator?model=gpt-5-5 被当成独立页面参与排名），信号被稀释。

首页慢在数据模型

TTFB 1.0s，超出 0.8s 阈值。每次请求读 60 个 JSON 文件做合并计算，没有缓存。原先 AI 默认设计的数据流方式，数据膨胀后力不从心。改造方向明确：开 ISR、数据物化、分层加载，不改布局、不减功能。

有展示没点击

两类不同的问题。

第一类是意图错配。月之暗面api 在 Bing 有 184 次展示、0 点击，Google 同样。搜索结果前列是官方控制台和开发文档，用户搜这个词是要找官方 API 入口，不是第三方定价。处理方式：不争排名，在首屏加官方文档外链承接。

第二类是标题不匹配：

页面 Google 展示 Google 点击 Bing CTR
Kimi 指南 2,958 0 3.15%
中国模型对比 884 0 2.67%

两页合计占全站 Google 展示的 64.3%，0 次点击，但 Bing 有转化。用户搜的是 kimi api 价格 2026 这类词，确实想要价格信息，内容没问题。问题在标题：TrakToken 写的是"选型指南"，竞品直接写价格数字和更新日期（如 Kimi API Pricing (August 2026): Kimi K3 at $3/$15）。每天自动同步价格本来是强项，标题里没体现。

四、取舍

从用户要完成的任务出发，看哪些页面该做、哪些不该做。GSC 90 天导出 + GA4 落地页 + Bing 关键词报告共同支撑以下判断：

用户任务 页面 决策 证据
快速横向比较大模型 API 价格 / update 1,544 sessions；Bing 头部 5 query 中首页获 408/432 展示与全部 45 clicks，Observed
按用量估算月度账单 /calculator update 509 事件访客，搜索入口 GSC 有少量 query
查询 Token 市场趋势 /spend-index update 194 sessions，Observed
查询中国厂商对比 /blog/china-llm-comparison update 66 sessions；聚焦国内厂商横评，不争通用价格词（头部 5 query 中仅 24 展示 / 0 clicks）
查单个模型/厂商价格 /models/[id] support 多页有入口
本地部署还是用 API /models/open-source#local-roi support 11 sessions，不够拆页
英文通用 LLM 比价 - do-not-build 市场拥挤且无英文产品面
任意两模型 vs 页面 - do-not-build 无特定组合的独立 query 证据

做与不做的标准

模型详情页 /models/[id] 应该做。它已经存在，已经有长尾入口（比如 /models/agnes-2-5-pro-alpha 有 41 个 organic landing sessions），是系统性覆盖的合理方式。

“任意 A vs B 对比页"暂时不做。对比工具确实有 903 个访客在用，说明对比需求存在。但工具使用数据证明的是"对比功能有需求”，不是"kimi vs deepseek 这个特定组合有独立搜索需求"。GSC 里没有看到特定组合词的 query 展示。对比工具的分享状态可以承接这类访问，等 GSC 出现特定组合的查询证据再考虑建独立页。

区分标准：页面能不能给用户独特的决策价值。如果和通用工具页的内容没有本质区别，只是换了两个名字，不值得建。

五、方案

性能优化

让首页从"每次请求都重新算"变成"缓存 + 按需加载"。开 ISR 让大部分请求命中 CDN 缓存（TTFB 从 1s 降到 50-100ms）；图表数据预计算成精简版（25KB gzip 降到 3KB）；表格先给 40 条再后台加载全量；各页面不再把 596 个模型的完整数据塞进 HTML。改完后首页 HTML 从 612KB 降到 350KB 以下。

CTR 修复

两个博客页拿走全站 64.3% 的 Google 展示，贡献 0 次点击。位置 7-8 的正常 CTR 是 2-3%，不需要新排名就能兑现。

项 Kimi 指南改前 改后
title 月之暗面 Moonshot / Kimi API 选型指南 2026 Kimi API 价格表 2026：K3 $3/$15，月之暗面全模型报价
首屏 K3 上线时间与涨幅叙述 直接给价格数字，涨幅降到第二句
日期 写死"2026-08-01 更新" 数据更新于 {动态日期}，每日自动同步

中国模型对比页同理：标题改为"18 家厂商 135 个模型报价表"，首屏加最低价与性价比排名。Bing 是当前唯一有转化的渠道，改标题有伤到它的风险，必须一起监控。

搜索基础设施

全站加 self-canonical，参数状态 URL 全部 canonical 到干净路径。首页新增服务端精简价格表（8-12 个主流模型），计算器和对比页新增默认内容，完整交互继续懒加载。模型页的 Product/AggregateRating 标记不合规（ratingCount=1 配自算分数），先移除再决定换什么。

内容节奏

不按日历排期，按数据事件触发：价格变动发快报、TTSI 异常出数据句、中国厂商有动作时更新已有文章、用户决策问题重复出现时写场景案例。每条内容回答四件事：发生了什么、对用户意味着什么、数据参考、号召读者行动。

六、执行节奏

Now：保护已有增长。首页加 canonical + ISR + SSR 摘要，两个博客页跑 CTR 实验，性能改造落地数据物化和分层加载，品牌和数量主张统一（标题里写 500+ 但页面上显示 611+，对不上）。

Next：用证据重排。GSC demand map v1 把前 20 查询簇映射到现有页面；刷新中国模型对比页（66 sessions / 25.8% engagement）；TTSI 做引用包让外部作者能一键复制数据句和图；产品漏斗归因把核心事件放进同一平台。

Later：等证据。英文市场没有 /en/ 正文、导航和 hreflang 前不做；策展式 A vs B 页面等查询证据和独立页面价值同时成立；AI visibility baseline 等固定 Prompt Set 和测量方案就绪。

七、总结经验

其实本篇文章，算是对过去一段时间研究SEO的总结。SEO现在公开互联网上，有各种方法、各种所谓的skills。但你一旦实践下来，就会发现要做的事情非常多，而且常常难以准确归因动作到结果的逻辑关系。也就是说，你做了不一定能在互联网上被看见。但不做，大概率看不见。

本篇技术内容，核心由大模型辅助生产。就像我们如今的coding，目前已几无手工代码。我想，SEO这件事也是。于是便整合了我阅读的书籍、技能以及过往的经验，试图流程化它，让他生成对应的SOP skills。上述的诊断和改动便是前述行为的产物。

目前，这套方法，我已经在两个产品上进行实践。从体感上来说，算是给自己找到了一个落点方向，真实效果也待更长久的数据观察。在AI coding加持下的产品井喷时代，被看见比想法本身更重要。当然，看见也是有技巧和方法的，从前文来说：你需要有数据埋点意识、需要知道数据驱动决策、需要密切关注入口，唯有这样才能减少不必要的自嗨投入，让自己的产品尽快让更多人看到。

参考资料

关于作者