首頁 » 觀點聚焦 » Organization Schema 品牌實體設定完整攻略
SEO優化
2026.07.08　最後更新 2026.07.09 Haden

Organization Schema 品牌實體設定完整攻略

在 Google 搜尋框打上自己的品牌名，按下 Enter，右邊那一塊整理得乾乾淨淨的資訊卡卻始終沒出現。有時更尷尬，跳出來的是一家同名公司、一個對不上的 Logo，甚至是一段你根本沒寫過的描述。你明明天天更新網站、社群也經營得很勤，搜尋引擎卻好像認不得你是誰。

問題往往不在內容夠不夠多，而在於你從來沒有用機器看得懂的方式，正式跟 Google 自我介紹一次。Organization Schema 就是這份「品牌身分證」的結構化資料，它用標準化的 JSON-LD 格式，把你的名稱、官網、Logo、社群帳號一次講清楚，讓搜尋引擎能把網站上散落的線索，收斂成一個它能唯一識別的品牌實體。 沒有它，Google 只能靠零碎的網頁訊號去猜你是誰；有了它，你才算把品牌正式登記進它的認知系統。

這件事在 AI 搜尋時代又更重要了一層。先從「實體」這個概念為什麼會決定你被不被認識講起，再一路把必填欄位、完整 JSON-LD 範本、WordPress 怎麼設定，一關一關拆給你看。

為什麼 Google 排的是「實體」，而不再只是關鍵字

早在 2012 年，Google 推出知識圖譜（Knowledge Graph）時就喊出一句口號——「Things， not strings」，事物，而不是字串。意思是搜尋引擎不再只把「龐果」當成兩個比對用的文字，而是試著把它理解成一個有屬性、有關係的真實對象：它是一家公司，做什麼的，創辦人是誰，官網在哪，跟哪些社群帳號是同一個主體。

實體（Entity）指的就是任何「唯一且可被明確辨識的對象」，可以是人、地點、組織，也可以是一個品牌。每一個實體在知識圖譜裡都會被分配一個專屬 ID，附帶它的屬性與關係。這套基礎建設不是擺著好看，後來的 Hummingbird、RankBrain、BERT、MUM 一路到生成式的 AI Overviews，全都是圍繞著「實體與實體之間的關係」在運作。

換句話說，現在這個階段，業界已經有一個共識——Google 不再只排關鍵字，而是排實體。如果你的品牌在它眼中還是一團模糊的字串，沒有被升格成一個「驗證過的實體」，那麼不管是傳統搜尋結果的知識面板，還是 AI 直接生成的摘要，都很難穩定地把你叫出來、引用你。

實體之所以重要，還有一個很實際的理由是「解除歧義」。同一個名稱可能對應好幾個對象，Google 需要足夠的訊號才能在對的情境下把對的你配出來。而把這些訊號用機器看得懂的方式遞給它，最直接的工具就是 Organization Schema。

Organization Schema 是什麼，跟一般 SEO 有什麼不同

一句話先講清楚——Organization Schema 是一段用 Schema.org 詞彙寫成的結構化資料，放在你的網頁裡，專門用來向搜尋引擎宣告「這個品牌是誰」。它不影響使用者在頁面上看到的內容，是寫給機器讀的那一層。

跟你平常做的關鍵字、內容、外鏈那種 SEO 不太一樣。傳統 SEO 是在優化「文字本身」，希望 Google 從字裡行間推敲出你的意思；結構化資料則是跳過推敲這一步，直接把答案告訴它。Google 官方文件講得很白——在首頁加入機構結構化資料，有助於它進一步了解你的管理細節，並在搜尋結果中把你跟其他機構區分開來。

它最常用的格式是 JSON-LD。這種寫法的好處是可以跟 HTML 完全分離——你只要在頁面的 <head> 或 <body> 結尾放一段 <script type="application/ld+json">，把資料包在裡面就好，不必去動現有的版面或內容。也正因為這樣，Google 官方把 JSON-LD 列為最推薦的實作方式。

要特別澄清一個常見誤會。Organization Schema 屬於「不直接觸發華麗複合式搜尋結果」的那種標記，它不會像食譜或評論那樣，立刻在搜尋結果長出星星和圖片。它的價值是在背景默默累積——幫 Google 確認你的身分、決定知識面板要顯示哪個 Logo、把你的內容歸到對的發布者名下。看不見，但是地基。

必填欄位有哪些，又有哪些其實該補滿

先講一個會讓很多人鬆一口氣、但也容易被誤用的事實——Google 官方明說，Organization Schema 並沒有所謂「必要欄位」。它的建議很簡單，盡可能加入所有跟你機構相關的屬性，提供得越完整，Google 能利用的訊號就越多。

