GEO 實體關聯設定教學：用結構化資料讓 AI 看懂服務與人物

TL;DR

• 實體關聯（把網站上的服務、人物、文章用 ID 互相連起來）讓搜尋引擎與 AI 確定這些內容指的是同一個對象，也知道彼此的關係
• AHHA 的做法是先建立「服務項目」與「人物」兩組內容，再在「欄位與關聯」加上負責人、相關服務等欄位
• 文章可以標示主題與審閱人，兩者會同時出現在頁面上與結構化資料中
• 審閱人只能填實際審閱過內容的人，這是對外的事實宣告，而不是 SEO 技巧
• 設定完成後，可以在頁面原始碼的 JSON-LD 中確認每一條關聯是否正確輸出

一家顧問公司的網站上，通常會有服務介紹、團隊成員與專欄文章。對讀者來說，這三者的關係並不難理解：這篇文章在談某項服務，而這項服務由某位顧問負責。搜尋引擎與 AI 的處理方式則不同，如果頁面之間只有文字上的提及，它們看到的是三份各自獨立的內容，無法確定文章裡提到的「年度顧問」與服務頁上的「年度顧問」是同一項服務，更無法得知兩者之間的關係。

實體關聯處理的正是這個落差。本文以 AHHA 後台的操作為例，依序說明服務與人物的建立、欄位與關聯的設定、文章的主題與審閱人，以及設定完成後的檢查方式。

實體關聯與 GEO 的關係

實體（entity）指的是一個可以被明確辨識的對象，例如一家公司、一位醫師、一項服務或一篇研究。搜尋引擎與 AI 在理解網站時，會嘗試把頁面上的文字對應到這些實體，並建立它們之間的關係；Google 的知識圖譜（Knowledge Graph）就是這類關係的集合。GEO（生成式引擎最佳化，讓內容更容易被 ChatGPT、Gemini、Google AI 摘要等生成式搜尋理解與引用）之所以重視實體，是因為 AI 在組合答案時需要判斷「誰提供什麼」「這個說法出自誰」，而這些判斷都建立在實體與關係之上。

網站能主動提供這層資訊的方式是結構化資料（寫在頁面原始碼中、給機器讀的標記，通常採用 JSON-LD 格式），常見的結構化資料類型可參考商家網站最該做的 5 種結構化資料。在結構化資料中，每個實體可以有一個固定的 @id，其他頁面提到它時只需引用這個 ID，而不必重新描述一次。以本文的示範為例，一篇文章的結構化資料會寫成：

{
  "@type": "Article",
  "about": { "@id": "https://example.com/consultant/seo-geo-annual#item" },
  "mainEntityOfPage": {
    "@type": "WebPage",
    "reviewedBy": { "@id": "https://example.com/team/howshin-wang#item" }
  }
}

這段標記表示文章的主題是「SEO / GEO 年度顧問」這項服務，並由一位顧問審閱，而服務與顧問各自的完整資料只寫在它們自己的頁面上。AHHA 在後台設定關聯後，會自動產生這類標記，同時在頁面上輸出對應的連結，因此不需要手動撰寫任何程式碼；網站其他自動輸出的結構層，例如 llms.txt 與 hreflang，可參考網站怎麼被 AI 讀懂：Schema、llms.txt、hreflang。

實體關聯的內容規劃：服務、人物與文章

AHHA 的「作品・案例・物件」模組以「一組」為單位管理內容。每一組會有自己的列表頁，例如 /consultant，而組內的每個項目會有獨立的內頁，例如 /consultant/seo-geo-annual。實體關聯的設定建立在這個結構上，因此在開始設定之前，需要先決定哪些內容要成為可被引用的實體。

以顧問公司為例，規劃通常包含三類內容。服務放在一組類型為「服務項目」的內容中，每項服務一個內頁；顧問或團隊成員放在另一組類型為「人物」的內容中，每位成員一個內頁；文章則維持在部落格，透過文章的設定連到服務與人物。服務也可以不放在組內，而是各自寫成一個頁面，這種情況的設定方式在後文另外說明。

步驟一：建立服務項目與人物兩組內容

進入後台左側選單的「作品・案例・物件」，按右上角的「+ 新增一組」，填入名稱與網址，並在「這一組是什麼」選擇「服務項目」。建立完成後，以同樣方式再新增一組人物，名稱可以是「顧問團隊」或「醫師團隊」，網址例如 team，並在「這一組是什麼」選擇「人物（醫師、講師、團隊成員）」。

「這一組是什麼」決定了每個項目在結構化資料中的類型：服務項目會輸出為 Service，人物會輸出為 Person。這個選擇會影響後續能設定的欄位，例如只有類型為人物的組，其中的成員才能被文章選為審閱人。已建立的組可以透過「編輯這一組」修改類型。

接著在兩組中分別按「+ 新增項目」，填入服務名稱與介紹，以及顧問的姓名與簡介，並將狀態設為「已發布」。草稿狀態的項目不會出現在網站上，也無法在前台被引用。

步驟二：在「欄位與關聯」加上負責人與相關服務

