Organization Schema：sameAs怎麼寫

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 通常建議使用這種格式，因為它比較容易部署和維護。

代碼寫完後，要先檢查語法；正式上線後，還要查看搜尋引擎實際讀取的網頁中是否包含最新數據。不能只檢查網站後台中的配置。

每個字段分別填寫什麼

字段	含義及填寫方式	常見錯誤
@context	聲明代碼使用哪套結構化數據詞彙，通常填寫 https://schema.org	拼寫錯誤或使用無效地址
@type	填寫與實際組織最匹配的類型	門店和電商網站一律填寫 Organization
@id	填寫站內穩定、唯一的組織標識地址	每個頁面生成不同的標識
name	填寫網站和用戶日常識別的組織名稱	官網、代碼和社交賬號使用不同名稱
legalName	填寫與工商或註冊資訊一致的法定名稱	把宣傳口號寫成法定名稱
alternateName	填寫真正使用的簡稱、英文名或歷史別名	堆積關鍵詞和產品名稱
url	填寫組織官方網站的固定標準網址	填寫欄目頁或臨時活動頁
logo	填寫可以公開訪問的正式 Logo，也就是組織標誌圖片	圖片無法訪問、需要登錄或尺寸過小
description	填寫能夠由頁面正文核驗的組織介紹	加入頁面中沒有的榮譽、規模或業務
foundingDate	填寫真實的成立日期	使用未經核驗的日期
address	填寫適用且真實的聯繫地址	與頁面或營業資訊中的地址衝突
contactPoint	填寫用戶目前可以正常使用的聯繫方式	電話、郵箱已經停用
sameAs	填寫能夠明確識別同一組織的外部頁面	填寫搜尋結果、轉載文章或他人頁面

下面分別説明最容易出錯的幾組字段。

name、legalName和alternateName怎麼區分

這三個字段不能分別寫成三套互不相關的宣傳詞。

• name：網站和用戶日常使用的組織名稱；
• legalName：組織的正式註冊名稱；
• alternateName：組織公開使用的簡稱、英文名或歷史別名。

只有當日常名稱與法定名稱不同時，分別填寫 name 和 legalName 才有實際意義。

填寫前，可以先整理一份名稱核驗記錄：

使用位置	示例	核驗依據
name	示例科技	官網頁頭、站點名稱
legalName	示例科技有限公司	註冊文件、網站法律資訊
alternateName	Example Tech	官網公開使用的英文名稱

如果某個英文名只出現在代碼中，網站頁面和公開資料從未使用，就不適合直接寫入 alternateName。

@id為什麼要保持穩定

@id 是同一組織在結構化數據中的固定標識。它不是網頁標題，也不要求用戶打開後看到一個獨立頁面。

常見寫法是在官網固定網址後添加一個不會隨頁面變化的片段：

"@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 編號都不能留在正式代碼中。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://www.example.com/#organization",
  "name": "示例科技有限公司",
  "legalName": "示例科技有限公司",
  "alternateName": "示例科技",
  "url": "https://www.example.com/",
  "logo": {
    "@type": "ImageObject",
    "url": "https://www.example.com/assets/logo.png"
  },
  "description": "提供工業設備設計、生產與技術服務。",
  "foundingDate": "2018-06-01",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "示例路88號",
    "addressLocality": "杭州市",
    "addressRegion": "浙江省",
    "postalCode": "310000",
    "addressCountry": "CN"
  },
  "contactPoint": {
    "@type": "ContactPoint",
    "telephone": "+86-571-0000-0000",
    "email": "contact@example.com",
    "contactType": "customer service"
  },
  "sameAs": [
    "https://www.linkedin.com/company/example-company",
    "https://www.youtube.com/@example-company",
    "https://www.wikidata.org/wiki/Q000000"
  ]
}
</script>

這是一套修改模板，不是一段可以直接上線的正式代碼。某個字段沒有真實資訊時，應刪除整個字段，而不是保留空值或示例值。

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結構化數據指南
• Google結構化數據工作原理
• Schema.org Organization
• Schema.org sameAs