不過「沒有強制必填」不代表可以亂寫。實務上有一組欄位是地基中的地基，少了它們，這段標記幾乎發揮不了作用。可以把它分成兩層來看。

第一層是無論如何都要寫的核心欄位：

  1. @type：宣告這是什麼類型，通常就是 Organization；如果你是純電商，建議用更精確的子類型 OnlineStore，在地實體店家則用 LocalBusiness。
  2. name：品牌的正式名稱，要跟你的網站名稱、社群名稱保持完全一致。
  3. url：官方網站的網址，這是 Google 用來精準對應你是誰的關鍵錨點。
  4. logo：代表品牌的標誌圖檔網址。這個欄位會直接影響知識面板和搜尋結果裡顯示哪一個 Logo，所以圖片網址一定要能正常打開、不能是 404。

第二層是強烈建議補上、對建立實體特別有幫助的欄位：

  1. sameAs：你在其他權威網站上的個人檔案網址，例如維基百科、Wikidata、LinkedIn、各社群帳號。這是整段標記裡最重要的實體訊號，下一節會單獨展開。
  2. description：一段品牌的簡介，知識面板裡的那段描述文字常常就來自這裡。
  3. foundingDate：成立日期，替品牌補上時間維度的脈絡。
  4. founder：創辦人，這個欄位會把你的品牌和一個「人」的實體連起來，後面講 Person Schema 時會用到。
  5. contactPoint：聯絡方式，可以放客服電話、Email。有趣的是，補上這個欄位往往也能讓驗證工具更穩定地把整段 Organization 標記辨識出來。

如果你是電商，還可以延伸補上地址（address）、會員方案、退貨與運送政策這類欄位，讓商家知識面板顯示更多細節。但對大多數想先把品牌實體立起來的人來說，把上面兩層欄位填對、填一致，就已經是合格的起點。

sameAs 為什麼是整段標記裡最關鍵的一行

如果只能在 Organization Schema 裡用心經營一個欄位，那就是 sameAs。它是一個網址陣列，作用像一個數位等號，等於在跟 Google 說：「我官網上的這個品牌，和維基百科上的它、LinkedIn 上的它、Wikidata 上的它，是同一個主體。」

這一行的份量為什麼這麼重？因為 Google 的知識圖譜不會只信你單方面的說法，它要把多個來源的資料交叉比對、整合成一個可信的實體。sameAs 等於替它把這些散落各處的官方檔案串成一條線，讓它有信心把它們認定成同一個你。對 AI 搜尋來說，這條線還有個額外好處——當答案要引用來源時，明確的權威連結能降低模型把你的資訊張冠李戴、甚至憑空編造的機率。

不是每個連結份量都一樣。可以照權威性分成幾個層級來排優先：

  1. 最高優先：維基百科頁面、Wikidata 條目，以及你完全掌控的官方社群主帳號。維基百科和 Wikidata 是知識圖譜的核心資料源，這兩個帶來的認證效果，遠高於一般社群連結。
  2. 次優先：LinkedIn 公司頁、Crunchbase 之類的商業檔案、Google 商家檔案、產業專屬目錄。
  3. 支援性：其餘的社群與內容平台，例如 YouTube 頻道、Facebook 粉專等。

填 sameAs 有三個鐵則要守。第一、只放你真正擁有、且還活著的帳號，連到一個你控制不了或早就停更的頁面只會扣分。第二、所有連結頁面上的品牌資訊（名稱、簡介、Logo）要彼此一致，對不上反而會讓 Google 起疑。第三、帳號有異動就要回來維護，把失效的連結拿掉、把新的權威檔案補上。

完整 JSON-LD 範本，照著改就能用

觀念講完，直接給你一份可以複製、把內容換成自己品牌就能上的完整範本。先看基礎版，欄位精簡，適合剛起步：

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://www.yourbrand.com/#organization",
  "name": "你的品牌名稱",
  "url": "https://www.yourbrand.com",
  "logo": "https://www.yourbrand.com/images/logo.png",
  "description": "一句話講清楚你的品牌是做什麼的。",
  "foundingDate": "2018",
  "sameAs": [
    "https://www.facebook.com/yourbrand",
    "https://www.instagram.com/yourbrand",
    "https://www.linkedin.com/company/yourbrand"
  ]
}Code language: JSON / JSON with Comments (json)

這裡有一個小細節值得特別講——@id。它替你的品牌實體指定一個專屬的識別碼，這個網址不需要真的存在一個頁面，它的作用是當「站內錨點」。有了它，同一頁上其他的結構化資料（例如每篇文章的 BlogPosting）就能用 @id 反向指回你的 Organization，把零散的標記串成一張連通的圖，而不是各自孤立的資料島。

