Schema 中文意思怎麼分？進階結構化資料類型、用途與判斷流程

Schema 中文怎麼翻？先判斷你問的是哪一種 Schema

schema 中文常見翻譯是「模式」、「架構」或「綱要」；在 SEO 場景，多半指 Schema.org 結構化資料標記，用來協助搜尋引擎理解頁面內容。

schema 常見中文翻譯：模式、架構、綱要

Schema 不是只有一種中文意思。單看英文單字時，它接近「模式」或「綱要」；放到工程語境，常被翻成「資料庫架構」；放到 SEO 語境，台灣團隊通常會直接說「Schema 標記」或「結構化資料」。

我會先看討論對象。如果對方在談 MySQL、資料表、欄位關聯，那是資料庫 schema；如果在談 Google 搜尋結果、JSON-LD、rich results，那幾乎就是 SEO Schema。這個分流很重要，因為兩者的實作目標完全不同。

英文單字、資料庫 Schema、SEO Schema、JSON Schema 差在哪

英文單字的 schema 是抽象概念；資料庫 schema 是資料儲存設計；SEO Schema 是網頁給搜尋引擎看的語意標記；JSON Schema 則用來檢查 JSON 格式是否符合規範。四者都和「架構」有關，但應用位置不同。

SEO 實務上最常見的誤會，是把 JSON Schema 和 Schema.org 混在一起。JSON-LD 是一種把 Schema.org 寫進網頁的格式，JSON Schema 是驗證 JSON 資料結構的規格，兩者名字相近，工作目標不同。

台灣 SEO 團隊說的 Schema 多半指結構化資料標記

在台灣 SEO 專案裡，如果有人說「這頁要補 Schema」，通常不是要你設計資料表，而是要補 Article、Breadcrumb、Organization、Product、VideoObject 這類 Schema.org 結構化資料。這也是「schema 中文」這個查詢真正值得往下看的地方。

SEO 裡的 Schema 是什麼？和 Schema.org、JSON-LD 有什麼關係

SEO 裡的 Schema 是用 Schema.org 詞彙描述網頁內容的結構化資料，常用 JSON-LD 寫在頁面中，讓 Google 等搜尋引擎更容易理解頁面類型、實體與屬性。

Schema.org 是詞彙表，不是 Google 專屬外掛

Schema.org 是由搜尋與網路生態共同維護的結構化資料詞彙，涵蓋人物、組織、商品、活動、影片、文章、在地商家等實體。它提供的是共用語彙，不是某個 CMS 外掛。

這一點會影響決策。Schema.org 有很多類型，但 Google 搜尋不會把所有類型都顯示成 rich result。9iseo 在做 Schema 規劃時，不會先問「Schema.org 有沒有這個類型」，而會先問「Google 搜尋是否支援這種呈現，頁面內容是否撐得住」。

JSON-LD 是常見寫法，Schema.org 是語彙來源

JSON-LD 是把結構化資料寫進網頁的一種格式。Schema.org 提供 @type、name、url、author、publisher、sameAs 等語彙，JSON-LD 則負責用 JSON 形式把這些語彙整理成搜尋引擎能讀的標記。

Google 支援的搜尋呈現不等於 Schema.org 所有類型都會顯示

Google 官方說明指出，結構化資料可協助 Google 理解頁面，也可能讓內容符合 richer appearance 的資格，但實際搜尋呈現以 Search Gallery 支援類型、必要欄位與品質準則為準。這裡最容易犯的錯，是看到 Schema.org 有某個類型，就期待 Google 一定會在搜尋結果顯示特殊樣式。

除了 Article Schema，還有哪些進階 Schema 能提升搜尋呈現？

Article Schema 只是文章頁的基礎起點；更有搜尋呈現價值的進階 Schema，通常是 Breadcrumb、Organization、ProfilePage、Product、VideoObject、Event、LocalBusiness 等類型。

導航與信任型：Breadcrumb、Organization、ProfilePage

Breadcrumb Schema 用來描述頁面在網站階層中的位置，能讓搜尋結果更清楚呈現分類脈絡。對文章站、知識庫、服務頁來說，Breadcrumb 往往比多塞一段 FAQPage 更穩。

Organization Schema 描述品牌或公司實體，例如名稱、網址、Logo、聯絡資訊與 sameAs。ProfilePage 則適合作者頁、專家頁、品牌人物頁，讓人物或組織和網站內容之間的關係更清楚。對 2026 的 SEO 來說，作者與品牌實體比單頁小技巧更值得補。

內容強化型：VideoObject、Dataset、Course、DiscussionForumPosting、QAPage

VideoObject Schema 實作教學適合頁面真的有影片，且影片有標題、縮圖、上傳日期、描述與嵌入位置。Dataset 適合研究資料、統計資料、開放資料集，不適合一般部落格硬套。Course 適合課程清單或教育內容，DiscussionForumPosting 與 QAPage 則適合論壇討論與問答頁。

內容強化型 Schema 的共同前提，是頁面本身真的有對應內容。沒有影片就不要標 VideoObject，沒有資料集就不要標 Dataset。這句話看似基本，但很多網站的 Schema 失敗都卡在這裡。

