海外實體建模：Schema與sameAs八平台實操

GEO，即生成式引擎優化，關注的是品牌資訊能否被 ChatGPT、Perplexity 等生成式引擎準確檢索、識別和引用。海外實體建模要解決的問題，是讓官網與外部平台用一致、可驗證的資訊説明同一家公司、產品和人員，減少 AI 認錯企業、混淆品牌或無法確認資訊的情況。

執行上主要分為三部分：用 Schema 結構化數據説明“我是誰”，用 sameAs 屬性聲明“這些平台賬號屬於同一個實體”，再通過維基百科、維基數據等外部資料增加可交叉驗證的資訊。三部分需要相互一致，任何一處出現名稱、成立時間或業務資訊衝突，都可能影響實體識別。

先看實體建模的主要依據

目前公開研究和行業觀察提供了以下參考：

Geneo 2025 年數據稱，帶結構化數據的頁面被 AI 引用的頻率，是無結構化數據頁面的 8.2 倍。
一項未經第三方核驗的行業口徑顯示，同時部署 Organization 和 FAQPage 兩類 Schema 的頁面，相比無 Schema 頁面，在 Google AI Overviews（Google AI 概覽）中的引用率高 37%。
seoClarity 的實證研究顯示，跨平台實體一致性與 AI 引用的相關係數為 r=0.664，反向連結與 AI 引用的相關係數為 r=0.218。相關係數用於表示兩個變量之間的統計關聯，不能據此認定實體一致性必然帶來引用增長。
Digital Applied 對 Google 2026 年 3 月更新的解讀認為，“可驗證的作者或發佈者實體”屬於較強信號，其中包括 sameAs 指向維基百科、維基數據等資料。該説法是機構解讀，不等同於 Google 公佈的無條件規則。
5W Research 的公開研究顯示，維基百科佔 ChatGPT 前十位引用來源的 47.9%；另一項統計中，維基百科與 Reddit 合計佔美國地區 ChatGPT 引用的 25% 以上。
AmICited 的公開研究顯示，使用 FAQPage Schema 的頁面在 ChatGPT 中的引用提升 320%，進入 Google AI 概覽的概率達到 3.2 倍。這是研究樣本中的觀察結果，不代表所有網站部署後都會獲得同等變化。
行業口徑認為，中國公司的英文維基百科詞條首次通過率約為 30%-50%，完整準備和申請週期通常需要 12-18 個月。該數據未經第三方核驗。

一種行業觀察框架將主流 AI 搜尋的候選內容評估分為五個維度，其中實體一致性的估算權重約為 15%-20%。這一比例同樣未經第三方核驗，只適合用於判斷工作優先級，不能當作平台公開的固定權重。

海外實體建模：Schema與sameAs八平台實操

一、Schema 應該部署哪些類型

Schema.org 是 Google、微軟等搜尋廠商共同維護的結構化數據詞彙表。網站通常使用 JSON-LD，也就是“用 JSON 格式表達關聯數據”的標註方式，把代碼放進網頁中，供搜尋引擎和其他機器讀取。

Schema.org 提供了數百種類型，但出海企業官網常用的主要是以下六種：

Schema 類型	適用頁面	關鍵內容	主要作用
Organization	全站統一配置，通常重點放在首頁和關於頁	公司全稱、logo、地址、成立資訊、sameAs 數組	説明公司的統一身份，減少同名企業混淆
Product	每個產品頁	名稱、描述、aggregateRating、review、offers	説明產品、實際評分、具體評價和報價資訊
FAQPage	帶 FAQ（常見問題）內容的頁面	mainEntity 數組，以及 Question 和 acceptedAnswer	幫助機器識別頁面中的問題和對應答案
Article	博客、新聞或其他內容頁	標題、作者、datePublished、dateModified	説明作者、首次發佈時間和修改時間
BreadcrumbList	全站導航	頁面層級路徑	幫助機器判斷頁面在網站中的位置
HowTo	教程或操作指南頁	按順序排列的 step 數組	説明任務的操作步驟，僅適合教程類內容

基本選型原則是：Organization 和 BreadcrumbList 作為全站配置，Product、FAQPage、Article、HowTo 根據頁面實際內容添加。90 天落地計劃可以把 Schema 部署安排在第二週，並以至少完成 20 個頁面作為階段驗收標準。

