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

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

來源：https://www.starbox.work/zh-hant/insights/geo-guide/geo111/（星盒AI 知識中心，更新於 2026-10-03）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

![GEO實體建模上線前：7項自查](/static/img/insights/geo-guide/geo111-2.jpg)

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

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

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

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

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

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

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

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

![GEO實體建模上線前：7項自查](/static/img/insights/geo-guide/geo111-3.jpg)

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

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

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

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

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](https://schema.org/Organization)
- [Schema.org sameAs](https://schema.org/sameAs)
- [Google結構化數據通用指南](https://developers.google.com/search/docs/appearance/structured-data/sd-policies)

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

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

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

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

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

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

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

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

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

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

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

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

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

## 常見問題

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

要。

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

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

不需要。

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

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

不是。

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

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

不算。

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

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

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

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

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

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

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

## 寫在最後

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

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

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

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