三个月，12491 次搜索展现，53 次点击。CTR 0.42%。我花了一个下午把这份 Search Console 数据拆开，想找出是哪里坏了——结果没有一处坏的，但发现了一个我没预料到的分裂：在完全相同的排名区间，工具页的点击率是文章页的 6.4 倍。
一、先把数据说清楚
数据来自 Google Search Console 的性能报告导出，窗口 2026-05-30 至 2026-08-29，共 92 天。站点是一个中英双语的技术博客，188 个页面在这段时间里拿到过至少一次展现。
全站 12491 展现 53 点击 CTR 0.42% 平均位次 23.30.42% 看起来很糟，但先别急着下结论。CTR 只有和位次一起看才有意义，所以第一步是把 188 个页面按位次分桶：
| 位次区间 | 页数 | 展现 | 点击 | CTR |
|---|---|---|---|---|
| 1–5 | 9 | 33 | 0 | 0% |
| 5–10 | 51 | 1835 | 18 | 0.98% |
| 10–20 | 77 | 2991 | 20 | 0.67% |
| 20–30 | 34 | 5549 | 12 | 0.22% |
| 30+ | 17 | 2083 | 3 | 0.14% |
第一个结论从这张表里直接掉出来：61% 的展现落在位次 20 以后。那是搜索结果的第三、第四页，0.22% 的 CTR 在那个位置是完全正常的。全站 0.42% 的平均值，很大程度上只是”大部分内容排得太靠后”的算术后果，不是文案问题。
但 5–10 位那一格不对劲。第一页底部的 0.98%，比通常见到的 3–5% 低了一大截。这一格有 1835 次展现，样本不算小。所以真正的问题变成了：为什么排到第一页了还是没人点。
二、我先怀疑的那些，逐个排除
在得出任何结论之前，我把常规的嫌疑对象全部实测了一遍。这一节没有惊喜，但值得写下来——因为把它们排除掉，才让后面那个发现站得住。
标题被截断？没有
Google 桌面端标题大约在 580–600px 处截断。我抓了展现最高的 32 个页面的实际渲染标题，按字符宽度估算像素：
最窄 308px 神经网络基础教程：感知机、激活函数和反向传播
最宽 575px Backpropagation Computation Graph: ReLU, Softmax Cross-Entropy...
超过 600px 的：0 个中文标题因为全角字符宽，反而更容易超；但实测下来最宽的是英文标题，也还有 25px 余量。
描述缺失？没有
32 个页面全部有 meta description，长度 51–256 字。有 13 个短于 80 字，偏短，但不是”缺失”。
移动端被压制？不是
这一条我一度以为找到了元凶：
Desktop 10589 展现 49 点击 CTR 0.46% 位次 23.24
Mobile 305 展现 4 点击 CTR 1.31% 位次 11.11移动端只占 2.8% 的展现。技术博客通常是 30–60%。而且移动端位次（11.1）比桌面（23.2）好了一倍还多——排得更好却几乎不给展现，第一反应是 Google 在移动端压制这个站。
但这个推论是错的。回头看查询词列表就明白了：
"cloudflared tunnel --config" "ingress validate"
rfc 9110 connect method proxy tunnel
matrix calculus output only result exam style gradient -site:wikipedia.org
-site:book118.com -filetype:pdf -filetype:xls
"1/sqrt(d_k l)" transformer没有人在手机上打 -site:wikipedia.org -filetype:pdf。桌面端占 97% 不是故障，是这些查询本身就只发生在桌面。如果真是移动端被降权，位次应该更差而不是更好。
结构化数据？确实坏了，但不是这个原因
查到一个真缺陷：每个文章页上有三份互相冲突的 JSON-LD——Yoast 输出了完整的 @graph（含 Article 和 BreadcrumbList），一个自写的 SEO 插件又发了一份 BreadcrumbList，站点自己的 mu-plugin 再发一份 BlogPosting + BreadcrumbList。同一个页面上出现两个描述同一篇文章的实体类型，Google 只能任选其一。
修了一部分。独有的 articleSection、keywords 已经通过 wpseo_schema_article 过滤器并进 Yoast 的节点，站点自己那份重复声明也删掉了——三个 JSON-LD 块降到两个。剩下那份 BreadcrumbList 来自那个自写插件，它不在部署管线里；你现在查看这个页面的源码还能看到它。但把话说全：这修的是卫生问题，预期带来的点击接近零。
站内链接？工具页反而比文章页多
工具页 24 个：正文入链中位数 4
文章页 164 个：正文入链中位数 1
孤儿页：0“好位次零点击”的页面？样本太小而已
有 5 个页面位次 ≤14、展现 ≥100、点击为 0。看着像异常，但按本站 5–10 位区间实测的 0.98% 算，这几个页面出现 0 点击的概率是 11%–35%。完全在随机范围内。这类”看起来不对”的东西，算一下概率就散了。
三、真正的分裂：同一个位次，工具和文章不是一回事
排除完之后，我换了个切法：不按语言、不按主题，按页面类型切——能交互的工具页 vs 纯阅读的文章页。只看位次 1–10 这一格，排除位次差异的干扰：
| 位次 1–10 | 页数 | 展现 | 点击 | CTR |
|---|---|---|---|---|
| 工具页 | 12 | 105 | 5 | 4.76% |
| 文章页 | 48 | 1763 | 13 | 0.74% |
6.4 倍。
点击数只有 5，第一反应应该是”样本太小，别当真”。所以算一下：如果工具页和文章页的真实 CTR 相同（0.74%），105 次展现的期望点击是 0.77 次。观测到 5 次的概率，按泊松分布：
import math
lam = 105 * (13 / 1763) # 0.774
p = 1 - sum(math.exp(-lam) * lam**k / math.factorial(k) for k in range(5))
# p = 0.00122p = 0.0012。样本确实小，但差异不是小样本能解释掉的。
把整个站放进来看，方向一致：工具页 420 展现 7 点击（1.67%），文章页 12071 展现 46 点击（0.38%），4.4 倍。位次 1–10 那一格倍数更大，是因为它剔除了”工具页平均排得更靠前”这个混淆因素。
四、这不能证明是 AI 摘要，但形状对得上
最省事的解释是 AI Overview：一个搜”什么是反向传播”的人，看完摘要就走了；一个搜”dQ/dV 分析工具”的人，摘要没法替他把 CSV 跑出来，他必须点进去。
这个解释和数据的形状吻合：CTR 的亏空集中在好位次。20–30 位那一格 0.22%，和该位置的正常值差不多；5–10 位那一格 0.98%，比正常值低了 3–4 倍。AI 摘要占据的正是搜索结果顶部的位置，它压缩的也正是那一段的点击。
但我必须把话说全：Search Console 不告诉你哪次展现下面挂着 AI 摘要，所以这是推断，不是测量。而且有一个同样成立的替代解释：
搜工具的人，本来就比搜概念的人更有点击意图。一个人搜”在线 dQ/dV 分析”，他的目的就是打开一个网页干活；一个人搜”什么是增量容量分析”，他可能只是想知道个大概。这个差异独立于 AI 摘要存在，在 2015 年也成立。
我没有办法用手上的数据把这两个解释分开。能确定的只有那个事实本身：同位次下，工具页拿到的点击是文章页的数倍。至于成因是”AI 吃掉了信息类查询”还是”工具类查询本来意图就更强”，对于要做决策的人来说，结论恰好是同一个。
五、一个副产品：中英位次差是系统性的
这个站的每篇文章都有中英两版。75 组配对页面里，53 组英文版位次更靠前：
中文侧 8374 展现 26 点击 CTR 0.31% 中位位次 17.2
英文侧 3225 展现 19 点击 CTR 0.59% 中位位次 11.2差距最大的几组：
neural-networks-basics 中文 30.8 → 英文 10.9 (+19.9)
feature-engineering-sklearn 中文 31.2 → 英文 11.9 (+19.3)
matrix-calculus-neural-networks 中文 26.4 → 英文 9.1 (+17.3)
backpropagation-computation-graph 中文 28.4 → 英文 13.4 (+15.0)同一篇内容、同样的作者、同样的域名，中文版排在第三页，英文版排在第一页。原因不难猜：中文技术搜索的头部被几个巨型内容站占满，一个新域名挤不进去；同样的题目在英文搜索里竞争者反而更分散。
但注意这里有个陷阱：英文版位次好，展现却只有中文版的 40%。排得好不等于有量。下一节就是这个问题。
六、我据此改了什么，以及一个失败的尝试
发现”工具页转化高”之后，直觉是多做工具。我做了两个——电池领域的 dQ/dV 增量容量分析器和 HPPC 脉冲内阻分析器，选题标准是”搜索结果里没有同类浏览器工具”。
上线 13 天后的结果：
/en/dqdv-analyzer-en/ 位次 3.4 5 展现
/en/hppc-analyzer-en/ 位次 5.78 9 展现 1 点击
/dqdv-analyzer/ 位次 9.1 10 展现
/hppc-analyzer/ 位次 9.9 10 展现全部第一页。竞争判断是对的——那个位置确实是空的。但空是因为没人搜。13 天 34 次展现，位次再好也换不出点击。
这是我在这份数据里学到最贵的一课：“没人做过”和”有人需要”是两件事，我把前者当成了后者的证据。正确的判据应该是”有搜索量，且现有的做得不好”——而不是”搜不到竞品”。搜不到竞品，往往正是因为没有需求。
反向验证了一下：混淆矩阵计算器这种高频需求，搜索首页有 9 个以上专门的工具站。有量的位置早就被占满了，这才是常态。
七、如果你也在看自己的 GSC 数据
几条从这次分析里提炼的、可以直接拿去用的东西：
- 永远按位次分桶看 CTR。全站平均 CTR 是个几乎没有信息量的数字，它主要反映”你的内容平均排在第几页”。
- 用你自己的数据当基准，别用行业均值。本文所有”正常/不正常”的判断都是拿这个站自己的位次-CTR 曲线做的参照，因为不同主题、不同语言、不同国家的绝对水平差异极大。
- 看到”异常”先算概率。那 5 个”好位次零点击”的页面看起来很可疑，算完发现 0 点击的概率有 11–35%，是完全正常的涨落。小样本上肉眼判断异常几乎总是错的。
- 切一刀”能交互 vs 只能读”。这是本文唯一有统计显著性的发现，而它不在任何标准 SEO 报表的维度里——GSC 不会替你按页面类型分组。
- 源站访问日志数不出读者。这个站在 Cloudflare 后面，边缘缓存意味着一个页面每小时最多回源一次。我第一次尝试用 nginx 日志统计真人访问时，把 42 次自己的缓存预热任务、12 次自己写的分析脚本和 36 次 curl 验证都算成了”真人浏览器”。
References
相关阅读：dQ/dV 增量容量分析器 和 HPPC 脉冲内阻分析器（本文提到的那两个工具）、量化自己站点的模板同质度（另一次拿自己站点当数据源的测量）。