商業轉換型：Product、Review、MerchantReturnPolicy、LocalBusiness、Event

Product Schema 可描述商品名稱、價格、庫存、評價與 offer；Review snippet 可處理符合規範的評論或評分；MerchantReturnPolicy 可補商家退貨政策；LocalBusiness Schema 教學指出，LocalBusiness 適合有明確地點或服務區域的在地商家；Event 則適合有日期、地點、票務或活動狀態的頁面。

這些類型最接近業務結果，但也最容易誤用。商品頁沒有價格與庫存，不該硬上 Product；服務頁沒有公開評價，不該自行產生 rating；活動頁沒有清楚日期與地點，Event Schema 只會增加維護風險。

9iseo 優先建議：先補站點信任與頁面脈絡，再做特殊 rich result

我不建議一開始就追最花俏的 rich result。多數網站先把 Breadcrumb、Organization、作者或 ProfilePage 補好，讓站點、頁面、作者、品牌之間的關係變清楚，再依商品、影片、活動、在地商家等頁面類型追加 Schema，效果比較穩，也比較不容易製造錯誤。

怎麼決定要加哪一種 Schema？用頁面類型與商業目的分流

選 Schema 先看頁面類型，再看商業目的與可見內容；有明確頁面內容與 Google 支援搜尋呈現的類型，才值得排進進階 Schema 導入清單。

如果是文章頁：Article 只是起點，Breadcrumb 與作者/組織訊號要補齊

文章頁可以先處理 Article Schema，但它不該是終點。對內容站來說，更完整的做法是讓文章頁同時有 Article、Breadcrumb、author、publisher，並連到清楚的作者頁或品牌頁。

如果作者是 Kevin Lin，作者頁應該有可見簡介、專長主題、相關文章、社群或可信外部資料，再用 ProfilePage 或 Person 相關屬性輔助。這會比每篇文章都塞 FAQPage 更符合長期內容資產的方向。

如果是商品或服務頁：Product、Review、Offer、LocalBusiness 要看內容是否真的存在

商品頁有價格、庫存、規格、圖片與購買條件，才有 Product 與 Offer 的基礎。服務頁如果沒有標準化價格或線上下單流程，硬套 Product 反而容易失真；在地服務業更常需要 LocalBusiness、Organization、Service 類型搭配頁面內容。

Review Schema 與 rating 更要保守。頁面上沒有公開可見的評論來源，不要在 JSON-LD 裡標出不存在的評分。這不是技術問題，是信任問題。

如果是 AI 搜尋與品牌信任：Organization、ProfilePage、sameAs 要對齊作者與品牌實體

AI 搜尋與品牌理解更在意實體是否穩定。Organization、ProfilePage、sameAs、author、publisher 這些欄位，應該和站內作者頁、關於頁、社群頁、商業登記資料或外部品牌頁一致。可延伸閱讀 作者頁 SEO 與 AI SEO / GEO 策略。

• 頁面上看不到的資訊，不標。
• Google Search Gallery 沒有支援的搜尋呈現，不當成主要投資理由。
• 需要頻繁變動的欄位，例如價格、庫存、活動日期，要有維護機制。
• 先做全站共用的信任與導航，再做單頁特殊類型。

JSON-LD 最小實作範例：一眼看懂 @type、屬性與頁面內容對應

JSON-LD 實作重點不是把欄位塞滿，而是讓 @type、name、url、author、publisher、sameAs、breadcrumb 等屬性能對應頁面可見內容與站點資料。

Organization + WebSite 最小範例

Organization + WebSite 適合放在首頁或全站模板，用來描述品牌、網站與官方連結。範例中的名稱、網址、Logo、sameAs，都應該和網站上的關於頁、頁尾、社群連結保持一致。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://9iseo.com.tw/#organization",
      "name": "9iseo",
      "url": "https://9iseo.com.tw/",
      "logo": "https://9iseo.com.tw/logo.png",
      "sameAs": [
        "https://www.facebook.com/9iseo"
      ]
    },
    {
      "@type": "WebSite",
      "@id": "https://9iseo.com.tw/#website",
      "url": "https://9iseo.com.tw/",
      "name": "9iseo",
      "publisher": {
        "@id": "https://9iseo.com.tw/#organization"
      }
    }
  ]
}
</script>

BreadcrumbList 最小範例

BreadcrumbList 適合每個文章頁、分類頁、商品頁或服務頁。它描述的不是設計上的麵包屑樣式，而是頁面在網站階層中的位置，所以 itemListElement 的順序要和實際導覽一致。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "首頁",
      "item": "https://9iseo.com.tw/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "文章",
      "item": "https://9iseo.com.tw/articles"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "Schema 中文完整說明",
      "item": "https://9iseo.com.tw/articles/schema-zh-tw"
    }
  ]
}
</script>

每個欄位都要能在頁面或站點資料中被驗證

Google 文件明確提醒，結構化資料應描述該頁內容，不要加入使用者看不到的資訊。實作時可以用下表檢查欄位來源。