進階版把建議欄位補滿，並且加進創辦人和聯絡資訊，給想一次到位的人參考：

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://www.yourbrand.com/#organization",
  "name": "你的品牌名稱",
  "alternateName": "品牌的常用別名",
  "url": "https://www.yourbrand.com",
  "logo": {
    "@type": "ImageObject",
    "url": "https://www.yourbrand.com/images/logo.png",
    "width": 600,
    "height": 60
  },
  "description": "你的品牌是一家專注於 OO 的公司，提供 XX 服務。",
  "foundingDate": "2018-03-15",
  "founder": {
    "@type": "Person",
    "name": "創辦人姓名"
  },
  "knowsAbout": ["你的專業領域一", "你的專業領域二", "你的專業領域三"],
  "contactPoint": {
    "@type": "ContactPoint",
    "contactType": "customer service",
    "telephone": "+886-2-1234-5678",
    "email": "[email protected]"
  },
  "sameAs": [
    "https://zh.wikipedia.org/wiki/你的品牌",
    "https://www.wikidata.org/wiki/Q12345678",
    "https://www.linkedin.com/company/yourbrand",
    "https://www.facebook.com/yourbrand"
  ]
}Code language: JSON / JSON with Comments (json)

進階版裡多了兩個很有想法的欄位。一個是 knowsAbout，它讓你明確宣告品牌擅長的主題，這直接呼應 Google 評估內容時看的「專業度」；對 AI 搜尋系統來說，當它要判斷誰是某個題目的權威來源時，這就是一個現成的訊號。另一個是把 logo 從單純的網址，升級成帶有寬高的 ImageObject，讓 Google 更清楚這張圖的規格。

把這段 JSON-LD 放在哪裡？官方建議放在首頁，或是一個專門介紹品牌的單一頁面，例如「關於我們」。這個頁面在實體經營裡有個名字叫「Entity Home」——它是你所有品牌資料的權威源頭，日後不管是社群、新聞報導還是外部目錄，最好都連回這一頁。

為品牌再加一個人，Person Schema 怎麼補

光有 Organization 還缺一塊。Google 的知識圖譜很在意「人」這個維度，因為品牌背後的創辦人、執行長、長期作者，本身也都是可以被識別的實體。把 Person Schema 補上，等於替你的品牌再拉一條關係線，讓整張實體圖更立體。

Person Schema 的用途主要有兩種。一種是宣告品牌與某個人的關係，例如誰是創辦人；前面進階版範本裡那個 founder 欄位，其實就是內嵌的一個迷你 Person。另一種更常被忽略，是替文章標註作者——用 Person Schema 告訴 Google 每篇文章是誰寫的，讓這個作者名在整個網路上累積專業與信任，文章自然也跟著沾光。

一段獨立的 Person Schema 大致長這樣，重點同樣在 @id 和 sameAs：

{
  "@context": "https://schema.org",
  "@type": "Person",
  "@id": "https://www.yourbrand.com/#founder",
  "name": "創辦人姓名",
  "jobTitle": "創辦人暨執行長",
  "worksFor": { "@id": "https://www.yourbrand.com/#organization" },
  "sameAs": [
    "https://www.linkedin.com/in/founder-name",
    "https://twitter.com/founder"
  ]
}Code language: JSON / JSON with Comments (json)

注意 worksFor 用 @id 指回 Organization 的那個錨點，這一筆就把「人」和「品牌」兩個實體正式綁在一起。同樣地，這個人的 sameAs 要連到他真實、活躍的個人檔案，最好是 LinkedIn 這種職業身分明確的平台。要建立這個人的權威，光標記不夠，還得讓這個名字在網路上真的有互動——演講、受訪、被新聞提到，這些站外的足跡才是把作者實體養大的養分。

WordPress 上怎麼實際裝起來

如果你的網站跑在 WordPress 上，好消息是你有兩條路，不一定要會寫程式。

第一條、用 SEO 外掛設定。主流的 SEO 外掛通常都內建一塊「機構／網站」的結構化資料設定區，你只要在後台填入機構名稱、上傳 Logo、貼上社群帳號網址，它就會自動幫你產生對應的 JSON-LD，並插進每一頁。這條路最省事，也最不容易寫錯語法，是大多數人的首選。設定時要把握的重點和前面一致：名稱跟全站一致、Logo 網址正常、sameAs 只填你掌控的官方帳號。

第二條、手動貼程式碼。如果你想要完整掌控欄位，或外掛的設定不夠細，可以把前面那段完整 JSON-LD 直接貼進佈景主題的 header 區域。這裡有個一定要提醒的眉角——千萬不要直接改母主題的 header.php，因為主題一更新，你的程式碼就會被蓋掉。正確做法是透過子主題，或用「插入 header 程式碼」類型的外掛來放，這樣才不會在每次更新後白忙一場。

