AI 答案引擎到底是怎麼解析您的 @graph 的

Schema 驗證器查的是語法。它告訴您 JSON-LD 是不是格式正確。它不告訴您 AI 引擎拿它做了什麼。

過去一年,我用 RankLabs 把同一組 @graph 載荷跑過五個 AI 引擎,看它們在哪裡分叉。差別一點都不細微。有些引擎激進地合併實體。有些拆開。有一個完全無視 sameAs 鏈。還有一個會沿著它跟到三跳深。如果您的團隊把 AI 引擎優化當成一件事而不是五件事,您一定會上線一份幫到兩個引擎、傷到三個引擎的工作。

這是那份現場指南。

為什麼 @graph 形態首先就重要

把每個實體放進各自的 JSON-LD 區塊,與放進單一聚合 @graph,這個選擇不是裝飾。AI 引擎先抽取實體,然後跑一個解析步驟 —— 把共享 @id 或透過 sameAs 連起來的實體合併。分散在多個區塊時,合併是按區塊發生(或失敗)的。在 @graph 裡,合併發生在整篇文件內,因為每一處引用都明確綁定到 @id。

具體來說:如果您在一個 script 標籤裡發出 Organization,在第二個 script 標籤裡從 Product 引用它,有些引擎會把這兩份當作不連接的兩份文件,拒絕合併。同樣的載荷做成單一 @graph 就會乾淨地解析,因為引用是本地的。

我測過的所有引擎都更偏好聚合的 @graph。沒有引擎對它懲罰。這是一個單邊選擇。

ChatGPT:激進合併,@id 上很嚴格

OpenAI 的網頁抓取器(以及由它衍生的 ChatGPT 瀏覽工具)在 @id 一致時會激進地合併實體。如果您的 Organization 有一個穩定的 @id,而且每個 Product、每個 Article、每個 BreadcrumbList 都一致地引用它,ChatGPT 會把整個網站收斂成一個知識單元,在各種查詢類型上都自信地引用您。

如果 @id 漂移了(把頁面 URL 當作 id 是這個 bug 最常見的形態,見 Commerce 診斷目錄裡的 #1 bug),ChatGPT 會把每一處引用當作不同的 organization。它不會僅靠名稱匹配就合併。結果是:本應提到您的查詢,引用了擁有穩定 @id 的對手。

我測到的:@id 結構一致的品牌,在相關查詢上的引用次數比內容相同但 @id 不穩定的品牌多 40 到 70%。變數是 @id 結構,不是內容品質。

實用規則:在寫任何 Schema 之前先選定 @id 約定,絕不動搖。品牌實體用 https://yoursite.com/#organization。商品用 https://yoursite.com/products/{slug}#product。文件化。在 CI 裡強制。

Perplexity:沿著 sameAs 走,引用權重高

Perplexity 沿著 sameAs 鏈跟得比任何其他引擎都狠。如果您的 Organization 的 sameAs 包含 Wikidata、Wikipedia、已驗證的社群帳號,Perplexity 會把這些當作信心訊號,在構建答案時給您加權。

如果 sameAs 是空的或指向死連結,Perplexity 會扣分。我看到過品牌僅僅加上一個 Wikidata sameAs 引用,在同一查詢上從「未被引用」變成「被引用」,沒有任何其他變更。

Perplexity 還有一個特點:它帶顯式 URL 出處地引用。Perplexity 上的引用份額是比那些不帶出處只做總結的引擎更乾淨的訊號。如果您要為 AEO 進度做基線,Perplexity 是首先要追蹤的引擎。

實用規則:每個主要實體(Organization、個人品牌的 Person、主力 Product 線)都配一個指向規範外部識別符的 sameAs 陣列。Wikidata 第一,Wikipedia 第二,官方社群第三。

Claude:保守合併,對結構敏感

Anthropic 的解析器是這五個引擎裡最保守的。它不會合併沒有透過 @id 顯式相連的實體。它對結構也讀得更字面:如果您的 Article 實體的 author 設成嵌套的 Person 物件而不是一個回指規範 Person 的 @id 引用,Claude 會把那個作者當作跟您 Organization 引用的人不同的另一個人。

修法跟 ChatGPT 那一個相同(永遠引用,絕不嵌套),但 Claude 對同一個 bug 罰得更狠。

Claude 對 description 欄位也加權很高。主要 Person 與 Organization 實體上一段好的 description 會實質影響 Claude 在總結您時怎麼描述您。馬虎的 description 會原文出現在答案裡,有時候持續好幾年。

實用規則:把 description 欄位當作標題來寫。它就是標題。

Gemini:被 Google 既有訊號加權

Gemini 坐在 Google 更廣泛的基礎設施裡,因此能拿到 Google 十幾年累積的抓取記錄、連結圖、實體關聯。結果是:Gemini 對 Schema bug 最寬容,對更廣泛的話題權威性最不寬容。

您可以上線完美的 JSON-LD,但如果 Google 對您站點既有的話題評估跟查詢不匹配,Gemini 仍然不會引用您。反過來,您可以上線平庸的 JSON-LD,如果 Google 已經在這個話題上信任您,仍然可能被引用。

Gemini 是 Schema 必要但不充分的引擎。在這裡,內容深度和權威性比在其他引擎更重要。

實用規則:在 Schema 工作的範圍裡把 Gemini 排在最後。最後修。先修內容。

Google AI Overviews:結構化資料優先,引用謹慎

AI Overviews 從給常規搜尋用的同一份抓取裡抽取,但對 @graph 抽取加權很高,而且偏好引用擁有豐富、形式良好結構化資料的網站。代價是它經常在沒有明顯出處的情況下做總結,所以歸因比 Perplexity 難追蹤。

最狠擊中 AI Overviews 的 bug 模式是 JS 渲染 Schema 問題(目錄裡的 #8 bug)。Googlebot 會渲染 JS 用於索引,但 AI Overviews 抽取管線在很多情況下讀的是初始 HTML 回應。僅在 hydration 之後才存在的 Schema 對 AI Overviews 這條路徑不可見,即使常規 Google 搜尋把頁面排得很好。我在多個合作裡發現這種問題,團隊都因為 Search Console 回報驗證有效就以為 Schema 沒事。

實用規則:在初始回應裡以伺服器端發出 Schema。永遠。

這意味著什麼對合作範圍

五個引擎不可互換。幫 ChatGPT 的工作(穩定 @id)跟幫 Perplexity 的工作(sameAs 鏈)不一樣,跟幫 Google AI Overviews 的工作(伺服器端渲染)又不一樣。一個有用的 Sprint 範圍按您最想贏的引擎排工作,而不是按哪些修復在簡報裡看著最炫排。

我給 Sprint 定範圍時,會問哪個引擎在驅動品牌最想擁有的查詢。然後架構決策與依模板的實作就優先做這些引擎最敏感的 Schema 模式。驗證器套件把規則編碼進去。

如果您不知道哪些引擎對您重要,那就是 Audit 回答的問題。RankLabs 把您的優先查詢跑過全部五個,回報誰在引用您、誰在引用對手、結構性差距在哪。沒有這個基線,您只是在猜。

引擎不是魔法。它們各有規則。尊重規則的 Schema 工作會贏。不尊重的不會。