進階 Schema 常見錯誤：為什麼有標記也沒有 rich result

有 Schema 標記不代表一定出現 rich result；常見原因包括 JSON 格式錯誤、必要欄位缺漏、內容與標記不一致、類型不受支援或 Google 選擇不顯示。

技術錯誤：JSON 格式、巢狀、URL、日期格式

技術錯誤通常最容易修。常見狀況包含逗號多打、引號錯誤、@graph 巢狀關係混亂、URL 使用測試站、日期格式不符合 ISO 標準、Product 缺 offer 或 Event 缺 startDate。這類問題應先用 Rich Results Test 檢查。

內容錯誤：標記了頁面沒有顯示的資訊

內容錯誤更傷信任。頁面沒有評論，卻標 aggregateRating；頁面沒有影片，卻標 VideoObject；活動已過期，Event 狀態仍是開放報名。Google 官方說明也要求結構化資料描述該頁可見內容，這不是可有可無的建議。

策略錯誤：選了 Google 不支援或顯示機率低的類型

策略錯誤最常發生在「別人說有用」的 Schema 清單。Schema.org 支援很多類型，但 Google 搜尋呈現以 Search Gallery 與各類型文件為準。驗證通過，只代表語法和部分欄位符合條件，不代表搜尋結果一定顯示。

2026 應避開的 Schema 迷思：FAQ、HowTo、排名提升與 AI 搜尋

2026 做 Schema 不該再把 FAQPage、HowTo Schema 或「加標記就提升排名」當主策略；進階 Schema 的價值在於降低搜尋引擎理解成本與補強可信實體。

FAQPage 不該再被當成通用 CTR 技巧

Google 在 2023 年調整 FAQ Schema rich results 顯示方式，FAQPage rich results 主要保留給權威政府與健康網站，其他網站不再規律顯示。一般商業網站仍可保留真實 FAQ 內容，但不應把 FAQPage 當成通用 CTR 手段。

HowTo 不適合當 2026 的主要 Schema 投資理由

HowTo rich results 在 Google 搜尋的能見度已大幅退場，官方在 2023 年 9 月後也明確說明桌機端不再顯示 How-to rich results。教學內容仍然值得寫，但投資理由應該是內容價值、索引品質與轉換，而不是期待 HowTo 樣式回來。

進階 Schema 的價值是降低理解成本，不是偷排名

Schema markup 不是排名保證。Google 會用結構化資料理解頁面內容、人物、公司、商品與活動，也可能用來產生 rich result 資格，但排名仍受內容品質、查詢意圖、頁面體驗、連結、品牌與整體網站信任影響。把 Schema 當成語意基礎建設，會比把它當小技巧更接近實務。

9iseo 建議的進階 Schema 推進順序

進階 Schema 建議先做 Article、Breadcrumb、Organization，再補作者與品牌實體，最後依頁面類型加入 Product、Video、Event、LocalBusiness 等特殊類型。

第一階段：Article + Breadcrumb + Organization

內容型網站的第一階段，先把文章頁基礎、頁面階層與品牌實體補齊。Article 負責文章內容，Breadcrumb 負責路徑脈絡，Organization 負責品牌識別。這三個完成後，網站的基本語意架構會穩很多。

第二階段：作者頁與品牌實體補強

第二階段處理作者與品牌關係。作者頁要有簡介、專長、文章列表、外部 sameAs；品牌頁要有組織名稱、網址、Logo、聯絡方式與官方連結。這部分常被低估，但它會影響搜尋引擎如何理解「誰在說這件事」。

第三階段：依頁面型態加 Product、Video、Event、LocalBusiness

第三階段才看特殊頁面。電商與 SaaS 方案頁評估 Product、Offer、Review；影片內容評估 VideoObject；講座、課程發表會評估 Event；有門市或服務區域的商家評估 LocalBusiness。沒有對應頁面，不需要為了清單完整硬做。

第四階段：Rich Results Test + Search Console 持續檢查

第四階段是驗證與監測。開發時用 Rich Results Test 檢查語法與資格，上線後用 Search Console 的 enhancement report 觀察錯誤、有效項目與搜尋呈現。Schema 不是一次性貼碼，模板、外掛、價格、活動日期、作者頁改版都可能讓標記失準。

FAQ：schema 中文與進階 Schema 常見問題

schema 中文最常見的問題，通常卡在詞義、SEO Schema.org、JSON-LD 實作與 rich result 期待；先分清語境，才知道該看字典、資料庫，還是 SEO 結構化資料。

結論：進階 Schema 是搜尋理解層，不是排名捷徑

進階 Schema 結構化資料的重點，是讓搜尋引擎更清楚理解頁面、作者、品牌、商品、影片、活動與在地資訊，而不是保證排名上升。Article Schema 做完後，9iseo 會優先補 Breadcrumb、Organization、作者或 ProfilePage，再依頁面型態加入 Product、VideoObject、Event、LocalBusiness。每一個欄位都要有可見內容支撐，並用 Rich Results Test 與 Search Console 持續檢查，這才是 2026 比較穩的 Schema 推進方式。