Organization 與 WebSite 標記：品牌識別與網站名稱

這兩個型別描述的不是某一頁的內容，而是 整個網站與它背後的組織：

型別	描述什麼
Organization	網站背後的組織或品牌
WebSite	網站本身

所以它們有一個和其他型別不同的特性：應該集中在首頁，而不是每頁都放。

Organization

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "某某科技",
  "url": "https://example.com",
  "logo": {
    "@type": "ImageObject",
    "url": "https://example.com/logo.png",
    "width": 512,
    "height": 512
  },
  "description": "提供網頁設計與前端開發服務。",
  "sameAs": [
    "https://www.facebook.com/example",
    "https://x.com/example",
    "https://www.linkedin.com/company/example",
    "https://www.youtube.com/@example"
  ],
  "contactPoint": {
    "@type": "ContactPoint",
    "contactType": "customer service",
    "telephone": "+886-2-1234-5678",
    "email": "service@example.com",
    "availableLanguage": ["zh-Hant", "en"]
  }
}

欄位說明

欄位	必要性	說明
name	必填	組織名稱
url	建議	官方網站
logo	建議	標誌圖片，至少 112 × 112
sameAs	建議	官方社群帳號與百科條目
description	選填	組織簡介
contactPoint	選填	聯絡方式
address	選填	地址（實體店面見 LocalBusiness ）
foundingDate	選填	成立日期

logo 的要求

項目	要求
最小尺寸	112 × 112 像素
格式	搜尋引擎支援的圖片格式
可爬取	不能被 robots.txt 擋住

logo 和 favicon 是兩件事

Organization 的 logo 用於知識面板等品牌呈現；搜尋結果旁的小圖示 是另一套規則（至少 48 × 48、邊長為 48 的倍數）。

兩者的視覺應該一致，但通常是不同的檔案，標誌是完整版，圖示是扁平化的方形版。

sameAs 的用途

它幫搜尋引擎確認 這些帳號屬於同一個實體：

"sameAs": [
  "https://www.facebook.com/example",
  "https://x.com/example",
  "https://zh.wikipedia.org/wiki/某某科技"
]

只放官方的

不要放非官方的粉絲頁、第三方報導或商品目錄頁。sameAs 的意思是「這也是我」，放進不是自己控制的頁面會讓宣告失去可信度。

WebSite 與網站名稱

WebSite 描述網站本身。它現在的用途是 網站名稱（site name），讓搜尋結果的來源顯示您指定的名稱，而不是直接把網域印出來：

{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "@id": "https://example.com/#website",
  "name": "某某科技",
  "alternateName": "某某",
  "url": "https://example.com",
  "inLanguage": "zh-Hant-TW",
  "publisher": { "@id": "https://example.com/#organization" }
}

欄位	說明
name	希望顯示的網站名稱
alternateName	常見的簡稱或英文名，選填
url	網站首頁
publisher	用 @id 參照上面的 Organization

這段一定要放在首頁

搜尋引擎只從 首頁 讀取網站名稱，放在內頁沒有效果。這也是 WebSite 與 Organization 都該集中在首頁的原因之一。

SearchAction 與站內搜尋框已經停用

Google 於 2024 年 11 月停止顯示站內搜尋框

搜尋結果裡那個「在本站搜尋」的輸入框 已經全面移除，相關的官方文件也一併撤下了。這和 HowTo 的情況一樣，是產品決策而不是標記寫錯。

舊專案裡常見的這段標記，現在不會有任何效果：

"potentialAction": {
  "@type": "SearchAction",
  "target": {
    "@type": "EntryPoint",
    "urlTemplate": "https://example.com/search?q={search_term_string}"
  },
  "query-input": "required name=search_term_string"
}

留著或刪掉都可以。 官方明確說明不再支援的標記不會造成問題，也不會在 Search Console 產生錯誤。新專案就不必再寫了。

要刪的話只刪 potentialAction

WebSite 型別本身 仍然有用，網站名稱就靠它。整段 WebSite 一起刪掉會連網站名稱也丟掉，只拿掉 potentialAction 那一段就好。

集中在首頁，用 @id 參照

不要在每一頁重複整份組織資訊

// 每篇文章都寫這麼一大段？
"publisher": {
  "@type": "Organization",
  "name": "某某科技",
  "logo": { "@type": "ImageObject", "url": "https://example.com/logo.png" },
  "sameAs": ["...", "...", "..."],
  "contactPoint": { "..." }
}