選到服務項目那一組，點選「欄位與關聯」，面板上方會列出常用範本。點選「+ 負責人／講師」，系統會自動加入一個指向人物組的關聯欄位；如需補充說明，也可以用「+ 自訂欄位」加入文字欄位，例如「適合對象」。確認後按「儲存欄位」。

欄位列上的「指向」決定這個欄位可以選哪些內容；「結構化資料」決定關聯輸出成哪一種屬性，範本會依這一組的類型自動挑選合適的屬性，例如服務的負責人會輸出為 provider（提供者）；「顯示在內頁上」則決定訪客是否看得到這個欄位。只想提供給搜尋引擎、不需要出現在頁面上的資訊，可以取消勾選。

作品或案例組也可以用同樣的方式加上「相關服務」欄位。這個範本同時接受兩種服務來源：服務項目組裡的項目，以及被設為一項服務的頁面，因此無論服務以哪一種形式存在，都能被選到。

步驟三：在項目中選擇關聯對象

欄位儲存後，在服務項目的清單中對任一項服務按「編輯」，表單中會出現剛才加入的「負責人」欄位。從下拉選單選擇對應的顧問並儲存，前台的服務內頁就會在規格表下方列出「負責人：〇〇〇」，並連到該顧問的個人內頁。

下拉選單中以灰色顯示的選項代表目前無法引用，選項後方會註明原因，例如頁面尚未設為一項服務。被其他內容引用的項目在刪除時，系統會先列出正在引用它的文章與項目，確認後才會刪除，以避免關聯在不知情的情況下中斷。

步驟四：文章的主題與審閱人設定

在部落格打開一篇文章，展開作者欄位下方的「進階：內容關聯」，會看到「文章主題」與「審閱」兩個欄位。文章主題可以選擇任何一組中的項目，或設為一項服務的頁面；審閱只能選擇人物組中的成員。儲存後，文章頁的日期旁會顯示「審閱 〇〇〇」，內文結尾會列出「文章主題：〇〇〇」，兩者都連到對應的內頁。

在結構化資料中，文章主題輸出為 Article 的 about 屬性，審閱人則輸出在頁面節點的 reviewedBy 屬性，因為 Schema.org 將 reviewedBy 定義為 WebPage 的屬性，而不是文章本身的屬性。

服務寫成單一頁面時的設定

部分網站的服務是以一般頁面呈現，例如每項服務各有一頁完整的介紹。這種情況不需要把服務搬進組內，只要在「頁面編輯」中選擇該頁，展開 SEO 設定，將「這一頁是」設為「一項服務」或「一門課程」即可。設定後，該頁會輸出一個 Service 或 Course 類型的實體，並標示由網站本身提供，文章與作品就能在「文章主題」與「相關服務」中選到這一頁。

這個設定與預約系統的「預約項目」無關，只影響結構化資料與關聯選單，不會改變頁面的版面。

前台呈現與結構化資料的檢查方式

設定完成後，先從訪客看到的內容確認：服務內頁應顯示負責人連結，文章頁應顯示審閱人與文章主題，而且點擊後能正確進到對應的內頁。接著確認結構化資料，在瀏覽器中檢視頁面原始碼並搜尋 application/ld+json，檢查關聯屬性中的 @id 是否指向正確的網址。若想看到完整的解析結果，可以把網址貼到 Schema Markup Validator，它會列出頁面上所有的實體與關係；Google 的複合式搜尋結果測試只顯示可產生特殊搜尋結果的類型，Service 與 Person 通常不會出現在那份報告中，因此不適合拿來檢查這項設定。

多語系網站的 @id 不帶語言前綴，中文頁與英文頁指向的是同一個實體，這是為了讓不同語言的頁面在搜尋引擎眼中收斂到同一組服務與人物，並非設定錯誤。

審閱人、作者與 E-E-A-T 的設定原則

審閱人與作者屬於人物關係，會以文字顯示在文章頁上，也會以結構化資料對外宣告「此人撰寫或審閱了這份內容」。Google 在內容品質的說明文件中說明，E-E-A-T（經驗、專業、權威與可信度，也常寫作 EEAT）本身不是單一的排名因子，但對於可能影響健康、財務或安全的主題，系統會更重視符合 E-E-A-T 的內容，而內容由誰撰寫、由誰負責，正是讀者與系統判斷這些條件的線索。醫療、法律、財務類網站的審閱人欄位因此較有價值，但前提是資訊屬實。只有在該成員確實審閱過文章時才應填寫審閱人；文章由公司撰寫、沒有具名作者時，可以在「網站設定」的內容作者區塊，勾選「沒填作者的文章，作者標示為本站」，讓作者如實標示為公司本身。

實體關聯能讓搜尋引擎與 AI 更確定網站上提到的服務與人物是誰、彼此有什麼關係，但無法保證排名提升，也無法保證內容一定會被 AI 引用。內容本身是否回答了使用者的問題，以及網站以外是否有其他可信來源提及這家公司與這些人物，對能否被引用的影響更為直接；實體關聯是讓這些條件被正確解讀的基礎，而不是替代品。