Schema.org JSON-LD 完全手冊：2026 年台灣站長該裝哪些結構化資料、哪些已經沒用，附可直接複製的範本

CONTENTS · 目次

本文 10 個段落

§ 01 先講結論：Schema 在 2026 年到底還有什麼用？
§ 02 JSON-LD 是什麼？為什麼大家都用它
§ 03 2026 年哪些 schema 還有 rich result？哪些已經死了
§ 04 台灣站長最該先裝的三個 schema（附可複製範本）
§ 05 進階：用 @graph + @id 把實體串起來
§ 06 五個台灣站最常踩的 schema 錯誤
§ 07 怎麼驗證你的 schema 對不對？
§ 08 那 Schema 到底能不能讓 AI 引用我？
§ 09 常見問題
§ 10 結語：把 schema 當成「機器可讀層」，而不是魔法

先講一個很常見的場景。

某位台灣站長看了幾篇教學，知道「要加 schema」，於是用了一個外掛把 FAQPage、HowTo、Organization 一口氣全裝上去。裝完很有成就感，但過了一個月，Google 搜尋結果裡什麼變化都沒有，AI 也沒有比較常引用他。他開始懷疑：是不是我裝錯了？還是 schema 根本沒用？

兩個答案都不對。真正的情況是：他裝的東西裡，有一半在 2026 年已經不再產生任何效果了——而真正還有用的那幾個，他反而沒裝對。

這篇手冊要把這件事一次講清楚：結構化資料到底是什麼、2026 年哪些還活著哪些已經死了、台灣站長該優先裝哪幾個，以及——最重要的——怎麼確認你到底有沒有裝對。文章裡的每一段 JSON-LD 都可以直接複製改成你自己的。

先講結論：Schema 在 2026 年到底還有什麼用？

很多人對 schema 的期待是錯的。所以先把話講白：結構化資料在 2026 年有三個真實的用途，以及一個被嚴重高估的用途。

三個真實用途：

觸發 Google 的 rich result（複合式搜尋結果）：例如商品的星等評分、麵包屑路徑、文章的發布日期。這些是 schema 最確定、最看得到的回報。
建立實體（entity）認知：透過 Organization schema 加上 sameAs，你等於明確告訴 Google「我是這個品牌，我的官網、FB、IG 是這幾個」，幫助它把你接進知識圖譜（Knowledge Graph）。
提供機器可讀的事實層：搜尋引擎和 AI 不必猜，你的作者是誰、發布日期、價格、地址都用標準格式寫好了。這降低被誤讀的機率。

那個被高估的用途是：「裝了 schema，AI 就會引用我」。這個說法在 2026 年站不住腳，後面有一整段專門講。先記住一句話：schema 是讓機器「看懂」你，不是讓機器「偏愛」你。

JSON-LD 是什麼？為什麼大家都用它

結構化資料有三種寫法：JSON-LD、Microdata、RDFa。Google 三種都讀得懂，但官方明確推薦 JSON-LD，原因很單純：它跟你的網頁內容是分開的。

Microdata 和 RDFa 要把標記屬性直接塞進一個個 HTML 標籤裡，資料跟版面糾纏在一起，改版只要動到版型就很容易把標記弄壞，維護起來很痛苦。JSON-LD 則是一整塊獨立的 <script>，放在 <head>（放 <body> 也可以），跟你的版面完全分離、不影響畫面，要改就改那一塊，乾淨俐落。對用 Astro、Next.js 這類框架的站來說，JSON-LD 也最好用程式動態產生——把資料當變數帶進去，文章標題、日期一改，標記自動跟著更新，不用手動同步。

它長這樣：

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "白鹿數位",
  "url": "https://example.com.tw/"
}
</script>

三個一定要懂的關鍵字：

@context：固定寫 https://schema.org，告訴機器「接下來的詞彙都用 schema.org 這套字典解讀」。
@type：這個東西「是什麼」，例如 Organization（組織）、Article（文章）、Product（商品）。
其餘的 name、url、logo 這些叫 property（屬性），是這個型別底下可以填的欄位。

就這麼簡單。schema.org 的字典裡有 800 多種型別、上千個屬性，但你 99% 的時間只會用到其中不到 10 種。不用被嚇到。

2026 年哪些 schema 還有 rich result？哪些已經死了

這是最多人沒跟上的部分。Google 這兩年砍掉了一大批結構化資料功能，很多教學文章還停在 2023 年的資訊，照著做等於白做。

下面這張表是 2026 年 6 月的現況：