一來沒有額外效果，二來改一個社群連結要動幾百個頁面。

正確做法是 首頁完整描述一次並給它 @id，其他頁面用識別碼參照：

// 首頁：完整定義
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "某某科技",
      "logo": { "@type": "ImageObject", "url": "https://example.com/logo.png" },
      "sameAs": ["https://x.com/example"]
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "url": "https://example.com",
      "publisher": { "@id": "https://example.com/#organization" }
    }
  ]
}

// 文章頁：只用識別碼參照
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "文章標題",
  "publisher": { "@id": "https://example.com/#organization" }
}

@id 的命名慣例

用 網址加上井號與名稱：https://example.com/#organization、https://example.com/#website。這樣識別碼本身就唯一，也看得出它屬於哪個網站。

@id 的機制見 JSON-LD 語法與驗證 。

個人網站用 Person

個人品牌的網站用 Person 比 Organization 貼切：

{
  "@context": "https://schema.org",
  "@type": "Person",
  "@id": "https://example.com/#person",
  "name": "Away",
  "url": "https://example.com/about",
  "image": "https://example.com/avatar.png",
  "jobTitle": "前端工程師",
  "worksFor": {
    "@type": "Organization",
    "name": "某某公司"
  },
  "sameAs": [
    "https://github.com/example",
    "https://x.com/example"
  ]
}

情況	用哪個
個人部落格、作品集	Person
有註冊公司	Organization
團隊名義營運的網站	Organization

這個站的做法

首頁有 WebSite 與 ItemList 兩段標記：

{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "name": "前端工程文件",
  "url": "https://docs.incode.tw",
  "description": "以繁體中文整理的前端工程學習筆記。",
  "inLanguage": "zh-Hant-TW",
  "publisher": {
    "@type": "Person",
    "name": "Away",
    "url": "https://docs.incode.tw/about"
  }
}

這裡沒有 SearchAction

站內搜尋框已經停用，這段標記不必再寫。何況這個站的搜尋是純前端的本機搜尋，本來就沒有 ?q= 這種伺服器端的搜尋網址。

publisher 用 Person 而非 Organization，因為它是個人維護的文件站。

首頁的 ItemList 則列出各主題分類的入口頁，這是 WebSite 之外另一個適合放在首頁的型別。

檢查清單

項目	標準
Organization 或 Person 集中在首頁	建議
有 @id 供其他頁面參照	建議
其他頁面用 @id 而非重複整份資訊	建議
logo 至少 112 × 112 且可爬取	建議
sameAs 只放官方帳號	必備
WebSite 有 name 且放在首頁	建議
沒有再寫已停用的 SearchAction	建議
個人網站用 Person 而非 Organization	建議
內頁沒有重複的 WebSite 標記	建議

常見問題

Organization 標記要放在每一頁嗎？

不用，應該集中在首頁完整描述一次。其他頁面若需要引用，用 @id 參照就好。每頁重複整份組織資訊不但沒有額外效果，還讓維護時要改幾百個地方。

sameAs 該放哪些連結？

放官方的社群帳號與百科條目，例如：臉書、X、領英、YouTube 的官方頁面。它幫搜尋引擎確認這些帳號屬於同一個實體。不要放非官方的粉絲頁或第三方報導。

SearchAction 還需要寫嗎？

不需要。Google 已在 2024 年 11 月停止顯示站內搜尋框，這段標記現在沒有任何作用。舊專案留著或刪掉都可以，官方說不支援的標記不會造成問題；要刪的話只拿掉 potentialAction 那一段，WebSite 本身仍然負責網站名稱。

個人網站要用 Organization 還是 Person？

個人品牌的網站用 Person 更貼切，欄位包含職稱、任職單位與社群帳號。有註冊公司或以團隊名義營運的用 Organization。兩者的社群帳號欄位寫法相同。

logo 有尺寸要求嗎？

建議至少 112 × 112 像素，格式用搜尋引擎支援的圖片格式，而且必須可被爬取。它與 搜尋結果旁的網站圖示 是兩件不同的事，後者有自己的尺寸規則。

延伸閱讀

JSON-LD 語法與驗證搜尋結果的網站圖示 favicon在地商家與活動標記結構化資料是什麼？

參考資料：Google 搜尋中心：機構結構化資料