# Organization Schema：sameAs怎麼寫 > Organization Schema（組織結構化數據）是一段放在網頁中的代碼，用來向搜尋系統説明：這家組織叫什麼、官網是哪一個、使用什麼標誌、地址在哪裏，以及它在其他網站上有哪些可以核驗的身份頁面。 來源：https://www.starbox.work/zh-hant/insights/geo-guide/geo120/（星盒AI 知識中心，更新於 2026-10-07） Organization Schema（組織結構化數據）是一段放在網頁中的代碼，用來向搜尋系統説明：這家組織叫什麼、官網是哪一個、使用什麼標誌、地址在哪裏，以及它在其他網站上有哪些可以核驗的身份頁面。 很多網站已經添加了這段代碼，做法卻只是複製模板，再替換公司名稱和官網地址。代碼看起來完整，實際資訊可能並不準確，常見問題包括： - 代碼中的組織資訊與頁面正文不一致； - `sameAs` 填入了不能證明組織身份的連結； - 同一家公司在不同頁面使用了不同的名稱、標誌、地址或外部賬號。 `sameAs` 是 Organization Schema 中的一個屬性，用來填寫能夠明確識別同一組織的外部頁面。這裏的 URL，指可以直接訪問的網頁地址。`sameAs` 不是友情連結，也不是所有提到過這家公司的網頁。 準確的 Organization Schema 可以幫助搜尋系統理解組織資訊、區分同名主體，也可能影響組織標誌等搜尋展示元素。但它不能保證網站一定獲得特定展示，也不能保證內容一定被 AI（人工智能）系統引用。 這段代碼是否有用，主要取決於資訊是否真實、統一，並且能夠持續維護，而不是填寫了多少字段。 ## 添加之前，先確認6條規則 ### 1. 放在真正介紹組織的頁面 Google 建議將 Organization 結構化數據放在網站首頁，或者“關於我們”這類專門介紹組織的頁面，不需要在每個頁面重複添加。 如果網站系統會自動在所有頁面輸出這段代碼，應確保每個頁面使用的組織名稱、標誌、網址和固定標識完全一致。 ### 2. 不需要填滿所有字段 Google 的 Organization 指南沒有規定必須填寫哪些屬性。網站只應填寫真實、適用，並且能夠持續維護的資訊。 字段少但準確，比字段多卻包含失效連結或虛假資訊更合適。沒有公開地址、税號、員工數或對外聯繫方式時，可以不填，不能為了讓代碼顯得完整而編造。 ### 3. 選擇與組織匹配的類型 `@type` 用來説明當前數據描述的是哪類主體。不是所有網站都應該使用最寬泛的 `Organization`。 電商網站可以考慮 `OnlineStore`，也就是網上商店類型；實體門店則應結合 `LocalBusiness`，也就是本地經營場所類型，以及對應的官方指南處理。 具體使用哪種類型，應根據組織的真實業務和頁面內容決定。 ### 4. 正確理解`sameAs` Schema.org 是一套供網站描述人物、組織、商品等資訊的通用結構化數據詞彙。它將 `sameAs` 定義為能夠明確表明當前項目身份的參考網頁地址。 因此，`sameAs` 不能用來填寫普通友情連結、關鍵詞相關頁面，或者只在正文中提到過該組織的文章。 ### 5. 數量沒有統一下限 `sameAs` 可以填寫多個網址，但官方沒有規定最低數量，也沒有“必須填寫8條”之類的要求。 只填寫真正屬於該組織，並且能夠核驗身份的頁面。三條準確連結，比十條混有錯誤主體的連結更可靠。 ### 6. 優先使用JSON-LD，並檢查實際輸出 JSON-LD 是一種用代碼描述網頁資訊的結構化數據格式。Google 通常建議使用這種格式，因為它比較容易部署和維護。 代碼寫完後，要先檢查語法；正式上線後，還要查看搜尋引擎實際讀取的網頁中是否包含最新數據。不能只檢查網站後台中的配置。 ![Organization Schema：sameAs怎麼寫](/static/img/insights/geo-guide/geo120-2.jpg) ## 每個字段分別填寫什麼 | 字段 | 含義及填寫方式 | 常見錯誤 | |---|---|---| | `@context` | 聲明代碼使用哪套結構化數據詞彙，通常填寫 `https://schema.org` | 拼寫錯誤或使用無效地址 | | `@type` | 填寫與實際組織最匹配的類型 | 門店和電商網站一律填寫 `Organization` | | `@id` | 填寫站內穩定、唯一的組織標識地址 | 每個頁面生成不同的標識 | | `name` | 填寫網站和用戶日常識別的組織名稱 | 官網、代碼和社交賬號使用不同名稱 | | `legalName` | 填寫與工商或註冊資訊一致的法定名稱 | 把宣傳口號寫成法定名稱 | | `alternateName` | 填寫真正使用的簡稱、英文名或歷史別名 | 堆積關鍵詞和產品名稱 | | `url` | 填寫組織官方網站的固定標準網址 | 填寫欄目頁或臨時活動頁 | | `logo` | 填寫可以公開訪問的正式 Logo，也就是組織標誌圖片 | 圖片無法訪問、需要登錄或尺寸過小 | | `description` | 填寫能夠由頁面正文核驗的組織介紹 | 加入頁面中沒有的榮譽、規模或業務 | | `foundingDate` | 填寫真實的成立日期 | 使用未經核驗的日期 | | `address` | 填寫適用且真實的聯繫地址 | 與頁面或營業資訊中的地址衝突 | | `contactPoint` | 填寫用戶目前可以正常使用的聯繫方式 | 電話、郵箱已經停用 | | `sameAs` | 填寫能夠明確識別同一組織的外部頁面 | 填寫搜尋結果、轉載文章或他人頁面 | 下面分別説明最容易出錯的幾組字段。 ![Organization Schema：sameAs怎麼寫](/static/img/insights/geo-guide/geo120-3.jpg) ## `name`、`legalName`和`alternateName`怎麼區分 這三個字段不能分別寫成三套互不相關的宣傳詞。 - `name`：網站和用戶日常使用的組織名稱； - `legalName`：組織的正式註冊名稱； - `alternateName`：組織公開使用的簡稱、英文名或歷史別名。 只有當日常名稱與法定名稱不同時，分別填寫 `name` 和 `legalName` 才有實際意義。 填寫前，可以先整理一份名稱核驗記錄： | 使用位置 | 示例 | 核驗依據 | |---|---|---| | `name` | 示例科技 | 官網頁頭、站點名稱 | | `legalName` | 示例科技有限公司 | 註冊文件、網站法律資訊 | | `alternateName` | Example Tech | 官網公開使用的英文名稱 | 如果某個英文名只出現在代碼中，網站頁面和公開資料從未使用，就不適合直接寫入 `alternateName`。 ## `@id`為什麼要保持穩定 `@id` 是同一組織在結構化數據中的固定標識。它不是網頁標題，也不要求用戶打開後看到一個獨立頁面。 常見寫法是在官網固定網址後添加一個不會隨頁面變化的片段： ```json "@id": "https://www.example.com/#organization" ``` 如果網站中的 `Article`、`WebSite` 或 `Product` 等結構化數據需要引用這個組織，可以繼續使用同一個 `@id`。這三個類型分別用於描述文章、網站和商品。 統一使用固定標識，可以避免每次引用發佈者或品牌時，又生成一套不同的名稱、標誌和地址。 同一家公司應確定一個主要組織標識。集團、子品牌和門店如果確實屬於不同主體，就要根據真實關係分別設置，不能全部指向同一個 `@id`。 ## `sameAs`應該放哪些連結 判斷一個連結能不能寫進 `sameAs`，不在於平台是否知名，而在於頁面能否明確證明它對應同一個組織。 可以考慮以下幾類頁面： - 由組織自己維護，並且公開展示組織身份的官方社交賬號； - 能夠明確對應這家組織的行業平台或評價平台資料頁； - 符合平台規則並且真實存在的 Wikipedia 或 Wikidata 條目； - 由權威註冊系統或標識系統提供的組織身份頁面。 Wikipedia 是公開協作的網絡百科全書；Wikidata 是用於記錄人物、組織、地點等資訊的結構化知識庫。 以下連結不適合寫入 `sameAs`： - 搜尋結果頁、話題頁和標籤頁； - 只提到公司一次的新聞或博客文章； - 經銷商、創始人個人或合作伙伴的頁面； - 尚未創建、無法打開或跳轉到其他主體的資料頁； - 為湊數量臨時註冊、沒有組織資訊的空賬號。 如果組織沒有 Wikipedia 或 Wikidata 頁面，直接不填即可。不要保留模板中的示例地址，也不能使用不屬於自己的 QID。QID 是 Wikidata 分配給每個條目的編號。 ## Logo、地址和聯繫方式怎麼處理 Google 建議 Logo 圖片至少為112×112像素。圖片地址應當能夠被搜尋引擎直接訪問，並使用 Google 圖片支持的格式。如果使用白色 Logo，還要檢查它在白色背景上是否能夠正常顯示。 在代碼中，Logo 可以使用 `ImageObject`，也就是圖片對象類型來描述。 地址應使用 `PostalAddress`，也就是郵寄地址類型，拆分填寫街道、城市、省份、郵政編碼和國家。國家建議使用兩位國家代碼，例如中國填寫 `CN`。 聯繫方式可以使用 `ContactPoint`，也就是聯繫資訊類型。電話號碼應包含國家和地區代碼，`contactType` 則用來説明聯繫方式的用途，例如客戶服務。 只有用戶目前確實可以使用的聯繫方式才應填寫。涉及隱私或不對外公開的資訊，不要因為代碼中有對應字段就寫進去。結構化數據最終會出現在公開網頁的源代碼中。 ## 一套可以修改的JSON-LD模板 下面使用 `example.com` 和“示例科技有限公司”作為佔位內容。代碼通過 HTML，也就是組成網頁源代碼的標記語言，嵌入頁面。 正式上線前，必須逐項替換示例內容，並刪除不適用的字段。示例名稱、地址、電話、郵箱、賬號連結和 Wikidata 編號都不能留在正式代碼中。 ```html ``` 這是一套修改模板，不是一段可以直接上線的正式代碼。某個字段沒有真實資訊時，應刪除整個字段，而不是保留空值或示例值。 ## Organization Schema應該放在哪個頁面 優先放在網站首頁，或者明確介紹組織的“關於我們”頁面。一個站點保留一套主要的 Organization 數據即可。 如果內容管理系統會在每個頁面自動輸出 Organization，應確認所有頁面中的內容和 `@id` 完全一致。內容管理系統通常簡稱 CMS，指用於編輯和發佈網站內容的後台系統。 重複輸出本身不一定造成錯誤，但如果網站主題和多個插件分別生成名稱、Logo 與 `sameAs`，就容易出現資訊衝突，也會增加維護成本。 不要只把 JSON-LD 放在需要登錄、帶有 `noindex`，或者被 `robots.txt` 阻止的頁面。 `noindex` 是要求搜尋引擎不要收錄該頁面的設置；`robots.txt` 是用於限制搜尋引擎訪問網站頁面的文件。 部署完成後，應使用 Google Search Console，也就是查看網站在 Google 中抓取和收錄情況的管理工具，檢查目標頁面。其中的 URL Inspection，中文通常稱為“網址檢查工具”，可以用來確認 Google 實際讀取的 HTML 中是否包含最新數據。 ## 上線前必須完成的8項檢查 部署前，可以使用 Rich Results Test，也就是 Google 的“富媒體搜尋結果測試”工具檢查代碼。上線後，再通過 Search Console 的網址檢查工具確認實際讀取結果。 正式發佈前，逐項檢查： 1. JSON-LD 語法是否有效，括號、引號和逗號是否正確； 2. `@context` 和 `@type` 是否正確； 3. 名稱、網址、Logo 和地址是否與頁面可見內容一致； 4. Logo 是否可以直接打開並被搜尋引擎訪問； 5. 每條 `sameAs` 是否確實屬於同一組織； 6. 示例值、空字段和失效連結是否已經全部刪除； 7. 富媒體搜尋結果測試是否出現關鍵錯誤； 8. 上線後，網址檢查工具是否能夠看到最新代碼。 代碼通過測試，不代表網站一定會出現知識面板、Logo 或其他搜尋展示。知識面板是搜尋結果中集中展示組織資訊的卡片。 結構化數據提供的是便於機器讀取的組織資訊，不是搜尋結果展示保證。 ## 上線後怎麼維護 組織名稱、官網域名、Logo、地址、聯繫方式或外部資料頁發生變化時，需要同時更新結構化數據和頁面正文。 已經失效的 `sameAs` 應及時刪除，不要長期保留已註銷賬號。每次更新後，應保留版本記錄，重新測試 JSON-LD，並檢查網頁最終輸出的代碼。 如果代碼由 CMS 插件生成，還要在網站模板或插件升級後檢查兩件事： - 原有字段是否被覆蓋； - 頁面中是否出現重複或互相沖突的組織資訊。 最終應以公開頁面實際輸出的源代碼為準，不能只看插件後台顯示的內容。 ## 常見問題 ### 1. Organization Schema必須放在每個頁面嗎？ 不需要。Google 建議放在首頁，或者“關於我們”這類專門介紹組織的頁面。如果系統會在多個頁面自動輸出，應確保內容和 `@id` 完全一致。 ### 2. `sameAs`必須填寫8條嗎？ 不需要。官方沒有統一的最低數量要求。只填寫能夠明確識別同一組織的真實頁面，準確性比數量更重要。 ### 3. 沒有Wikipedia或Wikidata頁面怎麼辦？ 不填即可。不要複製模板中的示例 QID，也不要為了填寫結構化數據而創建不符合平台規則的條目。 ### 4. 添加Organization Schema後一定會被AI引用嗎？ 不能保證。它主要幫助系統理解和區分組織資訊，也可能影響 Logo 等搜尋展示元素。是否被引用，還取決於內容、搜尋引擎是否能夠訪問和收錄頁面，以及用戶提出的具體問題。 這裏的收錄，是指搜尋系統保存網頁資訊，並允許用戶通過搜尋找到該頁面。 ### 5. 使用插件生成後還需要檢查嗎？ 需要。插件可能繼續使用舊名稱、預設 Logo 或空的社交連結，也可能與網站主題生成的數據重複。最終應以頁面實際輸出的源代碼為準。 ### 6. 怎麼驗證部署是否成功？ 部署前使用富媒體搜尋結果測試檢查代碼；上線後使用 Search Console 的網址檢查工具，查看 Google 實際讀取的頁面。發現錯誤並修復後，再請求 Google 重新訪問頁面。 ## 公開資料入口 - [Google Organization結構化數據指南](https://developers.google.com/search/docs/appearance/structured-data/organization) - [Google結構化數據工作原理](https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data) - [Schema.org Organization](https://schema.org/Organization) - [Schema.org sameAs](https://schema.org/sameAs)