Schema 字段怎樣寫才合格

第一，優先使用 JSON-LD 格式。代碼通常放在網頁的 <head> 區域，也就是頁面源代碼中集中存放標題、説明和結構化資訊的位置。這是 Google 官方推薦的格式，WordPress、Webflow、Shopify 等常見建站系統都支持添加自定義代碼。

第二，Organization 中要配置 sameAs 數組。數組裏填寫企業已經建立並持續維護的官方平台主頁網址，讓機器能夠核對官網和各平台資料是否屬於同一家公司。

第三，Product 頁面應配置 aggregateRating（彙總評分）、review（具體評價）和 offers（報價資訊）。這些字段只能標註頁面真實展示的內容，不能填寫不存在的評分、評價或價格。

FAQPage 需要使用 mainEntity 數組。數組中的每一項由 Question（問題）和 acceptedAnswer（被接受的答案）組成。問題應採用用戶真實可能向 AI 提出的長尾問句，通常控制在 10-20 個詞；答案控制在 50-150 個詞，並儘快給出結論。

網頁中訪客能夠看到的 FAQ 內容，必須與代碼中的標註一致。頁面展示一套內容、代碼填寫另一套內容，屬於不實標註，可能受到平台處理。

部署完成後，還要通過兩個免費工具檢查：

Schema.org Validator：檢查代碼語法和字段結構。
Google Rich Results Test：檢查 Google 是否能夠識別相應標註。

只有完成檢查並解決報錯，才算完成這一階段的部署。

海外實體建模：Schema與sameAs八平台實操

二、Schema 在 SEO 和 GEO 中分別解決什麼問題

SEO，即搜尋引擎優化。Schema 在傳統 SEO 中已經使用多年，主要用途是幫助頁面獲得富摘要，也就是搜尋結果中顯示星級、價格、FAQ 摺疊內容等附加資訊。行業公開口徑認為，富摘要可能帶來約 5%-30% 的點擊率提升，具體結果會受關鍵詞、排名位置和頁面類型影響。

Google 在 2026 年 5 月 15 日的官方説明中表示，為生成式 AI 搜尋進行優化，本質上仍然屬於 SEO。Google 同時否定了所謂“AI 專用 Schema 標籤”的必要性。市面上宣傳的“AI 時代專用 Schema”或“AEO（回答引擎優化）Schema 包”，並不是 Google 要求增加的新類型。

企業真正需要部署的，仍然是 Organization、Product、FAQPage、Article、BreadcrumbList 和 HowTo 等通用類型。

GEO 更關注 Schema 對實體識別的幫助。sameAs 與維基數據 QID，也就是維基數據條目的唯一編號，可以幫助機器判斷不同頁面和平台資料是否指向同一家公司。

因此，對 Schema 的合理預期應分成三層：

富摘要是最直接的應用。
減少實體混淆，是 Schema 在 GEO 場景中的重要作用。
“部署 Schema 後就一定會被 AI 引用”沒有充分依據。結構化數據不能代替內容質量、事實完整度和外部資料。

三、sameAs 怎樣連接八個平台

sameAs 是 Organization Schema 中的一個屬性，用來列出企業在其他平台上的官方主頁網址。

機器讀取這些網址後，可以繼續核對各平台資料。如果官網、LinkedIn、Crunchbase、GitHub 等頁面使用相同的公司全稱，並且成立時間、業務類別、地址等資訊能夠相互對應，機器就更容易判斷這些資料屬於同一個實體。

連接平台以前，先要統一公司名稱。海外平台應採用同一個英文註冊全稱，包括大小寫、空格以及 Inc. 等公司制後綴。執行時可以把“全平台名稱逐字符一致”設為第一項檢查標準。

行業常用做法是從以下十個平台中選擇至少八個：維基百科、維基數據、LinkedIn、Crunchbase、X、YouTube、GitHub、G2、Trustpilot 和 Facebook。

