AI 自动化 SEO 实验：Claude Code 每日一更的 42 周数据

一个计算器在 7 月底达到峰值：5 次点击，排名第 26 位。我从未改过它一行代码。然后它跌到了第 43 位，每周 1 次点击——而我依然没有动过它。

与此同时，另一个页面——自动化在 14 天前提交的那个——刚刚创下了该系列的最佳周记录：4 次点击，10.53% 的 CTR，排名第 21 位。

两个事实都是真实的。哪个都拼不出一个干净的故事。这就是本周在 GSC（Google Search Console）里看到的情况。

自 7 月 5 日起，每天的 Claude Code 流程一直在每天优化一个计算器页面。基准数据更新、示例验证、外链来源核实、dateModified schema 更新。提交。重复。

42 次提交之后，本周的队列覆盖了：Runway、Ad Spend、Conversion Rate、CAC、LTV、ARR、MRR。这七个页面在 Google Search Console 中没有任何曝光量。连一次展示都没有。

这部分我是有预期的。今天提交的页面不会明天就出现在 GSC 上。也不会出现在下周。页面上线工作和 Google 响应之间的延迟一直是这个系列的常量。

让我惊讶的是自动化在几周前动过的页面——以及它从未触碰的那个页面——所呈现的模式。

发现 #1：Impression Calculator 在没有通知我的情况下达到了峰值

Impression Calculator 是我们按曝光量计最高流量的页面——过去 28 天有 2007 次曝光。我已经超过六周没有往那个文件提交过代码了。

以下是周数据呈现的内容：

在 8 月 1 日左右发生了某种变化。点击从 5 次降到了 1 次。CTR 从 0.75% 降到了 0.21%。排名一直在下滑——从 31.5 到 43.4，两周内下滑了 12 位。

我回溯了 7 月 30 日到 8 月 2 日之间的每一次提交。没有任何提交触及 ImpressionCalculator.tsx。sitemap 在 8 月 1 日做了一次批量 lastmod 更新——所有页面的日期都被一次性改成了 2026 年 8 月——但我无法确认这是否引发了一次重抓取从而伤害了这个页面，也无法确认这是否只是巧合。

诚实的答案是：我不知道发生了什么。Google 知道。我不知道。

发现 #2：诊断这个问题所需的大部分数据都被隐藏了

Impression Calculator 在页面级别过去 28 天有 2007 次曝光。当我拉取同期的 query 级别细分时，得到了 25 个查询覆盖 174 次可见曝光。

这留下了 1833 次曝光——占总数的 91%——在 GSC 的隐私墓地中。展示次数为一次或两次的查询，未达到公开阈值。流量分布的主体对我来说是不可见的。

我可以看到"impression calculator"（头部词）排在第 30.3 位，2 次点击，49 次曝光。我可以看到"calculate impressions from cpm"排在第 46.4 位，35 次曝光，0 次点击。但我看不到 7 月底那一周是什么带来了 5 次点击，因为这些查询都埋在 GSC 阈值以下了。

我能说的是：可见查询（30–47 位）的排名并没有剧烈变动。如果排名下降了，那主要发生在我看不到的长尾查询上。点击下降和 CTR 下降可能是在我正在监控的查询之外——不可见的大多数身上的排名位移。

这和本系列第一篇文章里贷款还款计算器遇到的是同一个陷阱——聚合排名指标隐藏了分布，而分布又隐藏了实际行为。

发现 #3：Book Value Calculator 无中生有地出现了

Book Value Calculator 在 7 月 25–31 日那周没有任何 GSC 数据。什么都没有。连曝光都没有。

自动化在 8 月 2 日对它做了提交：将 dateModified 字段从 6 月更新到 8 月，把"Last Updated: June 2026"改成了 August，把一个内部链接换成了指向 CSIMarket 行业汇总数据的外链，并更新了基准文本。

以下是之后两周发生的情况：

排名几乎没有变动（21.9 → 21.4）。点击翻倍了。

我不是说自动化提交导致了这些。改动很小——一个日期、一个链接、几句更新的话。排名没动。但页面在两周内从不可见变成了 6 次点击，无论原因是什么，这都值得注意。

