GEO實體建模上線前：7項自查

GEO（生成式引擎優化），是指幫助生成式人工智能（AI）搜尋和問答系統更準確地理解公開資訊。本文所説的GEO實體建模，就是把公司、品牌、產品、服務、人物和地點分別記錄下來，再説明它們之間的真實關係。

這裏的“實體”，指能夠被單獨識別的對象。例如，一家公司是一個實體，它旗下的品牌是另一個實體，具體產品、負責人和辦公地點也應分別識別。

實體建模最容易出錯的地方，往往不是代碼，而是基礎事實：

• 公司註冊名和品牌名被混在一起；
• 同一款產品在不同頁面使用了兩個名稱；
• 創始人、負責人和文章作者被寫成同一個角色；
• 公司、品牌、產品之間的所屬關係寫反；
• 網頁代碼裏寫了某項資訊，頁面正文卻找不到對應內容。

如果這些問題沒有解決，繼續增加頁面和資訊項，只會讓錯誤出現在更多地方。

因此，上線前不應急着創建百科詞條，也不應先給網站添加代碼。第一步應當是確認：公開網絡中的公司、品牌、產品、服務和負責人，能不能被穩定識別為不同對象；它們的邊界是否清楚，關係是否正確，關鍵事實是否有據可查。

下面這7項自查，只要有關鍵項沒有通過，就應先修正，再決定是否上線。

一、公司、品牌和產品是否分開記錄

實體建模的第一步，是先區分對象，再記錄關係。

對象	應記錄的資訊	常見混淆
公司	法定全稱、註冊資訊、成立時間、總部、官網	把品牌簡稱當成公司全稱
品牌	中文名、英文名、別名、所屬公司、官方賬號	把公司和品牌寫成同一個對象
產品	正式產品名、型號、版本、所屬品牌、適用對象	把產品系列和單個型號混用
服務	服務名稱、服務範圍、交付對象、提供主體	把服務承諾寫成產品事實
人物	姓名、公開職務、與公司或品牌的關係	把創始人、負責人和作者混為一人
地點	註冊地、總部、辦公地、服務地區	把註冊地址寫成實際辦公地

一家公司可以維護多個品牌，一個品牌也可以包含多個產品。即使名稱相近，也不能直接認定為同一個對象。

反過來，同一對象可能同時存在簡稱、英文名和歷史名稱。這些名稱不應被拆成互不相關的多個實體，而應作為別名，統一關聯到同一個對象。

這一項主要檢查兩個問題：

• 應該分開的對象，是否已經分別記錄；
• 屬於同一對象的不同名稱和資訊，是否已經正確關聯。

二、每個核心實體是否都有事實主檔

每個核心實體都應建立一份持續維護的“事實主檔”。它不是對外宣傳文案，而是內部統一事實、檢查衝突和追溯來源的記錄。

一份事實主檔至少應包含：

• 主名稱： 當前對外使用的正式名稱；
• 法定名稱： 需要時單獨記錄，不與品牌名混寫；
• 別名： 常用簡稱、歷史名稱、英文名和常見拼寫；
• 唯一入口： 正式官網或長期穩定的主體頁面；
• 核心描述： 這個對象做什麼、不做什麼、面向誰；
• 關鍵關係： 它與公司、品牌、產品、人物和地點分別是什麼關係；
• 事實證據： 支持相關資訊的公開網址或正式文件；
• 當前狀態： 有效、待確認或已停用；
• 維護資訊： 負責人和最近一次複核日期。

“領先”“專業”“值得信賴”等宣傳用語，既不能證明對象身份，也不能幫助核對關係，不適合寫入事實主檔。

判斷一份主檔是否合格，可以看它能不能回答六個問題：

1. 叫什麼；
2. 屬於誰；
3. 做什麼；
4. 何時成立；
5. 在哪裏；
6. 證據在哪裏。

其中任何一項説不清，都不應急着把相關資訊同步到官網、平台簡介和網頁代碼中。

三、名稱、別名和身份標識是否統一

名稱不統一，是實體識別中最常見的問題之一。

這裏所説的“身份標識”，是指能夠幫助外部判斷“它到底是誰”的固定資訊，例如正式名稱、官網地址、產品型號和官方賬號。

上線前，應對照官網首頁、關於我們、產品頁、認證賬號、媒體資料和網頁代碼，逐項檢查：

