自己說的不算數：
hasCredential 與第三方驗證，AI 信任品牌的分水嶺

一句話結論：schema.org 的 hasCredential 能把「我有認證」變成機器可解析的結構化資料——但任何人都能在自家 JSON-LD 裡寫任何認證，所以「自報」本身只是宣稱。真正把宣稱變成事實的，是一個掛在發證方網域上、免登入、可即時查核、撤銷會反映的第三方驗證頁。這篇教你把兩者的差距補起來。

先做一個小實驗。打開任何一個網站的原始碼，找到 <script type="application/ld+json"> 區塊——裡面寫的每一個字，都是那個網站的擁有者自己放的。包括「本公司通過某某認證」「榮獲某某獎項」。沒有任何技術機制在你按下存檔之前檢查這些話是不是真的。這就是本文要處理的核心問題：當「自我宣稱」的成本趨近於零，AI 與搜尋引擎在決定信任誰的時候，靠什麼分辨？

1. 一句話答案：宣稱與事實的差別，在「可不可以回查」

差別不在你寫了什麼，而在別人能不能查。自報的 schema 是孤證：來源與宣稱者是同一人。第三方可驗證的背書是交叉證據：發證方（另一個可查證的實體）在它自己的網域上，用一個任何人打得開的頁面，替你的身分與資格作證。對做交叉驗證的系統來說，這是兩個完全不同等級的訊號。

這個原則其實不是 AI 時代的新發明。Google 的品質評分框架一貫的立場就是：權威與可信要靠「別人怎麼說你」——站外的獨立聲譽——而不是你在自己頁面上的宣告^[3]。Google Search Liaison 甚至直白說過，作者掛名本身不會幫你排得更好^[4]。AI 答案引擎在挑選引用來源時面對同樣的問題：滿網路都是自稱專家的頁面，它需要的是可回查的證據鏈，而不是更大聲的自我介紹。

2. hasCredential 是什麼：把「有認證」變成機器讀得懂的一句話

hasCredential 是 schema.org 定義在 Person 與 Organization 上的屬性，值是一個 EducationalOccupationalCredential（教育／職業資格憑證），可以描述認證名稱、類別，以及最關鍵的 recognizedBy——這個認證由誰承認、誰發出^[1][2]。

一段最小可用的寫法長這樣：

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "某某有限公司",
  "url": "https://example.com",
  "hasCredential": {
    "@type": "EducationalOccupationalCredential",
    "name": "某某夥伴認證",
    "credentialCategory": "certification",
    "recognizedBy": {
      "@type": "Organization",
      "name": "發證機構名稱",
      "url": "https://issuer.example"
    }
  }
}

它的價值在於消歧與可解析：一句藏在「關於我們」內文深處的「本公司通過認證」，機器要靠猜；一個結構化的 hasCredential，機器可以直接讀出「誰、持有什麼認證、由誰發出」。這是把認證事實接進知識圖譜的正確語法。

3. 殘酷的事實：自報 schema 五分鐘就能偽造

上面那段 JSON-LD，任何人複製貼上、把名稱換掉，五分鐘就能讓自己「持有」任何認證。沒有簽章、沒有查核、沒有守門員。這不是 schema.org 的缺陷——它本來就只是描述語法，不是驗證機制。缺陷出在把「寫了」當成「證明了」。

這件事的推論很直接：如果自報的 schema 就能建立信任，那信任早就通膨到一文不值了。實際上，會做交叉驗證的系統（無論是 Google 的評分機制，還是挑選引用來源的 AI 引擎）必須把「只有宣稱者自己說」的資訊打折看待。你可以把 award、認證、會員資格寫滿整個 JSON-LD，但當這些宣稱在網路上任何其他地方都找不到對應——發證方查無此頁、名稱對不上、機構本身查無實體——它們就只是雜訊。

自報 schema：「我持有某某認證。」——來源＝宣稱者本人，成本五分鐘，可信度打折。

第三方可驗證背書：「發證方在它自己的網域上有一頁寫著：我們審核過這家公司，證書目前有效，你可以隨時來查。」——來源＝獨立實體，可回查、可撤銷、可交叉比對。

所以正確的問題不是「我的 schema 寫得夠不夠漂亮」，而是：「當有人拿著我的宣稱去查證，他查得到嗎？」

4. 分水嶺三要件：發證方、被證方、可公開查核的 URL

把「宣稱」升級成「可驗證背書」，需要三個要件同時成立：發證方明確且自身可查、被證方明確且對得上、驗證端點公開且反映即時狀態。缺任何一個，證據鏈就斷。

注意第三個要件裡最容易被忽略的細節：撤銷要能反映。一個永遠顯示「有效」的驗證頁，跟沒有驗證頁差不多——它證明的只是「曾經發過」，不是「現在仍然有效」。可信的驗證端點必須讀取即時的審核狀態：發證方今天撤銷，頁面今天就要變。

把三要件接回 schema：你的 hasCredential 裡的 recognizedBy 應該指向發證方的真實 URL；發證方的驗證頁反過來寫明被證方是你。兩端互指、名稱對得上，交叉驗證才走得通。這跟我們在〈為什麼經過認證的品牌更容易被 AI 引用〉裡講的方向一致：AI 引用集中在「認得出、對得上、信得過」的實體。

5. 一個可信的驗證頁該長什麼樣（含反例）

驗證頁的本質是「發證方對外開放的查核窗口」。它要讓一個第一次到訪的陌生人（或一隻不執行 JavaScript 的爬蟲）在一頁之內確認：誰發的證、證給誰、什麼等級、現在是否有效。

常見反例：把一張「認證徽章」圖片放在自家官網 footer，點下去沒有任何連結，或連到發證方首頁（而不是針對你這張證書的驗證頁）。這種做法三要件全缺：查核的人找不到發證方對你的具體背書、對不上被證方、更查不到即時狀態。徽章本身不是問題——沒有可回查的端點才是問題。

6. 我們自己的做法：公開查驗中心與 3 家認證企業（誠實版）

我們把自己的認證系統照上面三要件蓋。發證方是誠通數位 TrueLink（登記法人：誠通智匯有限公司）；查驗窗口免登入、唯讀、公開；憑證資料由真實審核狀態產生，不是企業自報。

具體做法，讀者可以現在就打開查證：

• 公開查驗中心（/verify/）——免登入、唯讀，任何人可查驗憑證的真實性與有效狀態。
• 認證名錄（/directory/）——列出通過 KYC 實名審核的認證企業，每一筆對應真實的審核紀錄。
• hasCredential 由審核狀態產生——認證企業的 hasCredential 憑證資料是從我們的真實審核結果（審核等級、審核時間）建出來的，發證方欄位寫的是 TrueLink，不是企業自己填的；認證一旦撤銷，就不再顯示為有效。

這也是為什麼我們把「發證方自身可查」看得很重：TrueLink 自己的組織資訊、統編、sameAs 全部公開對得上。第三方背書的份量，最終取決於第三方自己的可查證程度——一個查無實體的發證方，發再多證都是零。

7. 今天就能做的三步