平台	在實體識別中的作用	中國團隊面臨的門檻	起步週期
維基百科	提供公開詞條和第三方資料，權威性較高	極高	6-18 個月
維基數據	提供結構化條目和 QID	低於維基百科，可按社區規則填報	較短
LinkedIn	提供公司及高管檔案	中等；2023 年 8 月退出中國大陸，公司主頁需要海外主體，個人賬號需要海外手機號	2-4 周
Crunchbase	提供公司、融資和團隊資料	較低，以自助填報為主	—
YouTube	提供影片內容及官方賬號資訊	中等；Otterly 2026 年口徑稱，長影片在 AI 引用的影片內容中佔 94%	4-8 周
GitHub	提供技術型公司的代碼和組織檔案	較低	較短
G2 / Trustpilot	提供第三方評價	中等；不要使用 `.cn` 郵箱註冊管理員，否則可能觸發人工審核	2-6 周
X / Facebook	用於確認官方社交賬號	中等	—

執行順序可以按照門檻安排：第一週先完成維基數據、Crunchbase、GitHub 等可填報平台；隨後處理 LinkedIn、YouTube、G2 等需要持續運營的平台；維基百科放在後期準備。

sameAs 數組可以隨着平台檔案的完成逐步更新，不必等到八個平台全部建好以後再上線。數量達到八個只是行業執行標準，資料真實、名稱統一和資訊一致比單純增加連結數量更重要。

四、維基百科和維基數據為什麼重要

5W Research 的公開研究顯示，維基百科佔 ChatGPT 前十位引用來源的 47.9%。另一項美國地區統計中，維基百科與 Reddit 合計佔 ChatGPT 引用的 25% 以上。

維基百科和維基數據中的內容還可能被納入大模型訓練資料。因此，合規、穩定的詞條資訊不僅可能影響實時檢索，也可能在約 18 個月後的模型版本中影響 AI 對企業的預設認知。這裏描述的是可能性，不是固定的模型更新時間。

對中國公司來説，英文維基百科通常是實體建模中週期最長的部分。常見拒稿原因主要有三類：

引用來源全部來自企業新聞稿或自有渠道。
詞條使用明顯的宣傳語言。
缺少來自非西方獨立媒體的多篇報道。

可行的準備方式，是先用約 12 個月積累 3-5 篇獨立媒體報道。這些報道應由記者主動採寫，而不是企業購買的付費稿。資料達到要求後，再通過 AfC，也就是 Articles for Creation（條目創建）草稿審核通道提交。審核通常需要 4-12 周，首次通過率約為 30%-50%。週期和通過率均為未經第三方核驗的行業口徑。

還要注意兩項規則。

第一，不要由企業自行註冊賬號編寫自家詞條。維基百科的 WP:PAID，也就是有償編輯披露規則，要求相關人員公開利益關係。違反規則可能導致詞條被標註或刪除。

第二，可以先按社區規則建立維基數據條目。維基數據允許結構化填寫公司名稱、成立年份、官網和類別。條目建立後會獲得唯一的 QID，把對應網址加入 sameAs，可以先用於實體區分，不必等待維基百科詞條通過。

五、怎樣驗證 AI 是否準確識別企業

完成部署後，不要只看代碼是否上線，還要直接檢查 AI 的回答。行業常用方法是每月運行一次“實體存在度矩陣”：在 ChatGPT、Perplexity、Gemini、Claude 四個引擎中，分別提出以下五個問題。

英文問題	檢查內容
Tell me what you know about [公司英文全稱]	AI 能否識別企業，並準確概括基本情況
Who is the founder or CEO?	能否説出創始人或首席執行官（CEO）
When was it founded?	能否説出成立時間
Is it a reliable supplier?	能否找到並引用與供應商可靠性相關的資料
What products does it make?	能否準確説明產品和業務類別

基本驗收標準是：AI 能準確説出企業的成立年份、產品類別和規模，並且沒有與同名公司混淆。如果回答錯誤、缺失或把兩家公司合併在一起，應依次檢查官網事實頁、Schema 和各平台檔案，確認名稱、成立時間、地址、產品資訊是否存在衝突。

每次測試都要保存四個引擎的完整回答，按月比較。Profound 的監測數據顯示，同一問題的 AI 答案在 70% 的時間裏會發生變化。因此，單次回答不能代表長期結果，應觀察多次測試中的變化趨勢。

上線前的十項檢查

