快速閱讀：Organization Schema 的核心不是加入最多欄位，而是準確回答「品牌主體是誰、分店在哪裡、提供什麼服務、哪些人物與品牌有真實關是」。以 Organization 表示品牌或法人、LocalBusiness 表示可到訪分店、Service 表示服務、Person 表示真人，並只在外部頁面能明確識別同一實體時使用 sameAs。Schema 能降低機器理解歧義，但不保證 AI 引用、品牌推薦、Google AI Overviews 顯示或搜尋排名。
Organization Schema 是用結構化資料向搜尋引擎及其他機器說明品牌實體的方式。正確做法是把品牌主體、實體分店、服務與人物分開，再以穩定的 @id 建立關是；不是把所有資料塞進一個 Organization。它能減少名稱、地址及隸屬關是的歧義，但不保證 AI 引用、推薦、Google AI Overviews 顯示或搜尋排名。
本文聚焦一個實際決策：香港品牌應如何選擇 Organization、LocalBusiness、Service、Person 與 sameAs，並處理改名、分店及母子品牌。若需要先理解生成式搜尋與傳統搜尋的差異，可閱讀 AIO 101；如要把實體資料、內容與技術 SEO 一併規劃，可參考 GEO／AI Search 服務。
Organization Schema 先處理「誰是品牌主體」
Organization Schema 首先要建立一個清晰、穩定的品牌或法人節點，回答機器「這個組織是誰」。首頁或關於頁通常是合適位置，因為頁面本身會顯示正式名稱、品牌介紹、標誌及聯絡資料。
Schema.org 的 Organization 定義涵蓋公司、機構及團體，亦有多種更具體子類型。Google Search Central 建議選擇符合實際情況的最具體類型，並指出 Organization 資料可協助 Google 分辨組織及相關標誌等資料；實作時應以 Google 的 Organization 結構化資料文件作為 Google Search 行為的依據。
常用欄位包括 @id、name、url、logo、description、email、telephone、address 及 sameAs。其中 @id 最適合使用品牌控制的絕對網址加片段識別符，例如 https://www.example.hk/#organization。其他頁的 Service、Person 或 WebSite 節點可以引用這個識別符，避免每頁各自建立一個看似不同的品牌。
欄位不是越多越好。頁面沒有公開顯示、企業無法證實或很快會失效的資料，不應為了「完整」而加入。Google 明確建議，較少但完整準確的建議欄位，優於大量不完整、格式錯誤或不準確的欄位。品牌亦要確保標誌網址可抓取、名稱與頁面可見內容一致，電話使用國際格式，地址則採用 PostalAddress 的細分欄位。
Organization Schema 類型決策表：Organization、LocalBusiness、Service、Person
選型的直接原則是：Organization 表示組織，LocalBusiness 表示具體營業地點，Service 表示所提供的服務，Person 表示真人。它們不是四個互相競爭的 SEO 標籤，而是描述不同實體及關是的詞彙。
| 需要描述的對象 | 建議類型 | 關鍵欄位／關是 | 不應使用的情況 |
|---|---|---|---|
| 品牌、公司、協會或總部 | Organization 或更具體子類型 | @id、name、url、logo、sameAs |
不要用它代表一項服務或一名創辦人 |
| 可到訪而有獨立地址、電話或營業時間的分店 | LocalBusiness 或最具體子類型 | address、telephone、openingHoursSpecification、geo、branchOf | 純網上服務、服務地區或虛構門市 |
| 顧客實際購買或查詢的服務 | Service | name、serviceType、provider、areaServed、offers | 不要把服務當成另一個品牌主體 |
| 創辦人、作者、顧問或團隊成員 | Person | name、url、jobTitle、worksFor、sameAs | 沒有頁面證據的虛構人物、職銜或資格 |
| 同一實體在其他網站的明確身份頁 | sameAs 屬性，不是類型 | 官方社交專頁、可信實體識別頁 | 一般報道、文章、合作頁或搜尋結果頁 |
例如一間只有辦公室、不接待顧客的香港顧問公司，可使用 Organization，並由 Service 的 areaServed 表示服務香港。若餐飲集團有三間可到訪餐廳，集團可是一個 Organization，每間餐廳則是獨立 LocalBusiness。Google 的 LocalBusiness 官方文件要求每個營業地點分別定義，並建議使用最具體的 LocalBusiness 子類型。
Service 則描述供應內容，不等同供應商。根據 Schema.org Service 定義，provider 可連接 Organization 或 Person；在分店提供服務的情況，也可連接相應 LocalBusiness。這種角色分工有助機器分清「誰提供」、「提供什麼」及「在哪裡提供」。
Organization Schema 的安全 JSON-LD 範例
安全範例應保持精簡、資料可核實，而且讓每個節點只有一個角色。以下示例以 @graph 建立品牌、服務及創辦人三個節點；實際使用時必須換成頁面上可見的真實資料，不應直接複製示例品牌。
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Organization",
"@id": "https://www.example.hk/#organization",
"name": "Example Hong Kong Limited",
"alternateName": "Example HK",
"url": "https://www.example.hk/",
"logo": "https://www.example.hk/logo.png",
"sameAs": [
"https://www.linkedin.com/company/example-hk"
],
"founder": {"@id": "https://www.example.hk/about/#founder"}
},
{
"@type": "Service",
"@id": "https://www.example.hk/services/advisory/#service",
"name": "企業顧問服務",
"serviceType": "企業顧問",
"areaServed": {"@type": "Place", "name": "香港"},
"provider": {"@id": "https://www.example.hk/#organization"}
},
{
"@type": "Person",
"@id": "https://www.example.hk/about/#founder",
"name": "陳大文",
"jobTitle": "創辦人",
"worksFor": {"@id": "https://www.example.hk/#organization"}
}
]
}這個範例刻意沒有加入評分、獎項、價格或大量 sameAs，因為那些資料必須有真實依據及相應頁面內容。@id 的作用是讓節點互相引用；它不是 Google 頒發的實體 ID，也不會單獨產生知識面板。若網站由多個外掛輸出 JSON-LD，應先盤點是否已有相同 Organization，避免同一頁同時出現不同 @id、不同名稱或互相衝突的標誌。
Organization Schema 欄位應從哪裡取得
建立資料來源表比直接編寫程式更重要。正式公司名稱應來自企業確認的法律或品牌資料；公開品牌名稱要與網站頁首、頁尾及關於頁一致；網址使用首選 canonical 網址；標誌使用長期可存取而且可索引的圖片；電話及電郵則以網站公開的主要聯絡渠道為準。地址必須先確認是註冊地址、辦公地址還是顧客可到訪的營業地址，三者不能在沒有說明下互換。
若法律名稱與市場品牌不同，可以保留一個清晰的 Organization 主節點，按實際需要以 legalName、name 及 alternateName 區分。不要為了同時容納中英文名稱而建立兩個相同組織；較穩妥的方法是選定頁面主要顯示名稱，再把真實常用別名放入 alternateName。電話、地址或名稱尚未核實時，寧可暫時省略，也不要用搜尋結果摘要或過時目錄作唯一來源。
Service 的資料應來自相應服務頁，包括服務名稱、服務類型、適用對象、覆蓋地區及供應者。Person 的姓名、職銜、個人頁及專業資格則要由本人或企業確認，並在頁面可見。若人物沒有公開個人頁，可以只在相關 Organization 的 founder 或 employee 中提供必要資料，沒有需要為每位員工建立可索引的詳細身份節點。
Organization Schema 應放在哪些頁面
品牌主節點通常放在首頁最容易維護，因為首頁代表整個網站；關於頁可提供更完整的組織背景，但兩頁如同時輸出，必須使用相同 @id 及一致核心欄位。服務頁建立 Service，並以 provider 的 @id 引用主組織。分店頁建立該地點的 LocalBusiness；人物介紹頁建立 Person。這種「頁面主題對應主要節點」的方法，比全站每頁輸出完整而重複的圖譜更容易審計。
網站若同時輸出 WebSite、WebPage、BreadcrumbList、Article 或 FAQPage，可以把它們放在同一個 @graph，並透過 @id 連接 publisher、about、author 或 provider。重點不是所有節點一定要放在同一段 script，而是識別符及關是一致。多段 JSON-LD 在語法上可以有效，但維護者必須知道每段由哪個外掛、主題或標籤管理工具產生。
多語言網站應讓每個語言頁的可見內容與 Schema 語言一致，並保留同一實體的穩定身份。公司不會因為中文頁與英文頁而變成兩個組織；名稱有官方語言版本時，可在頁面及欄位中準確呈現。不同地區若屬獨立法人或獨立分店，才按真實情況建立額外節點。部署前應把頁面 URL、主要類型、主體 @id、資料擁有人及更新觸發條件列入內容管理清單。
Organization Schema 如何處理品牌改名與法人變更
品牌只是改名而實體延續時，通常保留原有 Organization @id，更新 name，並在頁面清楚交代改名；舊名如仍有辨識價值，可放在 alternateName。這樣較能表達「同一實體換了名稱」，而不是突然建立兩間沒有關是的公司。
改名工作不能只改 JSON-LD。品牌應同步更新首頁、關於頁、頁首與頁尾、聯絡資料、Google Business Profile、主要社交專頁及可信商業名錄。舊網址如更改，需要妥善重新導向到最相關的新網址；標誌檔案、Open Graph 資料及網站名稱亦要一致。若外部身份頁仍顯示舊名，sameAs 雖然語法有效，仍可能把不一致訊號帶入實體核對。
若情況是收購、合併、分拆或成立全新法人，便不能自動視為同一實體。新 Organization 應有自己的 @id；頁面可按真實法律及品牌關是使用 parentOrganization、subOrganization、brand、owns 等合適屬性，但不要以 Schema 宣稱不存在的控制權。歷史關是應在可見內容說明，讓人與機器都有可核實的上下文。
Organization Schema 如何處理分店與母子品牌
每間有獨立地址、電話、營業時間或地理座標的分店，應建立獨立 LocalBusiness 節點及穩定 @id。總公司或集團維持 Organization 節點，分店可用 branchOf 指向上層組織；若是部門而非分店，可按實際關是考慮 department。
假設「甲集團」擁有「乙餐飲」品牌，而乙餐飲在中環與尖沙咀各有一間店：甲集團可是一個 Organization，乙餐飲如具獨立品牌身份可另建 Organization 或 Brand，而兩間店各自使用最具體的 Restaurant 類型。不要把兩個地址塞進一個 LocalBusiness，也不要把每間店都寫成互不相關的 Organization。分店頁應顯示該店的真實地址、電話、營業時間及服務內容，Schema 必須與頁面一致。
母品牌、子品牌與法人並非同一概念。parentOrganization 表達組織隸屬，brand 表達品牌關聯，branchOf 表達地方營業點與較大組織的分店關是。選擇前要先畫出真實關是：誰持有品牌、誰簽訂合約、哪個地點接待顧客、哪個名稱在頁面公開使用。若企業自己也不能清楚回答，Schema 不可能替企業解決治理問題。
多地點網站亦應讓每個分店有可索引的獨立頁面及自我一致資料，而不是只用定位器動態顯示。若正處理網站架構與本地搜尋問題，可配合 SEO 搜尋優化檢查 canonical、站內連結、地址頁內容及索引狀態。
Organization Schema 的 sameAs 只用於同一身份
sameAs 的直接判斷標準是：目標頁能否明確、無歧義地識別同一個組織或人物。Schema.org 對 sameAs 的定義是指向能清楚表示同一項目身份的參考網頁，而不是泛指任何提及品牌的連結。
適合的例子包括品牌官方 LinkedIn 公司頁、官方 Facebook 專頁、可核實的 Wikidata 實體頁，或可信平台上的正式機構資料頁。人物節點則應連接該人的官方個人專頁或可靠身份頁，不要把公司的社交帳戶放進 Person 的 sameAs。每一條連結都應定期檢查是否仍屬於同一實體、是否改名及是否公開存取。
不適合的例子包括新聞報道、客戶案例、供應商目錄分類頁、合作夥伴首頁、論壇討論、搜尋結果、短期活動頁及自行建立但沒有獨立身份價值的空白帳戶。這些頁面可作品牌提及或證據，但不等於 sameAs。若連結只證明「曾經提及」，應保留在正常內容與公關紀錄，不應硬塞入身份欄位。
sameAs 亦不是外部連結建設工具。加入十個低質帳戶不會比兩個清晰、持續更新的官方身份頁更可信。相反，錯誤地連到同名公司或離職人士，可能增加實體歧義。品牌可先做一份身份清單，記錄平台、帳戶 URL、擁有人、顯示名稱、最後核實日期及是否仍公開。
Organization Schema 驗證要分語法、資格與一致性
驗證 Organization Schema 不能只看工具顯示綠色。完整檢查應分三層：Schema.org 語法與詞彙、Google 支援功能的資格，以及頁面與外部資料是否一致。三層都通過，才算技術上可用；仍然不代表一定出現搜尋功能或 AI 引用。
- 檢查 JSON：確認引號、逗號、陣列及物件格式正確，沒有重複鍵或相對
@id。 - Schema.org 驗證：使用 Schema Markup Validator 檢查類型、屬性及預期值。它可以接受 Schema.org 有效詞彙，但不表示 Google 必然支援相應搜尋展示。
- Google 資格測試：使用 Rich Results Test 檢查 Google 已支援的結構化資料功能，再以 Search Console 監察偵測及錯誤。
- 頁面一致性：逐項比較 JSON-LD 與頁面可見名稱、地址、電話、標誌、人物及服務，不可隱藏不存在的資料。
- 實體一致性：核對 Google Business Profile、主要社交頁、公司資料及品牌指南，記錄差異與修正日期。
- 重新抓取：部署後檢查實際 HTML，而非只測試開發環境中的程式碼；快取或外掛可能刪除、轉義或重複輸出 JSON-LD。
Google 的 結構化資料入門文件指出，Schema.org 詞彙比 Google 搜尋功能範圍更廣，Google Search 的實際要求應以 Search Central 文件為準。文件亦強調必須符合相關指引及所需欄位，資料有效只代表具備資格，不是展示保證。
建議保留驗收紀錄：測試日期、頁面 URL、部署版本、主要 @id、Validator 結果、Rich Results Test 結果、Search Console 狀態、可見內容差異、外部身份差異及負責人。品牌改名、搬遷、開店、關店、換標誌或高層變更時，應觸發重新核對。
Organization Schema 常見誤用與風險
最常見的 Organization Schema 問題不是缺少欄位，而是角色錯置、內容不實或多套程式重複輸出。以下錯誤即使語法通過，也可能令機器更難理解品牌。
- 把服務當公司：為每項服務建立 Organization，導致品牌節點分裂；應使用 Service 並由 provider 指向品牌。
- 把服務地區當門市：公司服務全港不代表在每區都有 LocalBusiness；使用 areaServed，不要製造虛假地址。
- 一個 LocalBusiness 放多個分店：地址與電話無法對應，應為每個實體地點建立獨立節點與頁面。
- 公司與人物混用：以 Organization 表示創辦人，或把公司社交帳戶放入 Person sameAs。
- 濫用 sameAs：把所有提及、報道及外部連結當成同一身份頁，反而增加歧義。
- 虛構評分與獎項：在頁面不可見或無法證實的 AggregateRating、award、credential 中加入宣傳句。
- 改名後建立兩個品牌：同一實體使用兩個
@id，舊新名稱又沒有 alternateName 或改名說明。 - 多外掛互相衝突：SEO 外掛、主題及自訂程式各自輸出 Organization，名稱、標誌與網址不一致。
Google 的一般原則是結構化資料應描述所在頁面的內容，並採用最具體適用類型。內容誤導、與頁面不符或違反政策，可能失去豐富搜尋結果資格。安全做法是先減少重複節點，再以單一資料來源管理公司名稱、地址、電話、標誌與社交連結。
Organization Schema 對 AI Search 的合理預期與下一步
Organization Schema 的合理價值是讓可抓取系統更容易解析品牌身份與關是，而不是直接操控模型答案。它可能協助搜尋引擎理解組織名稱、標誌、分店、服務供應者及人物關是，但目前沒有可信官方證據證明加入特定欄位便會令 ChatGPT、Perplexity 或其他 AI 必然引用或推薦品牌。
量度時必須區分四種結果：第一，模型在文字中提及品牌；第二，聯網答案把官網列為引用來源；第三，答案把品牌推薦為供應商；第四，頁面或品牌在 Google AI Overviews 中顯示。四者的資料來源、意圖及波動不同，不能把一次被提及等同排名提升或生意成效。
可重複測試應先建立固定問句組及基準日，記錄平台、模式是否聯網、地區、語言、問句、品牌是否被提及、引用 URL、資料是否正確、推薦語境、競爭品牌及截圖時間。完成 Schema 修正後，以相同方法定期複測，同時觀察 Search Console 的索引與搜尋表現。即使結果改善，也只能視為相關訊號，不能在沒有對照與足夠樣本下宣稱 Schema 是唯一原因。
實務次序是：先確認唯一而穩定的 Organization @id，再畫出品牌、分店、服務與人物關是；清理重複 JSON-LD 後，補上可證實欄位及精選 sameAs，最後完成 Validator、Rich Results Test、實際 HTML 及 Search Console 檢查。若網站同時需要改善可引用答案、實體一致性與監察方法，可延伸閱讀 香港品牌的 GEO 與 AI 推薦基礎及了解 GEO／AI Search 優化。
最重要的判斷：Schema 是實體資料的機器可讀版本，不是排名或 AI 推薦捷徑。先把真實世界的品牌治理做好，再讓 JSON-LD 準確反映它，才是可長期維護的 Organization Schema。
Organization Schema：相關搜尋問句（長尾覆蓋）
除了主關鍵詞，這些同義／相關問句亦常見於搜尋同 AI 摘要場景——文章內文同 FAQ 已對應回答，方便擴大覆蓋而不必硬塞主詞。
內容審閱：2026年7月｜作者：trafficholic 實務團隊（香港中小企品牌網站、社媒同 SEO 落地經驗）。觀點來自真實合作流程同渠道數據觀察；數字會隨平台演算法更新，請以當期後台為準。
Organization Schema 常見問題
Organization Schema 是否每一頁都要輸出？
不一定。品牌級 Organization 通常可在首頁或關於頁建立主要節點，網站其他頁如要引用同一實體，可使用相同的絕對 @id。技術上全站重複一致節點並非必然錯誤，但要避免不同外掛輸出互相矛盾的名稱、網址或標誌。
Organization 與 LocalBusiness 可以同時使用嗎？
可以，但兩者要代表不同層次。Organization 可代表品牌總部或法人；每個可到訪及有獨立地址、電話或營業時間的據點可用 LocalBusiness，並透過 parentOrganization 或 branchOf 表達關是。單一實體亦可使用最具體的 LocalBusiness 子類型。
沒有門市的網上服務公司應否使用 LocalBusiness？
通常不應只因為服務香港便標記為 LocalBusiness。若沒有顧客可到訪的實體營業地點，Organization 往往較合適，再由 Service 的 areaServed 說明服務地區。不要把虛擬辦公室或住宅地址包裝成門市。
Organization Schema 的 @id 應如何設定？
使用由品牌控制、長期穩定而且完整的網址加片段識別符，例如 https://www.example.hk/#organization。@id 是 JSON-LD 圖譜內的識別鍵，不必是可開啟的獨立頁面；品牌改名時通常保留原 @id，除非實體本身已經改變。
品牌改名後需要刪除舊名稱嗎？
正式名稱應更新為目前公開使用的名稱；若舊名仍有助辨識，而且頁面可見內容清楚交代改名，可使用 alternateName 保留歷史名稱。同步更新官網、主要商業資料及社交帳戶，並避免新舊名稱在不同 Schema 節點互相競爭。
sameAs 是否可以放所有社交及目錄連結？
不應。sameAs 表示另一頁能明確識別同一實體，適合官方社交專頁或可信實體資料頁；一般新聞、合作夥伴頁、文章、短期活動頁及不受控制的搜尋結果都不應加入。連結數量不是品質指標。
Service Schema 可否取代 Organization Schema？
不可以。Service 描述「提供什麼」，Organization 或 LocalBusiness 描述「由誰提供」。較安全的做法是在服務頁建立 Service 節點，利用 provider 引用品牌或分店的 @id，而不是把服務名稱寫成另一間 Organization。
創辦人與團隊成員是否全部要用 Person Schema？
只標記頁面上真實、可見而且與內容相關的人物。創辦人可由 founder 連接，文章作者可由 author 連接；一般團隊頁亦可建立 Person，但不應虛構職銜、資格、獎項或社交帳戶。個人 sameAs 同樣要指向該人的明確身份頁。
通過 Schema Markup Validator 是否代表 Google 一定採用？
不是。Validator 主要檢查 Schema.org 詞彙和結構；Rich Results Test 檢查 Google 支援的搜尋功能資格。兩者通過仍不代表一定顯示豐富搜尋結果，更不代表 AI 系統一定引用、推薦或提升排名。
如何量度 Organization Schema 對 AI Search 的作用？
先記錄技術有效性、品牌資料一致性及搜尋系統是否正確理解，再以固定問句分開記錄品牌被提及、答案是否引用官網、是否推薦為供應商，以及是否出現在 Google AI Overviews。不要把任何一次答案截圖當成因果證明。
