GEO 結構化資料的重點不是每頁塞滿 Schema，而是讓同一位作者、同一家公司與每篇文章保持一致關係。我在自己的網站為 Claire Chang 與允愛數位科技建立固定 @id，文章只引用既有實體，避免每一頁產生一個新的同名作者。
結構化資料對 GEO 有什麼幫助？
結構化資料使用標準詞彙描述頁面類型、作者、發布者、日期與主題，協助搜尋引擎降低理解歧義。結構化資料不能取代正文、來源與專業經驗，也不能保證取得複合式搜尋結果或 AI 引用。
Google 說明，結構化資料是描述頁面資訊並分類頁面內容的標準格式；標記應放在其所描述的頁面，而且不得加入頁面上不存在或讀者看不到的內容。Google 結構化資料介紹
Article、Person 與 Organization 如何分工？
Article 描述單篇文章，Person 描述作者，Organization 描述品牌或發布單位。Article 應透過 author 與 publisher 連到既有 Person 和 Organization，而不是把作者及公司只寫成無關聯的文字。
| 實體 | 代表內容 | 適合的主要頁面 |
|---|---|---|
Article | 一篇文章 | 每篇文章頁 |
Person | 作者本人 | 關於作者或個人資料頁 |
Organization | 公司或品牌 | 首頁或公司介紹頁 |
ProfilePage | 以人物或組織為主體的頁面 | 作者頁、個人介紹頁 |
Google 建議人物使用 Person、組織使用 Organization，不要為方便而全部使用泛用的 Thing。Google Article structured data
固定 @id 為什麼重要？
固定 @id 能讓不同頁面的結構化資料指向同一個網站實體。只要 Claire Chang 與允愛數位科技的 @id 全站一致，搜尋引擎就能把文章作者、公司與個人頁合併理解，而不是視為多個同名物件。
我目前採用：
- Claire Chang：
https://claire-chang.com/#claire-chang - 允愛數位科技：
https://claire-chang.com/#organization
@id 是識別符，不一定要成為獨立可瀏覽頁面；但實體本身仍應有對應的可見資訊與網址。名稱、職稱與關係若改變，也要同步更新主要實體定義。
worksFor、author 與 publisher 要怎麼串？
Person.worksFor 表達作者任職或所屬組織，Article.author 表達文章作者，Article.publisher 表達發布單位。三種關係的方向與意義不同，應分別指向正確 @id，不能互相替代。
我網站上的關係可整理為：
| 主體 | 關係 | 指向 |
|---|---|---|
| Claire Chang | worksFor | 允愛數位科技 |
| Article | author | Claire Chang |
| Article | publisher | 允愛數位科技 |
同一組核心 Person 與 Organization 不必在每篇文章完整重寫；文章可以用 {"@id":"…"} 引用全站一致的實體。這種做法也比較容易集中維護作者職稱、社群連結與公司識別資料。
哪些頁面應該放完整 Person 與 Organization？
個人介紹頁適合完整描述 Person 與 ProfilePage，首頁或公司介紹頁適合完整描述 Organization。文章頁應保留 Article，並以 author、publisher 引用核心實體；不需要每頁都塞入所有詳細欄位。
Google 表示，在首頁加入 Organization 結構化資料可協助理解組織行政資訊與消歧。Google Organization ProfilePage 則適合以人物或組織為主要焦點、呈現第一手觀點的頁面。Google ProfilePage
about 與 mentions 有什麼差別？
about 表示文章主要討論的主題，mentions 表示文章提到但不是核心主題的具體實體。兩者都應根據正文內容建立，不能為了增加關鍵字而把未實際討論的工具、公司或技術加入標記。
例如本文的 about 可以包含 Schema.org、JSON-LD 與實體關係；Google Rich Results Test 雖然在文中出現，若只是驗證工具而非核心主題，則較適合 mentions。
FAQPage 應該在什麼情況使用？
只有頁面實際顯示由網站提供的問題與答案時，才應建立 FAQPage。FAQPage 不應標記隱藏內容，也不要期待一般商業網站一定取得 Google FAQ 複合式搜尋結果。
Google 目前將 FAQ 複合式搜尋結果的顯示範圍限制在知名且具權威性的政府與健康網站，但準確的問答結構仍有助於機器理解內容。Google FAQ structured data
結構化資料要怎麼驗證？
結構化資料應同時用 Rich Results Test 與 Schema Markup Validator 檢查。前者檢查 Google 支援的搜尋功能，後者檢查較完整的 Schema.org 詞彙；通過驗證仍不代表內容一定顯示為複合式結果。
我的驗證順序是先看 JSON-LD 能否解析，再檢查實體關係與頁面可見內容是否一致，最後才看 Google 是否支援該類複合式搜尋結果。
GEO 結構化資料常見問題
結構化資料最常見的錯誤不是少放欄位，而是建立重複實體、使用錯誤類型或標記頁面沒有的內容。先確保關係正確與資料真實，再增加建議欄位。
每篇文章都要建立新的 Person 嗎？
不用。同一作者應使用一致 @id，讓不同 Article 指向同一 Person。
publisher 可以直接填公司名稱字串嗎？
Schema.org 雖允許不同表達方式，但個人品牌網站若已建立 Organization，使用固定 @id 引用會有更一致的實體關係。
sameAs 可以放任何社群連結嗎？
sameAs 應放能確認同一人物或組織身分的官方外部頁面，不應放一般文章、合作夥伴或無法驗證身分的頁面。
結構化資料錯誤會影響一般排名嗎？
Google 說明，結構化資料人工處置會使頁面失去複合式結果資格，但不等同直接影響一般網頁排名。Google 結構化資料規範
JSON-LD 一定比 Microdata 好嗎？
Google 支援 JSON-LD、Microdata 與 RDFa，並普遍建議 JSON-LD。選擇格式後，最重要的是資料與可見內容保持同步。
參考資料
本文以 Google Search Central 與 Schema.org 的結構化資料定義為主要依據，實體關係範例則來自 claire-chang.com 當前網站架構。
延伸閱讀
- E-E-A-T 怎麼強化？讓 AI 與搜尋引擎看懂作者專業度：Person 與作者頁如何互相支撐，這篇有完整的可信度說明。
- 如何讓文章更容易被 AI 搜尋引擎理解與引用？GEO 內容優化教學：結構化資料之外，內容本身如何做到可獨立理解。
- AI 搜尋引擎優化怎麼做？網站 GEO 優化完整指南：本文談的實體關係，對應完整 GEO 四層架構中的可辨識層。
關於作者
Claire Chang ｜ 企業 AI 導入與流程轉型顧問。專注於 AI Agent 架構設計、ERP 系統整合與企業 AI 治理。
首次發布：2026-08-28