1. 公司全稱是否每個字符都一致；
2. 品牌中文名和英文名是否採用固定寫法；
3. 簡稱是否明確歸在對應的主名稱下面；
4. 舊名稱是否標註停用時間和替代名稱；
5. 產品型號中的空格、連字符和字母大小寫是否統一；
6. 官方網址是否統一使用正式域名和規範地址；
7. 聯繫方式、所在地和公開負責人是否存在衝突。

需要統一的是事實，不是文案。

不同平台可以根據篇幅限制，使用長短不同的介紹。但是，公司名、品牌名、產品名、所屬關係、產品範圍和關鍵時間，不能隨着文案長短而變化。

表達方式可以不同，指向的對象和事實必須一致。

四、實體之間的關係方向是否正確

實體建模不僅要説明“有哪些對象”，還要説清楚“這些對象之間是什麼關係”。

至少需要核對：

• 公司維護哪個品牌；
• 品牌包含哪些產品或服務；
• 產品由誰提供，適合什麼對象；
• 人物在公司中擔任什麼公開職務；
• 分公司、子公司和母公司分別是什麼關係；
• 證書、獎項和案例屬於公司、品牌，還是某個具體產品。

檢查時需要特別注意：“相關”不等於“屬於”。

合作伙伴不是子公司，經銷商不是品牌所有者，創始人也不等於每篇文章的作者。證書如果頒發給公司，也不能直接寫成某個產品獲得了該證書。

關係一旦寫錯，官網正文、平台簡介、網頁代碼和後續內容都可能繼續使用同一項錯誤資訊。因此，先保證關係正確，再考慮增加關係數量。

五、每條關鍵事實是否都有證據

關鍵事實不能只靠內部習慣或口頭説法確認。每一條關鍵事實，都應能夠追溯到至少一個可以訪問的來源。

證據可以包括：

• 官網正式頁面；
• 政府或行業公開資訊；
• 可以驗證的證書；
• 正式產品文檔；
• 獨立媒體報道。

核驗證據時，需要回答四個問題：

• 這個來源是否確實支持當前這句話；
• 來源描述的對象是否就是當前實體；
• 頁面能否公開訪問，是否標註日期或版本；
• 來源失效後，是否有備用證據或明確的責任人。

有連結，不等於有證據。連結中的內容必須能夠直接支持對應事實，而且説的是同一個對象。

同一家公司批量發佈的宣傳文章，不能互相作為獨立證明。也不能為了填滿資料，編造評價、獎項、成立時間或產品參數。

暫時找不到證據的事實，應標記為“待確認”，不能直接寫成公開結論。

六、頁面正文與結構化數據是否一致

結構化數據，是按照固定格式寫入網頁、用於描述頁面主體的一組資訊。它可以幫助搜尋系統識別頁面講的是哪家公司、哪個品牌或哪款產品。

Schema.org是一套用於描述網頁對象和屬性的公開規則。網站可以用其中的Organization表示組織，用Product表示具體產品。類型和資訊項應根據頁面實際內容選擇，並不是類型越多、資訊填得越滿越好。

Schema.org的Organization頁面列出了多項可用屬性，包括：

• legalName：法定名稱；
• url：官方網址；
• logo：標誌圖片；
• founder：創始人；
• foundingDate：成立日期；
• brand：所屬或維護的品牌；
• contactPoint：公開聯繫方式。

sameAs也是其中一個屬性，用於連結能夠明確標識同一對象的公開頁面。它不是“相關連結合集”。合作伙伴頁面、普通新聞稿和無關主頁，即使提到了該品牌，也不能因此直接作為sameAs使用。

JSON-LD是一種把結構化數據寫入網頁的代碼格式。檢查JSON-LD時，不能只看代碼格式是否正確，還要確認其中的資訊與頁面正文一致。

上線前，應同時檢查以下五個層面：

檢查層	檢查內容	通過標準
頁面正文	名稱、描述、人物、產品、地址是否可見	用戶能在頁面中找到對應事實
JSON-LD	類型和資訊項是否匹配當前對象	內容與正文一致，沒有隻寫在代碼裏的隱藏事實
sameAs	每個連結是否指向同一實體的公開頁面	不是合作方、新聞稿或無關主頁
產品頁	Product描述的是否為當前具體產品	名稱、型號、品牌與頁面一致
校驗工具	是否存在代碼格式或資訊項錯誤	錯誤已修復，警告有處理記錄

Google的結構化數據通用指南明確要求，標記內容應真實代表頁面主體，並與用戶可見內容一致。該指南也説明，代碼格式正確，並不保證搜尋結果一定出現額外展示。