当我拉取 query 级别细分时，得到了 5 个可见查询覆盖总共 11 次曝光：

那是 11 次可见曝光。该页面在过去 28 天共有 56 次曝光。六次点击来自阈值以下的查询——又是那个不可见的大多数。无论访问者搜索了什么才找到并点击了这个页面，我都看不到。

发现 #4：第一篇文章里的 og:title bug 依然在线

在本系列的第一篇文章里，我发现 valuefy.app 的每个页面都发送了两个 og:title 标签：一个静态标签 baked 进 index.html，一个由 React Helmet 在预渲染期间注入的动态标签。我承诺"今晚"修复它。那是几个月前的事了。

我今天 curl 了三个页面——首页、Book Value Calculator 和 Impression Calculator。三个都依然显示 count=2：

<meta property="og:title" content="Valuefy - Free Business Calculators &amp; Financial Tools">
...
<meta property="og:title" content="Book Value Calculator: BVPS, P/B Ratio &amp; Tangible | Valuefy" data-rh="true">

client/index.html（第 23 行）里的静态标签还在那里。修复——剥离静态 og: 标签，让 React Helmet 成为唯一来源——从未发生。

要清楚这会造成什么损失：og:title 不影响 SERP 摘要。Google 用的是 <title> 标签和 <meta name="description"> 来生成搜索结果。重复的 og:title 对社交分享预览有影响——Twitter cards、LinkedIn posts、Open Graph 渲染。当有人分享一个具体的计算器页面时，部分平台会抓取到泛泛的站点级标题而不是页面特定的标题。

这是一个真实的 bug。不是 Impression Calculator 排名下降的原因。但它已经在清单上放了好几个月了，现在依然坏着。

我打算怎么做

修复 og:title bug——这次来真的。 改动涉及一个文件，15 分钟。之所以一直没发生，只是因为更高优先级的工作不断冒出来。它应该是下周的第一笔提交。

观察 Impression Calculator—— 如果排名继续下滑超过 50 位，我会对下降前后那几周做完整的 query 级别审计，在我能看到的查询中寻找共同主题。91% 的不可见大多数意味着我无法仅从 GSC 内部来诊断。

不要现在就为 Book Value Calculator 揽下自动化功劳—— 我还需要两周的数据。如果排名改善或点击继续增长，那才是自动化改动有帮助的证据。如果它稳定下来并 plateau 了，那可能只是一次常规的 Google 波动事件。

停止批量更新 sitemap lastmod—— 8 月 1 日的批量更新一次性触碰了所有页面。如果 Google 在一个短窗口内重抓了全部 160+ 个页面，这可以解释意外的排名变化。我会测试只在实际改变了内容的页面上更新 lastmod。

那个令人不安的教训

42 次提交。每天一个页面。验证过的基准数据、更新过的示例、新鲜的外链来源。自动化正在做它应该做的事。

Impression Calculator 在我没有干预时达到峰值，在我没有任何操作时下跌。Book Value Calculator 在没有预警的情况下出现。两者都发生在 Google 的时间表上，而不是我的。

数据一直在告诉我们的是：页面上自动化控制着内容信号——仅此而已。域名权重、竞争态势、不可见的查询分布——那些都是 Google 的领域。你可以改善页面上的每一句话但不移动排名。你可以更新一个日期字段然后让页面第一次出现在 GSC 里。

我没有一个能预测这两种结果的干净理论。而且我越来越怀疑那些声称自己能做到的人。

下周我想知道 Impression Calculator 是稳定了还是继续下滑。如果它依然在第 43 位或更深，每周 1 次点击，那就意味着发生了结构性变化，我需要更认真地审视这个页面实际在和什么竞争。如果它自己恢复了，那就是波动——教训是在宣称某种趋势之前观察两周。

我会报告数据呈现的一切。

我正在 valuefy.app 上运行这些实验，并把发现随时写出来。如果你正在一个竞争激烈的垂直领域建站、调试你没有导致排名下降、或者试图衡量每日自动化是否真的在起作用——我很想比较笔记。留个评论或联系我。

我也运营 AImiten，在那里我们为公司构建 AI 工具。这个副项目是想法最先经过测试的地方。