狀態	結構化資料型別	說明
✅ 還有 rich result	Product、Review／AggregateRating	商品星等、價格、庫存
✅ 還有 rich result	Article／BlogPosting／NewsArticle	文章發布日、作者、縮圖
✅ 還有 rich result	BreadcrumbList（麵包屑）	搜尋結果顯示路徑而非裸網址
✅ 還有 rich result	Organization、LocalBusiness	品牌資訊、知識面板、地方商家
✅ 還有 rich result	Recipe、Video、Event、JobPosting	食譜、影片、活動、職缺
❌ 已退場	FAQPage	2026 年 5 月 7 日起 rich result 完全消失
❌ 已退場	HowTo	桌機版 2023 年 9 月就移除了
❌ 已退場	Sitelinks 搜尋框（WebSite 的 SearchAction）	2026 年 1 月停用
❌ 已退場	2025 年 6 月一次砍 7 種	Book Actions、Course Info、Claim Review、Estimated Salary、Learning Video、Special Announcement、Vehicle Listing

關於已退場的部分，有三件事要特別提醒台灣站長：

第一，FAQPage 還是有很多人在拼命加，這是白工。 Google 在 2026 年 5 月 7 日正式宣布 FAQ rich result 不再出現於搜尋結果，Search Console 的 FAQ 報表 6 月退場、API 8 月停止支援。你的 FAQPage 標記不會出錯、驗證也會過，但它對搜尋結果的曝光貢獻是零。

第二，HowTo 也一樣。 桌機版 2023 年就移除了，現在加 HowTo schema 同樣拿不到任何 rich result。

第三，「驗證通過」不等於「有效果」。 這是最容易誤會的地方。FAQPage、HowTo 在 schema.org 的字典裡依然是合法型別，丟進驗證工具一定全綠。但「語法正確」和「Google 會拿它做出搜尋結果」是兩回事。⚠️ 不要看到驗證器一片綠就以為自己賺到了。

那已經裝了 FAQPage 要不要拆掉？Google 的官方立場是：沒在用的結構化資料不會對搜尋造成問題，但也沒有任何可見效果。 所以不急著拆，但也別再花時間擴充它。把力氣放在下面這三個還活著的。

台灣站長最該先裝的三個 schema（附可複製範本）

如果你的網站是內容站、服務業、個人品牌站、中小企業官網——也就是台灣絕大多數網站——那 ROI 最高的就是這三個：Organization、Article、BreadcrumbList。其他的（Product、Recipe、Event）等你真的有那類內容再加。

順帶一提，TWTools 三軸掃描器的 GEO「結構化資料」這項，計分邏輯剛好就是：有任何 JSON-LD 給基礎分，再依序看你有沒有 Organization、Article、BreadcrumbList、WebSite 各加分。所以把這三個裝好，這項分數會直接拉起來。

Organization：先讓 Google 知道你是誰

這是全站每一頁都該有的（或至少首頁）。它的核心任務是建立你的品牌實體，logo 決定知識面板顯示什麼圖，sameAs 把你的社群帳號串進知識圖譜。Google 官方說法是 Organization 沒有必填屬性，但建議盡量填，填越完整實體越清楚。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "白鹿數位",
  "url": "https://example.com.tw/",
  "logo": "https://example.com.tw/logo.png",
  "description": "專為台灣中小企業設計的數位行銷服務",
  "sameAs": [
    "https://www.facebook.com/yourpage",
    "https://www.instagram.com/yourpage",
    "https://www.linkedin.com/company/yourpage"
  ]
}
</script>

sameAs 是這段裡最被低估的一行。AI 引擎不看反向連結，它判斷「這個站可不可信」很大一部分靠的就是這種明確的實體訊號。把你經營的社群帳號全列上去，而且確保各平台的名稱、logo 一致——一致性越高，機器越容易確認「這些都是同一個品牌」。

Article／BlogPosting：每篇文章都該有

文章頁加這個，Google 才能穩定抓到發布日期、作者、縮圖。注意 author 必須是巢狀的 Person 或 Organization，不能只寫一個名字字串——這是最常見的錯誤之一。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "如何替台灣中小企業挑進銷存系統",
  "image": "https://example.com.tw/blog/erp-cover.jpg",
  "datePublished": "2026-06-05T08:00:00+08:00",
  "dateModified": "2026-06-05T08:00:00+08:00",
  "author": {
    "@type": "Person",
    "name": "王小明",
    "url": "https://example.com.tw/author/wang"
  },
  "publisher": {
    "@type": "Organization",
    "name": "白鹿數位",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com.tw/logo.png"
    }
  }
}
</script>

幾個台灣站常踩的細節：datePublished 的時間帶記得用 +08:00（台灣時區），不要直接複製範例的 UTC；headline 盡量控制在 110 字元內；dateModified 真的有改內容才更新，不要每天自動改——假裝「天天更新」騙不到搜尋引擎，反而可能被視為訊號雜訊。

BreadcrumbList：讓搜尋結果顯示路徑

