你的網站每一頁可能都貼了 schema，AI 引擎讀完之後卻還是不知道這個 WebPage 屬於哪個網站、這個網站又是誰在經營。問題不在標記數量，而在這些標記彼此不認識。把 Organization、WebSite、WebPage 各自寫成一塊孤立的 JSON-LD，等於發給機器三張沒有連線的名片。@graph 的作用，就是把這三張名片用一條明確的線串起來，讓 AI 一次讀懂整個網站的實體結構。
分散的 schema 為什麼讓 AI 拼不回你的網站
多數網站的 schema 是外掛或 CMS 樣板自動吐出來的：首頁一塊 Organization、文章頁一塊 Article、定價頁一塊 Product，各寫各的。單看每一塊都合法，Rich Results 測試也會過。問題在機器想回答「這篇文章的發布者是誰、可不可信」時，手上只有一堆浮在半空的物件，沒有任何欄位告訴它 Article 的 publisher 就是首頁那個 Organization。尤其是 AI 摘要與答案引擎，它們判斷要不要引用你，很大一部分看的是能不能把內容對應到一個真實、可查證的組織。關係一缺，你的內容就從一家公司的正式資料，掉回一段來路不明的文字。
@graph 到底做了什麼
@graph 是 JSON-LD 的頂層欄位，值是一個陣列，裡面能放進多個實體物件。它把原本要拆成好幾個 script 標籤的實體，收進同一份文件、同一個命名空間。關鍵不在「放在一起」，而是放在一起之後，物件能用 @id 互相指名：你在 Organization 上宣告一個 @id，之後在 WebSite 的 publisher 只要填同一個 @id，機器就知道兩者是同一個實體，不必把整段 Organization 重抄一次。這種定義一次、到處引用的模式，正是知識圖譜的基本作法；schema.org 支援 @graph，就是為了讓一份頁面能表達實體之間的關係，而不只是列出一堆屬性。
一頁只要一個 script 標籤就裝得下整張 @graph。這順帶治好一個老毛病——同一個 Organization 被三個外掛各寫一次、屬性還互相打架。在 @graph 底下，這家公司只會出現一次，成為全站唯一的事實來源，維護時也只改一個地方。
@id：給每個實體一個穩定的門牌號
@id 是整套寫法的地基。它是一個全域唯一的識別字串，慣例上用網址加井號片段的形式，例如 https://example.com/#organization。這個值不必真的能打開，它的任務是當識別碼，不是當連結。只要同一個實體在站內每個角落都用同一個 @id，AI 就能把散在各頁的資訊歸戶到同一個主體底下。同一個 @id 出現在首頁、文章頁、定價頁，機器就把這些頁面對這家公司的描述疊在一起，形成一個資訊更完整、也更難造假的實體檔案。
- Organization 用網域根加片段，例如 https://example.com/#organization，全站唯一，永遠指同一家公司
- WebSite 用網域根加 #website，代表整個站台這個實體
- 每頁的 WebPage 用「該頁網址 + #webpage」，值隨頁面而不同
- 片段命名固定成團隊共識（#organization、#website、#webpage），別今天寫 #org 明天寫 #company
- @id 一旦上線就別亂改；改了等於製造一個新實體，過去累積的關聯全部斷掉
三個實體怎麼互相指向
串接的方向有邏輯：由小指向大、由頁面指向主體。WebSite 用 publisher 指向 Organization，宣告這個站由這家公司經營。每頁的 WebPage 用 isPartOf 指向 WebSite，宣告自己是這個站的一部分。如果這頁在講公司本身（關於我們、定價這類），再用 about 或 mainEntity 指回 Organization。文章頁則讓 Article 的 publisher 同樣指向那個 Organization 的 @id，發布者關係就補齊了。
一份可以直接套用的完整範例
下面這份 @graph 放進頁面 <head>，用一個 script 標籤就裝得下三個實體：各自宣告一次 @id，再用 @id 互相引用，而不是把 Organization 重抄一遍。實務上把 Organization 與 WebSite 兩塊抽成全站共用、只寫一次的模板，WebPage 那塊隨每頁的 url、name、@id 動態帶入即可。 { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://example.com/#organization", "name": "Example 公司", "url": "https://example.com/", "logo": { "@type": "ImageObject", "url": "https://example.com/logo.png" }, "sameAs": [ "https://www.linkedin.com/company/example", "https://x.com/example" ] }, { "@type": "WebSite", "@id": "https://example.com/#website", "url": "https://example.com/", "name": "Example", "publisher": { "@id": "https://example.com/#organization" } }, { "@type": "WebPage", "@id": "https://example.com/pricing#webpage", "url": "https://example.com/pricing", "name": "定價方案", "isPartOf": { "@id": "https://example.com/#website" }, "about": { "@id": "https://example.com/#organization" } } ] }
最常見的四個錯誤
- @id 前後不一致：首頁寫 #organization，文章頁的 publisher 卻填成完整網址或漏了井號片段，機器就當成兩家不同公司
- 該用引用的地方塞了完整物件：publisher 裡又整段重寫一次 Organization，同一實體出現兩份、屬性可能互相衝突
- 實體浮空：WebPage 沒有 isPartOf、Article 沒有 publisher，物件雖然合法，卻和主體斷了線
- 拿會變動的網址當 @id：帶追蹤參數或含 session 的網址一旦改變，就多生一個實體，關聯全部重來
讓 AI 信任你的網站，靠的不是標記得多，而是實體之間指得夠清楚。
上線前務必驗證這三件事
貼上去不等於做對。先用 Rich Results Test 或 Schema Markup Validator 貼上整份 @graph，確認語法沒有紅字；接著做多數人略過的一步——把每個被引用的 @id 抓出來，逐一比對它是否真的在同一份 graph 裡被定義過，別指向不存在的識別碼；最後在瀏覽器載入頁面、看 render 後的 HTML，確認 script 真的有輸出，很多 SSR 或 CMS 會在這一步默默掉東西。實體串接是技術 GEO 裡投報率很高的一塊：工時不多，卻直接影響 AI 願不願意把你當成可信來源。若你不確定自家的 Organization、WebSite、WebPage 有沒有真的接上、發布者關係是不是斷的，可以預約 30 分鐘 GEO 診斷，我們會實際抓你 render 後的 HTML，把缺的線一條條指出來。