公司英文全稱在所有海外平台逐字符一致。
Organization Schema 已完成部署，sameAs 中包含至少八個平台。
產品頁已經配置真實的 aggregateRating、review 和 offers 字段。
FAQ 頁面可見內容與 FAQPage 標註完全一致。
Article 頁面已經正確填寫 dateModified，也就是最近修改時間。
官網已經建立公司事實頁，集中説明成立年份、地址、產品類別和規模。
維基數據條目已經建立，並記錄對應 QID。
正在積累獨立媒體報道，達到 3-5 篇後再申請英文維基百科詞條。
Schema.org Validator 和 Google Rich Results Test 已經通過，且沒有未處理的報錯。
實體存在度矩陣已經加入每月檢查日程。

FAQ：Schema 和 sameAs 的常見問題

1. 沒有技術人員，可以自己部署 Schema 嗎？

可以。JSON-LD 是一段放入網頁 <head> 區域的代碼，Organization、Product、FAQPage、HowTo 等常用類型都有公開範例可供對照。WordPress、Webflow、Shopify 等建站系統也支持添加自定義代碼。

修改完成後，使用 Schema.org Validator 和 Google Rich Results Test 檢查。行業執行經驗認為，單個網站通常可以在一週內完成基礎部署，但實際週期仍取決於頁面數量和建站系統權限。

2. sameAs 是不是連接得越多越好？

不是。至少連接八個權威平台是行業常用標準，但一致性比數量更重要。

seoClarity 的數據支持的是跨平台實體一致性與 AI 引用存在較強相關性，相關係數為 r=0.664。它並不説明連結數量本身會帶來引用。連接 20 個資料不完整、長期不更新或資訊互相矛盾的賬號，反而會增加實體識別衝突。先把八個平台的資料維護準確，再考慮增加其他平台。

3. 暫時無法建立英文維基百科詞條怎麼辦？

分兩步處理。

短期先按社區規則建立維基數據條目，獲取 QID，並把條目網址加入 sameAs。長期用 12-18 個月積累 3-5 篇獨立媒體報道，再通過 AfC 草稿審核通道申請英文維基百科詞條。

首次通過率約為 30%-50%，屬於未經第三方核驗的行業口徑。企業不要自行編寫自家詞條，否則可能因違反 WP:PAID 披露規則而被標註或刪除。

4. Schema 部署後多久能看到變化？

需要分開判斷。

在富摘要方面，Google 重新抓取頁面並識別標註後，就可能開始展示，通常以周為觀察單位。

在實體認知方面，所需時間通常更長。行業公開案例中，GEO 整體最快約 6 周出現變化，90 天出現較明顯變化較為常見，3-6 個月可以作為合理觀察週期。這些都是行業案例中的時間範圍，不是固定承諾。

建議在部署當月就運行實體存在度矩陣並保存初始結果，之後逐月比較。

5. llms.txt 這類“AI 專用文件”需要一起做嗎？

不應列為重點。llms.txt 是網站主動提供給大模型或 AI 爬蟲的文本説明文件。Google 在 2026 年 5 月的官方説明中表示，不需要專門為 AI 增加這類文本文件。

SE Ranking 對 30 萬個域名的審計還顯示，主流 AI 爬蟲對 llms.txt 的抓取次數為零。企業可以把它視為低成本的兼容性嘗試，但不應為此支付較高的單獨配置費用。

6. 公司同時有中文名和英文名，會不會破壞一致性？

不會，但要分開管理。

海外實體體系統一使用英文註冊全稱，各英文平台保持逐字符一致。中文名稱用於國內平台和中文實體資料。

真正會增加識別難度的，是同一語種內同時存在多個寫法，例如英文名稱有時帶 Inc.、有時不帶，或者大小寫和空格長期混用。

7. AI 已經説錯公司資訊，應該怎樣糾正？

先運行實體存在度矩陣，確認錯誤出現在哪些引擎、涉及哪些資訊。然後檢查官網事實頁、Schema 標註和八個平台檔案，找出過時、缺失或互相沖突的內容，逐項修改，並更新 Article 中的 dateModified。

AI 回答會隨着檢索資料更新而逐步變化。由於同一問題的答案本身可能波動，糾正結果應通過每月複測判斷，不能只看一次回答。

完成以上工作，海外實體建模就具備了可檢查、可複測的執行體系。下一篇將討論國內做法：把主要外部參照調整為百度百科、搜狗百科，並統一公眾號、百家號和抖音號等平台的品牌名稱與企業資料。國內外的目標相同，使用的平台和具體執行方式不同。