不管走哪一條，裝完都還沒結束，有兩個收尾動作要做。一是確認這段標記只放在該放的頁面（首頁或關於我們），不要整站每一頁都塞一份一模一樣的 Organization。二是檢查 Logo 那個圖片網址，用瀏覽器直接打開它，確定真的看得到圖、不是壞掉的連結——這是最常見、也最冤枉的失誤之一。

裝好之後怎麼驗證，又有哪些坑最常踩

寫好程式碼不等於做對，一定要驗證。Google 提供兩個官方工具：複合式搜尋結果測試（Rich Results Test）和 Search Console。最快的做法是把已經放上標記的網址貼進複合式搜尋結果測試跑一次，看它有沒有正確抓到你的 Organization，並把所有重大錯誤修掉。除了 Google 的工具，Schema.org 自己的標記驗證器（Schema Markup Validator）也能用來檢查語法層面的問題。

實務上最常見的坑有這幾個，裝之前先記著，可以少走很多冤枉路：

  1. JSON-LD 語法寫錯：少一個逗號、多一個括號，整段就失效。手寫的話特別容易中，貼進驗證工具是最快的檢查。
  2. Logo 網址 404：圖片搬家或路徑打錯，導致 Google 抓不到 Logo。
  3. sameAs 連到非官方或失效帳號：連到一個你控制不了、或早就停用的頁面，不但沒幫助還可能扣信任分。
  4. 整段標記偵測不到：有時只放最精簡的幾個欄位，工具會抓不到。補上 contactPoint 或 foundingDate 這類欄位，往往就能讓它正確辨識。
  5. 資訊前後不一致：網站、社群、商業目錄上的名稱、地址、電話對不起來。這就帶到下一個重點——一致性。

要提醒的是，就算驗證全綠、零錯誤，Google 也從不保證一定會生出知識面板。結構化資料是必要條件，不是充分條件。它能不能變成那張資訊卡，還要看後面幾塊地基有沒有一起到位。

想拿到知識面板，光靠 Schema 還不夠

這是最該被講清楚、卻最常被略過的一段——加了 Organization Schema，知識面板不會自動長出來。Google 的知識面板是綜合維基百科、Wikidata、各種可信第三方來源生成的，schema 只是把你這一側的訊號整理好遞上去，它幫得上忙，但不能單獨成事。

完整的品牌實體大致建立在三根支柱上，Organization Schema 是其中一根，另外兩根同樣不能少。

  1. 實體源頭（Entity Home）：也就是用 Organization Schema 定義品牌的那一頁，這你已經做了。
  2. 權威知識庫的存在：在維基百科或 Wikidata 上有一筆準確的條目。Wikidata 的門檻比維基百科低很多，是相對務實的起點——你可以建立並維護一筆描述自己品牌的結構化條目，再透過 sameAs 把它和官網串起來。
  3. 跨來源的一致品牌提及：在各種權威第三方來源裡，你的品牌資訊都一致地出現。

這裡頭有一條看似瑣碎、卻會默默拖垮整體信任的細節，叫 NAP 一致性——Name（名稱）、Address（地址）、Phone（電話）。你的商家資訊在所有平台上必須完全一致，哪怕是「股份有限公司」寫成「有限公司」、市話多寫一個區碼這種小差異，都可能讓 Google 懷疑這是不是同一個主體，進而降低它對你的信任。

如果你有實體據點，甚至只是有一個辦公地址，把 Google 商家檔案（Google Business Profile）建好、填完整、並連回你的 Entity Home，是性價比很高的一步。商家檔案本身就會出現在搜尋的知識面板、Google 地圖和在地搜尋結果裡，等於多一個和品牌實體互相佐證的官方版位。

也要先把預期校準好。知識圖譜重新處理、驗證這些新建立的資料連結，通常需要四到八週，有時更久，而且沒有保證的時間表。把該做的訊號都做齊之後，剩下的就是耐心，以及持續累積品牌在外部世界的真實足跡。

把品牌「登記」進機器的認知，越早越值得

設定 Organization Schema 這件事，本質上就是一次身分的交接——從「讓 Google 自己去猜你是誰」，轉成「你主動把答案遞給它」。在搜尋結果越來越多被 AI 直接生成、引用來源也越來越集中在它信得過的實體身上的此刻，這份主動權的價值只會越來越高。

它不是一個裝完當天就見效的開關，比較像替品牌打地基——埋下去當下看不出變化，但之後每一篇文章、每一個社群連結、每一次被外部提及，都會因為有了這根錨點而被算進同一個實體身上，慢慢累積成搜尋引擎和 AI 都認得的那個你。今天就先把名稱、官網、Logo、sameAs 這幾個最基本的欄位填對、填一致，讓機器第一次正式認識你，是任何品牌都不該再拖的一步。

延伸閱讀