Schema.org 進階 — 2026 真正影響 AI 引用的 schema type 與常見誤用

為什麼這篇必要：schema.org 的 90/10 法則

Schema.org 詞彙表有 800+ types。但實際上：

15 個 type 涵蓋 90% 的網站需求
錯誤使用 比沒用更糟（AI 偵測 schema 誤用會降權）
「完整度」勝過「多樣性」（5 個完整 schema > 20 個半完整）

下面拆 4 類真正有效的 schema、選擇邏輯、嵌套結構，與 5 個我見過的真實誤用案例。

第一類：實體類 schema — 任何網站必做

這類回答「這個網站背後是誰 / 什麼」。

Organization（公司 / 組織）

用在：首頁、about-us 頁

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "您的公司名稱",
  "alternateName": "Your Company",
  "url": "https://example.com",
  "logo": "https://example.com/logo.png",
  "foundingDate": "2018-03-15",
  "description": "B2B SaaS demand generation 行銷顧問",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "信義路五段 7 號",
    "addressLocality": "台北市",
    "postalCode": "110",
    "addressCountry": "TW"
  },
  "contactPoint": {
    "@type": "ContactPoint",
    "telephone": "+886-2-1234-5678",
    "contactType": "customer service",
    "email": "[email protected]"
  },
  "sameAs": [
    "https://www.linkedin.com/company/example",
    "https://twitter.com/example_tw",
    "https://www.crunchbase.com/organization/example"
  ]
}

關鍵欄位：

name + alternateName：中英文名都列，AI 跨語對齊
sameAs：跨平台官方頁，AI 對齊實體最關鍵的訊號
address + contactPoint：可驗證實體存在
foundingDate：時間錨點

LocalBusiness（實體店家 / 本地服務）

用在：本地服務、餐廳、診所、零售店等

延伸自 Organization，加：

openingHoursSpecification：營業時段
geo：經緯度
priceRange：價格區間（用 $、$$、$$$ 標記）

為什麼重要：本地搜尋與「附近的 X」這類查詢，AI 優先引用有 LocalBusiness schema 的結果。

Person（個人品牌 / 作者）

用在：個人官網、作者頁

{
  "@context": "https://schema.org",
  "@type": "Person",
  "name": "陳大華",
  "jobTitle": "B2B 行銷顧問",
  "worksFor": {
    "@type": "Organization",
    "name": "您的公司名稱",
    "url": "https://example.com"
  },
  "alumniOf": "國立台灣大學",
  "image": "https://example.com/photo.jpg",
  "url": "https://example.com/about",
  "sameAs": [
    "https://www.linkedin.com/in/daihua-chen",
    "https://github.com/daihua",
    "https://medium.com/@daihua"
  ]
}

詳見：個人品牌 / 自由工作者的 GEO 起步。

WebSite

用在：首頁

{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "url": "https://example.com",
  "name": "您的公司名稱",
  "potentialAction": {
    "@type": "SearchAction",
    "target": "https://example.com/search?q={search_term_string}",
    "query-input": "required name=search_term_string"
  }
}

為什麼重要：SearchAction 讓 AI 知道你的站內搜尋怎麼操作，部分 AI Agent 在處理「在某網站找 X」這類請求時會呼叫。

第二類：內容類 schema — 內容站必做

Article / BlogPosting / NewsArticle 三選一

三者繼承關係：

CreativeWork
  └── Article
       ├── BlogPosting       ← 部落格用
       ├── NewsArticle       ← 新聞用
       └── ScholarlyArticle  ← 學術用

怎麼選：

部落格 / 心得文 → BlogPosting
新聞報導 / 時事 → NewsArticle
不確定 → 用 Article（最通用）

完整 Article schema

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "10 個 GEO 常見迷思",
  "description": "本文拆 10 個常見 GEO 迷思...",
  "image": "https://example.com/blog/myths-hero.png",
  "author": {
    "@type": "Person",
    "name": "陳大華",
    "url": "https://example.com/author/daihua"
  },
  "publisher": {
    "@type": "Organization",
    "name": "您的公司名稱",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/logo.png"
    }
  },
  "datePublished": "2026-04-30T08:00:00+08:00",
  "dateModified": "2026-04-30T08:00:00+08:00",
  "mainEntityOfPage": "https://example.com/blog/post-1",
  "wordCount": 2400
}

