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 是這個網站上最無聊的決定。也是槓桿最高的那一個。