麵包屑 rich result 是少數還活著、而且幾乎所有網站都適用的。它讓你的搜尋結果顯示「首頁 › 部落格 › 文章標題」而不是一串裸網址，提升點擊率。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "首頁",
      "item": "https://example.com.tw/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "部落格",
      "item": "https://example.com.tw/blog/"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "如何替台灣中小企業挑進銷存系統"
    }
  ]
}
</script>

注意最後一層（目前這一頁）不要填 item 網址，只留 name。這是 Google 的規範，最後一項代表使用者當前所在頁面，不需要連結。

額外加分：實體店家請改用 LocalBusiness

如果你不是純線上、而是有實體門市的台灣商家（餐廳、診所、補習班、工作室），那比起一般的 Organization，你更該用 LocalBusiness（或它底下更精確的子型別，例如 Restaurant、MedicalClinic）。它能多帶地址、營業時間、電話、座標這些在地資訊，對 Google 在地搜尋和地圖的呈現幫助很大。寫法跟 Organization 幾乎一樣，只是 @type 換掉、再多填 address、telephone、openingHours 這些欄位。一個店家同時想要品牌實體又想要在地呈現，把主體寫成 LocalBusiness 就一次涵蓋了，不必兩個都裝。

進階：用 @graph + @id 把實體串起來

當你同一頁有多個 schema（很正常：Organization + WebSite + 文章），與其分成三段各自獨立、Organization 在文章裡又重抄一遍，不如用 @graph 把它們放進同一個圖，再用 @id 互相指涉。每個實體只定義一次，其他地方用 @id 引用。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com.tw/#org",
      "name": "白鹿數位",
      "url": "https://example.com.tw/",
      "logo": "https://example.com.tw/logo.png",
      "sameAs": ["https://www.facebook.com/yourpage"]
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com.tw/#website",
      "url": "https://example.com.tw/",
      "name": "白鹿數位",
      "publisher": { "@id": "https://example.com.tw/#org" }
    },
    {
      "@type": "BlogPosting",
      "@id": "https://example.com.tw/blog/erp/#article",
      "headline": "如何替台灣中小企業挑進銷存系統",
      "datePublished": "2026-06-05T08:00:00+08:00",
      "author": { "@id": "https://example.com.tw/#org" },
      "publisher": { "@id": "https://example.com.tw/#org" },
      "isPartOf": { "@id": "https://example.com.tw/#website" }
    }
  ]
}
</script>

這裡的重點：

@context 在 @graph 最外層寫一次就好，裡面每個實體不用重複。
@id 是你自己在這份標記裡的內部識別碼（慣例用 網址#org 這種錨點寫法），讓不同實體可以互相指。BlogPosting 的 publisher 直接寫 { "@id": "...#org" }，不用把整個 Organization 再抄一遍。
串接外部實體時，如果你不確定對方有沒有維護那個 @id，記得保留 name 當後備，這樣就算 @id 指涉不到，關係還是清楚的。

要不要一定用 @graph？不一定。你也可以放好幾段獨立的 <script>，每段自己帶 @context，Google 兩種都吃。@graph 的好處是在實體關係複雜時更乾淨、更不容易自相矛盾。單純的小站，分開寫也完全沒問題。

五個台灣站最常踩的 schema 錯誤

錯誤 1：標記的內容畫面上看不到

Google 的政策寫得很明白：結構化資料必須代表頁面上「使用者看得到」的內容。你不能在 schema 裡寫一個價格、評分或答案，但畫面上根本沒有。這叫做「隱藏內容標記」，是會被當成違規的。同樣的道理也適用於 AI——它主要讀的是可見的 HTML，你藏在 JSON-LD 裡、畫面上卻沒有的東西，幫助有限。

錯誤 2：還在大力擴充 FAQPage

前面講過了，但值得再說一次，因為太多人卡在這。FAQPage 在 2026 年 5 月後沒有 rich result 了。把原本要塞進 FAQPage 的那些問答，改成頁面上看得到的問句小標 + 簡短直接回答，對 SEO、對 AI 引用都更實在。

錯誤 3：`author` 只寫字串

"author": "王小明"

❌ 上面這樣寫，Google 無法把它連到一個明確的人或組織實體。

"author": { "@type": "Person", "name": "王小明" }

✅ 一定要用巢狀的 Person 或 Organization。多打幾個字，差很多。

錯誤 4：沒有 sameAs，品牌實體建不起來

很多台灣中小企業官網有 logo、有 Organization，就是漏了 sameAs。結果 Google 知道「有這麼一個組織」，卻無法確認「它跟那個有 5 萬粉的 FB 粉專是同一個」。sameAs 是把這些分散的品牌資產綁成一個實體最直接的繩子。

錯誤 5：簡繁、語言訊號不一致