最常被忽略的關鍵欄位：

author 必須是 Person 物件（不是字串）+ 含 url 連到作者頁
datePublished + dateModified 兩個都要
mainEntityOfPage 指回該文章的 canonical URL

WebPage（一般頁面）

用在：非文章類的內容頁（產品介紹、服務、定價、about）

{
  "@context": "https://schema.org",
  "@type": "WebPage",
  "name": "服務介紹 - B2B SaaS demand generation",
  "description": "...",
  "url": "https://example.com/services",
  "isPartOf": {
    "@type": "WebSite",
    "url": "https://example.com"
  },
  "breadcrumb": {
    "@type": "BreadcrumbList",
    "itemListElement": [
      {"@type": "ListItem", "position": 1, "name": "首頁", "item": "https://example.com"},
      {"@type": "ListItem", "position": 2, "name": "服務", "item": "https://example.com/services"}
    ]
  }
}

第三類：商品 / 評論類 — 電商必做

Product + Offer + AggregateRating 三件套

這三個必須一起做——只做 Product 缺價格、缺評分對 AI 商品推薦幫助有限。

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "[產品名] CRM 標準版",
  "image": ["https://example.com/products/crm-1.jpg"],
  "description": "中小企業適用的客戶管理系統，含潛客、商機、自動化。",
  "sku": "CRM-STD-001",
  "brand": {
    "@type": "Brand",
    "name": "您的公司名稱"
  },
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/products/crm-standard",
    "priceCurrency": "TWD",
    "price": "9900",
    "priceValidUntil": "2026-12-31",
    "availability": "https://schema.org/InStock",
    "seller": {
      "@type": "Organization",
      "name": "您的公司名稱"
    }
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.6",
    "reviewCount": "127"
  },
  "review": [
    {
      "@type": "Review",
      "author": {"@type": "Person", "name": "王大明"},
      "datePublished": "2025-12-15",
      "reviewRating": {
        "@type": "Rating",
        "ratingValue": "5"
      },
      "reviewBody": "導入後 6 個月業務循環縮短 25%..."
    }
  ]
}

為什麼這個組合特別關鍵

當使用者問「X 工具推薦」「Y 軟體有哪些」時，AI 優先選擇有 Product + Offer + AggregateRating 三件套的選項——因為 AI 可以直接回答：

是什麼？（Product.name + description）
多少錢？（Offer.price）
評價如何？（AggregateRating.ratingValue）
在哪買？（Offer.url）

純 HTML 介紹頁缺這些結構，AI 切片時答不出完整資訊。

第四類：操作 / 流程類 — 教學內容必做

HowTo（教學步驟）

{
  "@context": "https://schema.org",
  "@type": "HowTo",
  "name": "如何在 30 分鐘內設定 robots.txt 開放 AI 爬蟲",
  "description": "完整步驟引導...",
  "totalTime": "PT30M",
  "supply": [
    {"@type": "HowToSupply", "name": "你的網站 robots.txt 檔案存取權"}
  ],
  "tool": [
    {"@type": "HowToTool", "name": "文字編輯器"}
  ],
  "step": [
    {
      "@type": "HowToStep",
      "name": "找到 robots.txt 位置",
      "text": "進入網站根目錄...",
      "url": "https://example.com/blog/robots#step1"
    },
    {
      "@type": "HowToStep",
      "name": "加入 AI bot 開放規則",
      "text": "貼上以下內容..."
    }
  ]
}

FAQPage

FAQPage 已經在前篇深度討論過：FAQPage 與 Q&A 結構深度設計（VIP）。

重點：mainEntity 陣列每個 Question 必須含完整 acceptedAnswer.text，不可空字串。

Course（課程）

用在：線上課程平台、教育機構

{
  "@context": "https://schema.org",
  "@type": "Course",
  "name": "GEO 30 天起步課程",
  "description": "從零開始建立 GEO 月度節奏",
  "provider": {
    "@type": "Organization",
    "name": "您的公司名稱",
    "url": "https://example.com"
  },
  "hasCourseInstance": {
    "@type": "CourseInstance",
    "courseMode": "online",
    "duration": "P30D"
  }
}

