Schema 会衰减。这是我测出来的半衰期。

某团队在 Sprint 第六周上线了一份干净的 Schema 架构。校验器全过、AI 引擎开始引用、自然营收上扬,上线后的报告漂亮极了。十二周后,引用份额回到了合作前的水平,而没有人能指出究竟哪一处坏了。

这是这门生意里最贵的失败模式。Schema 没有以任何看得见的方式坏掉。它只是衰减了。

我跨过足够多的合作把这条衰减时间线测了出来,可以给它配上数字。这些数字就是 Retainer 存在的理由,也是「我们自己维护就好」这句话之所以让多个团队最终烧掉六位数返工预算的原因。

我测到的半衰期:60 到 90 天

在一个每周发版、没有 Schema 感知 CI 校验门的团队上,从一份干净的上线基线到第一次实质影响 AI 引用份额的回归,用时是 60 到 90 天。这就是无人维护的 Schema 架构在生产环境里的半衰期。

「第一次回归」我指的是至少破坏其中之一的变更:
- 某个 @id 链(最常见的是有人上线了一个新模板,以不同的 @id 模式发出 Organization,这个漂移就是 Commerce 诊断目录里的 #1 bug 记录的那种)
- 某个对富媒体结果有资格要求的实体的必填字段(价格逻辑重构后,Product 缺了 priceValidUntil)
- Schema 的服务端渲染(开发同学为了「现代化」代码库,把 JSON-LD 移进了一个仅客户端的组件,也就是同一份目录里最致命的 #8 bug)

破坏是无声的。校验器抓不到 —— 校验器只看语法。Search Console 不会浮上来 —— 富媒体结果损失发生在 AI 引擎层,Google 不会报告这一层。团队是在某次季度可见性回顾里才发现的,而那时候第一个回归后面已经叠了三个新的回归。

为什么衰减是结构性的,不是粗心

Schema 回归几乎从来不是马虎工作造成的。是由跟 Schema 毫无关系的代码变更引起的 —— 由不知道 Schema 是承重层的工程师做出来的。

我反复看到的几个模式:

前端重构把组件改成仅客户端渲染。 那个模板的 Schema 生成器原本是服务端的,嵌在页面级组件里。重构把页面级组件拆成更小的片段,Schema 生成器被拽进了一个仅客户端的包装里,AI 引擎抓取器从此就看不到它了。(每个 AI 引擎对客户端渲染 Schema 的处理方式各不相同。)

数据库里加了一个新的商品属性。 市场希望把它显示出来。工程上线了显示侧的改动。没人去更新 Product Schema 把这个字段加进去。结果发给 AI 引擎的 Product 实体相对页面上看到的内容变得不完整,引擎把这视为部分匹配并降权。

为别的需求装了一个 CMS 插件。 插件作为防御性默认注入了自己的 JSON-LD。现在页面上有两个 @id 不同的 Organization 块。实体合并失败。

有人为了「整洁」把多个 JSON-LD 块「合并」成一个。 在合并过程中弄丢了 @id 引用,因为新结构里没有放它们的位置。@graph 现在是平的。

每一种情况里,做出变更的工程师都不知道 Schema 受到了影响。也不可能知道。唯一能抓到这些的方法,是在 CI 里、在变更上线之前。

校验器套件实际上做了什么

跑在 CI 里的 Schema 校验器套件会在每个 PR 上跑三层检查:

1. Schema.org 合规。 标准 JSON-LD 校验。抓不合法的 JSON、未知类型、缺失必填字段。

2. 来自架构决策记录的自定义 @graph 规则。 把项目级的决定编码进来:每个 Product 都引用规范 Brand 的 @id、每个 Article 都引用规范 Person 的 @id、BreadcrumbList 项只用尾斜杠 URL。这些规则在 Schema.org 里不存在,但在您上线的架构里存在。

3. 实体解析消歧测试。 用 RankLabs 用于 AI 引擎抽取的同一组模拟器跑一部分页面。确认 Product 仍然解析到正确的 Brand,Article 作者仍然解析到正确的 Person。

任何破坏其中一项的 PR 都会让构建失败,并附上一个指向出错字段的可读错误。工程师在合并之前修掉。60-90 天的衰减时间线变得无关紧要,因为回归从来到不了生产。

构建这套套件的成本是真实但有上限的:通常是 Sprint 期间的几人天。不构建它的成本会在十八个月后以 Schema 架构重做的形式出现。

怎么判断您的 Schema 现在正在衰减

如果您过去一年内上线过 Schema 工作,而且没有 CI 校验器套件,它正在衰减。问题只是衰减得多严重。三项快速检查:

今天把您前十大模板 URL 跑一遍 Google 的 Rich Results Test。 一个月后再跑一遍。两次跑之间丢失的任何富媒体结果资格,都是衰减。

比对您的线上 HTML 与代码库 Schema 生成器的输出。 如果线上响应里少了生成器发出的字段,那么下游某处(CDN、缓存层、标签管理器)在篡改输出。

今天把您的优先查询集跑一遍 ChatGPT 或 Perplexity,60 天后再跑一遍。 如果在您之前赢过的查询上引用份额下降了,您的 Schema 正在漏。

任意一项失败,都意味着您生产环境里有回归。Audit 找出这些,Sprint 修掉,Retainer 让它们不再回来。

为什么「我们自己维护」通常不奏效

几乎每个 Sprint 客户都会说 Schema 自己维护。每四个里有三个会在一年内回来要 Retainer 或返工 Sprint。原因不是能力,是带宽。

Schema 回归监控属于那种只有持续做才有价值的工作。每季度跑一次的团队会看到五个回归然后修掉。每个 PR 都跑的团队看到零个回归,因为它们在源头就被抓住了。带宽要求不大,但是持续的 —— 而不在某个人季度 OKR 里的持续工程工作,会被丢下。

Retainer 存在的理由,是 Schema 工作属于那种我的时间比您的时间便宜得多的事。我每天跑 RankLabs,回归模式都已经被模式匹配化,在第三天抓住一个回归的工程成本比第九十天抓住它低一个数量级。

如果您上线过 Schema 工作而没有监控,Retainer 是这个网站上最无聊的决定。也是杠杆最高的那一个。