因此，校驗通過只能説明技術檢查完成了一部分。它不能證明實體事實正確，也不能保證任何AI平台一定收錄、引用或推薦。

官方核驗入口：

• Schema.org Organization
• Schema.org sameAs
• Google結構化數據通用指南

七、跨平台結果是否可以複核

完成內部檢查後，還要觀察不同公開平台對相關實體的識別結果是否基本一致。

可以準備一組固定問題，分別測試：

• 這家公司的法定名稱是什麼；
• 這個品牌屬於哪家公司；
• 主要產品或服務有哪些；
• 創始人或公開負責人是誰；
• 總部、成立時間和官方入口是什麼；
• 某個產品與品牌、公司分別是什麼關係。

每次測試，都應記錄提問原文、測試平台、日期、回答內容、引用網址和錯誤類型。結果至少可以分為四類：

• 正確： 對象、事實和關係均無明顯錯誤；
• 缺失： 沒有找到對應資訊；
• 混淆： 把不同公司、品牌、產品或人物寫成同一個對象；
• 過期： 仍在使用已經變更的名稱、職務、地址或產品資訊。

發現問題後，不要只修改測試問題。應回到事實主檔查找原因：

• 主檔是否缺少記錄；
• 官網不同頁面是否互相沖突；
• 第三方頁面是否已經過期；
• 結構化數據中的關係方向是否寫反；
• 平台是否還沒有取得更新後的資訊。

一次回答正確，不能證明結果會長期穩定。只要名稱、產品、負責人或公開頁面發生變化，就需要重新複核。

出現這些問題，應暫停上線

如果出現以下任一情況，而且尚未解決，就不適合直接上線：

• 公司、品牌或產品的邊界尚未確定；
• 同一名稱在主要頁面存在兩種寫法，卻沒有別名説明；
• 所屬關係、人物職務或產品歸屬互相沖突；
• 關鍵事實沒有來源，或來源説的是另一個對象；
• 結構化數據包含頁面正文中看不到、也無法證明的內容；
• sameAs連結指向的不是同一實體；
• 沒有記錄負責人、版本和複核日期。

暫停上線，是為了先把已經發現的問題處理完。錯誤一旦進入多個頁面和平台，後續排查時就更難確認它最初來自哪裏。

常見問題

1. 公司名和品牌名一樣，還要分開記錄嗎？

要。

兩者可以同名，但公司是法律主體，品牌是對外使用的市場身份，兩者承擔的關係不同。分開記錄後，再説明它們當前同名並建立所屬關係，後續的產品、證書和賬號才不容易關聯到錯誤對象。

2. 所有平台的簡介必須一字不差嗎？

不需要。

不同平台可以使用長短不同的介紹，但公司名、品牌名、產品名、所屬關係和成立時間等事實應保持一致。文案可以調整，事實不能隨意改變。

3. sameAs連結是不是越多越好？

不是。

每個連結都應能夠明確標識同一個實體。合作伙伴頁面、普通新聞稿、無關欄目和無法確認歸屬的賬號，不應為了增加數量而加入。

4. Schema校驗通過，就算實體建模完成了嗎？

不算。

Schema校驗主要檢查結構化數據的代碼格式和資訊項。除此之外，還要檢查對象邊界、關係方向、頁面可見事實、事實證據和跨平台一致性。

5. 沒有第三方來源怎麼辦？

先完善官網事實主檔和能夠驗證的資料，再逐步獲得真實的獨立來源。

不能自行偽裝第三方評價，也不能創建缺乏獨立依據的百科內容。暫時無法核驗的資訊，應保留“待確認”狀態。

6. 事實主檔多久更新一次？

公司更名、產品改版、負責人變化、地址或聯繫方式變化時，應立即更新；平時按固定週期複核。

每次修改都應保留日期、負責人和舊值，以便後續確認相關資訊在什麼時間發生了變化。

寫在最後

GEO實體建模自查，不是檢查資訊有沒有填滿，而是確認四件事：

• 核心對象沒有混淆；
• 關係方向沒有寫錯；
• 關鍵事實能夠找到證據；
• 每次修改都可以追溯。

這7項全部通過，也不能保證任何平台一定收錄、引用或推薦。但它可以先排除自身能夠發現和修正的問題，讓公開資訊保持清楚、一致、可核驗。

上線之前多核對一次事實，通常比上線之後在多個頁面和平台反覆修改更有效。