5 個真實誤用案例

下面是業界實際踩過的雷（依 AI 整理常見 schema 誤用案例）。

誤用 1：產品頁同時加 Product 與 Article schema

情境：客戶想「同時拿產品搜尋與內容搜尋的好處」，在每個產品頁加兩種 schema。

問題： - 同一頁面 schema 類型衝突 - AI 不確定該頁是「產品介紹」還是「文章評測」 - Google 會直接拒絕 rich result 顯示

修法：選一個。產品頁就用 Product，介紹文章頁用 Article。一個頁面一個身份。

誤用 2：把整站所有頁面都標成 NewsArticle

情境：「我們是內容公司，全部都是新聞文章」——但實際上有產品介紹、服務頁、定價頁也標 NewsArticle。

問題： - 服務頁標 NewsArticle 是 schema 誤用（服務頁不是新聞） - AI 偵測到不一致整站降權 - Google 可能直接 manual action 處罰

修法：依頁面類型選對應 schema：產品頁 Product、服務頁 WebPage、新聞文章才用 NewsArticle。

誤用 3：AggregateRating 數字造假

情境：產品頁加 "ratingValue": "5.0", "reviewCount": "1000" 但實際上沒有 1000 條評論。

問題： - 使用者點進來看不到對應評論 → AI 偵測到不一致 - Google 對「rating spam」有 manual action - AI 對該網站的 schema 信任度永久下降

修法：數字必須對應頁面實際展示的評論。沒評論就不要加 AggregateRating，加了也是負面訊號。

誤用 4：Organization schema 的 sameAs 列入過時 / 錯誤連結

情境：sameAs 列了 5 年前的 Twitter 帳號（已停用）、改名前的 LinkedIn 公司頁、不存在的 Crunchbase 條目。

問題： - AI 跨平台對齊時跑去那些連結，發現 404 或內容不符 - 整體實體訊號可信度下降

修法：sameAs 每年檢查一次。寧可少列也不要列錯。

誤用 5：Article schema 的 author 用字串而非 Person 物件

情境：

"author": "陳大華"  ❌ 字串

"author": {                      ✅ 物件
  "@type": "Person",
  "name": "陳大華",
  "url": "https://example.com/author/daihua"
}

問題： - 字串版本 AI 無法跟你網站作者頁對應 - 跨文章的「同作者」識別失敗 - 整站 E-E-A-T 累積分散

修法：author 永遠用 Person 物件 + 包含 url 連回作者頁。

進階：嵌套結構與 @id 引用

當你網站累積很多 schema，會遇到「同一個 Person 在多個 Article 出現」、「同一個 Organization 在多頁出現」的情況。每個地方都重複定義不優雅，且 AI 可能視為不同實體。

用 @id 統一指涉：

在 Person 主定義（作者頁）：

{
  "@type": "Person",
  "@id": "https://example.com/author/daihua#person",
  "name": "陳大華",
  ...完整資訊...
}

在 Article schema 引用：

"author": {
  "@id": "https://example.com/author/daihua#person"
}

好處：

AI 把所有引用同一 @id 的視為同實體
維護只需在一處更新
減少重複資料

第一步：跑 schema validator 看你網站的 schema 健康度

兩個免費工具：

Google Rich Results Test — 看 Google 端解讀
Schema Markup Validator — 看純 schema.org 規範

跑你首頁 + 5 個重要頁面，檢查：

所有 schema 都通過驗證
沒有錯誤的 type 嵌套
沒有過期的 sameAs 連結

👉 GeoWeb 健檢的「結構化資料」維度會自動掃出最常見的 schema 問題。

範例 schema 是骨架，不是套版可貼即用——實際部署涉及：你產業適合哪個 type 組合、跨頁 @id 體系設計、CMS / 後端動態生成 schema、與既有 SEO 結構整合、定期驗證避免漂移。多數企業選擇 GEO 託管把這部分一次做齊，避免半年後發現 schema 寫錯整站 rich result 失效：[email protected]

GEO 進階系列。前一篇：「LLM 引用偏好的 5 個內容特徵」