這是台灣獨有的坑。如果你的網站 <html lang> 寫 zh-TW，schema 裡的文字卻混了簡體，或者乾脆從中國的範本複製過來沒改，會讓機器對你的語言歸屬產生混淆。對 AI 引擎來說更嚴重——它可能在回答繁體中文問題時，因為判定你是簡中內容而略過你。TWTools 掃描器有內建繁中比例與簡繁混用偵測，就是專門抓這個。

怎麼驗證你的 schema 對不對？

裝完一定要驗。盲裝不驗，等於不知道自己有沒有裝對。2026 年有兩個官方等級的工具，分工不同，兩個都要用。

第一步：先用 Schema Markup Validator 驗語法

到 validator.schema.org，把你的 JSON-LD 貼進去或輸入網址。這個工具由 schema.org 維護，支援全部 800 多種型別，只看「你的語法合不合 schema.org 標準」，不管 Google 認不認。語法層的錯誤（拼錯屬性、結構錯誤、少了引號）這裡會抓出來。部署前先在這裡驗，最快。

第二步：再用 Google Rich Results Test 看能不能觸發 rich result

到 search.google.com/test/rich-results，輸入你的網址（或貼程式碼）。這個工具只認 Google 支援的那約 30 種 rich result 型別，而且會給你一個搜尋結果預覽，讓你看到實際長相。如果你裝的是 FAQPage，這裡會告訴你它偵測到了、但不會給預覽——因為已經沒有 rich result。這一步是確認「Google 端到底會不會拿它做出東西」。

第三步：上線後用 Search Console 追蹤

正式上線後，到 Google Search Console 的「結構化資料」相關報表，看 Google 實際爬取後有沒有偵測到、有沒有報錯。validator 是「理論上對不對」，GSC 是「Google 實際看到什麼」，兩者可能有時間差，以 GSC 為準。

⚠️ 注意：舊版的「結構化資料測試工具」（Structured Data Testing Tool）已經退役，網路上很多教學還在叫你用它，認明上面兩個新工具。

完整的健檢順序是：validator.schema.org 驗語法 → 部署到測試環境 → Rich Results Test 看預覽 → 上線後 GSC 追蹤。

那 Schema 到底能不能讓 AI 引用我？

這是最多人想問、也最多人被誤導的問題。直接給你 2026 年最可靠的答案。

網路上你會看到各種驚人數字：某個單站實驗說「加了 schema，Google AI Overview 引用暴增 611%」，另一個框架說「結構化資料帶來 39% 引用提升」。但同一批實驗裡，ChatGPT 的引用卻掉了 71%，Perplexity 的爬蟲根本抓不到測試頁。這些數字彼此矛盾、樣本又小，不能當成定論。

目前規模最大、最接近對照實驗的證據是 Ahrefs 在 2026 年 5 月 11 日發布的研究：他們追蹤了 1,885 個加上 schema 的頁面，結果發現 AI 引用「幾乎沒動」，AI Mode 和 ChatGPT 的變化被歸類為隨機雜訊。

怎麼解讀這個落差？業界目前的共識是：schema 是入場券（table stakes），不是制勝因子。 確實有研究指出被引用的頁面裡 81% 都有 schema，但這是相關不是因果——大型網站本來就既有 schema、又有權威內容，是後者讓它被引用。schema 是「該有的衛生條件」，但它本身不會把你推上去。

更根本的原因是：AI 引擎主要讀的是你頁面上可見的 HTML 文字，不是藏在 <head> 裡的 JSON-LD。所以決定你會不會被引用的，是內容本身寫得夠不夠好引用——結論先講、段落自足、有具體數字——而不是你多塞了幾段 schema。這部分我們在另一篇〈如何提高內容被 AI 引用的機率〉裡有完整拆解。

所以結論是：該裝 schema 嗎？該。 它能穩定拿到 Google 的 rich result、能建立品牌實體、能讓事實層機器可讀，這三件事都很實在。但別把它當成「讓 AI 引用我」的開關——那個開關在你的內容裡，不在你的 <script> 標籤裡。

常見問題

加了 schema 多久會看到效果？

要看 Google 重新爬取你的頁面，通常幾天到幾週。Rich result（如麵包屑、文章日期）出現後，你會在搜尋結果直接看到。但記住：schema 觸發的是「呈現方式」的改變，不是排名的暴漲，不要期待加了就流量翻倍。

schema 要放 `<head>` 還是 `<body>`？

兩個都可以，Google 都讀得到。慣例上放 <head> 比較乾淨、好管理。用 WordPress 的話，多數 SEO 外掛會自動幫你放對位置。

我用 WordPress／Wix，需要自己手寫 JSON-LD 嗎？

通常不用。WordPress 的 Yoast、Rank Math 等外掛會自動產生 Organization、Article、BreadcrumbList。你要做的是去外掛設定把品牌名稱、logo、社群連結（sameAs）填好，然後用驗證工具確認它產出的東西是對的。手寫只在你需要客製、或外掛產不出你要的型別時才需要。