哪些 schema.org 類型實際會影響搜尋結果

簡短答案

schema.org 標記不會自動提升排名。不過，它可以讓頁面具備顯示強化搜尋外觀的資格：豐富搜尋結果、產品面板、麵包屑、活動列表、職缺模組、影片預覽，以及類似功能。

這個區別很重要。schema.org 是一套用來描述網路事物的廣泛詞彙。搜尋引擎只支援其中一部分，而且每一種搜尋功能都有自己的規則。你可以用 Thing、CreativeWork 或 Service 完美標記一個頁面，卻在搜尋結果中看不到任何可見變化，因為可能沒有任何搜尋功能與該類型綁定。

所以有用的問題不是「有哪些 schema 類型？」而是「搜尋引擎會使用哪些 schema 類型來產生可見或可運作的搜尋功能？」

以下是實務上的答案。

首先：結構化資料是資格，不是權利

結構化資料提供搜尋引擎明確線索。它不會強迫搜尋引擎顯示任何內容。

頁面通常需要符合以下所有條件，結構化資料才可能產生可見效果：

• 標記必須符合頁面上可見的內容。
• 必要與建議屬性必須存在。
• 頁面必須可被索引，且未被 robots 規則封鎖。
• 內容必須符合品質與垃圾內容政策。
• 搜尋引擎必須判斷強化結果對使用者有幫助。

這也是為什麼兩個技術上有效的頁面，在搜尋中的表現可能不同。其中一個可能取得產品豐富搜尋結果；另一個可能只顯示為普通的藍色連結。標記只是其中一項輸入。

這也說明了，追逐冷門 schema 類型通常不是善用時間。如果某個類型沒有對應的受支援搜尋功能，其好處多半是語意層面的，而不是視覺層面的。

影響最明確的類型

Product、Offer、AggregateRating 與 Review

對電子商務與軟體頁面而言，產品標記是最具可見用途的結構化資料家族之一。

Product 頁面可以具備顯示價格、庫存狀態、評分、運送、退貨與商家列表功能的資格。最重要的支援類型通常是：

• Offer，用於價格、幣別、庫存狀態與賣家資訊
• AggregateRating，用於彙總評分
• Review，在適當情況下用於個別評論
• Brand 或 Organization，用於製造商或賣家脈絡

當頁面真正是關於某個特定產品，而不是分類頁或模糊的服務頁時，這類標記最有用。搜尋引擎對評論與評分濫用越來越嚴格，尤其是自利性評論。如果評分沒有在頁面上對使用者可見，就不要標記它。

產品 schema 可以影響傳統自然搜尋摘要，也可以影響商家風格的版面。對零售商而言，這通常是投資報酬最高的結構化資料實作之一。

BreadcrumbList

BreadcrumbList 並不華麗，但很實用。它可以影響搜尋結果中的 URL／路徑顯示，用更清楚的階層取代雜亂的 URL。

麵包屑標記適合用於：

• 電子商務分類頁與產品頁
• 文件網站
• 大型部落格與出版網站
• SaaS 說明中心

它很少創造戲劇性的豐富搜尋結果，但可以改善理解。使用者在點擊前就能看出頁面位於哪個位置。搜尋引擎也能更清楚掌握網站結構。

如果你的網站有較深的導覽層級，麵包屑標記值得及早處理。

Article、NewsArticle 與 BlogPosting

Article、NewsArticle 與 BlogPosting 可以幫助搜尋引擎理解標題、作者、日期、圖片與發布者資訊。對出版者而言，這可能影響文章導向功能的資格，尤其是與良好的可爬取性、新鮮度與內容品質搭配時。

不要期待 article schema 把一篇普通部落格文章變成新聞結果。它無法彌補薄弱的報導、缺少作者資訊或內容貧乏的問題。

話雖如此，文章標記對編輯型網站仍然合理。用它來讓基本事實明確無歧義：

• 標題
• 作者或組織
• 發布日期與修改日期
• 主要圖片
• 發布者
• 正規 URL

如果你的團隊使用 AI 輔助發布，結構化資料不能取代揭露或編輯責任。我們在 小型網站上誠實的 AI 揭露應該是什麼樣子 中討論過人的那一面。搜尋系統可能會解析你的標記，但讀者評斷的是頁面本身。

LocalBusiness 及其子類型

對地方型組織而言，LocalBusiness 及其子類型——例如 Restaurant、Dentist、Store 或 ProfessionalService——可以幫助網站連結到商家事實：名稱、地址、電話號碼、營業時間、地理座標與 same-as 個人檔案。

其可見影響比產品或食譜標記更難預測，因為地方搜尋高度依賴商家列表、距離、知名度、評論與使用者意圖。不過，一致的地方商家標記仍然是有用的基本整理。

請將它用在代表該商家地點的頁面上，而不是隨機加到每一篇部落格文章。如果你有多個地點，請用各自的地址與營業時間標記每個地點頁面。

Event

Event 標記可以讓符合資格的頁面，在活動相關搜尋功能中顯示日期、地點與票務資訊。

這適合用於：

• 演唱會
• 研討會
• 網路研討會
• 課程
• 節慶
• 社群活動

關鍵在於具體性。關於「我們的年度訓練計畫」的頁面，並不等同於一個有日期活動頁，後者應有開始時間、地點、主辦者與參與模式。

對線上活動，請加入虛擬參與細節。對實體活動，請加入場地資訊。請持續更新取消、延期與改期的活動；過期的活動標記比沒有標記更糟。

JobPosting

JobPosting 是結構化資料驅動特定搜尋體驗最清楚的例子之一。正確標記的職缺頁面可以具備顯示在職缺搜尋功能中的資格，包括職稱、地點、薪資、雇用類型與發布日期。

這種標記只適用於實際的職缺發布頁。不要將它套用到列出多個職位但沒有獨立詳細頁的一般徵才頁。

重要欄位包括：

• 職稱
• 招募組織
• 地點或遠端狀態
• 發布日期
• 有效期限
• 雇用類型
• 薪酬，如有提供

過期職缺應移除、適當重新導向，或標記為不再有效。搜尋引擎不喜歡把使用者送到已失效的職缺頁。

Recipe

Recipe 標記仍是經典的豐富搜尋結果案例之一。它可以影響圖片縮圖、評分、烹調時間、食材、營養資訊與引導式食譜體驗。

它也是結構化資料最常被濫用的領域之一。如果頁面主要是一篇個人散文，食譜埋在底部，標記仍必須準確描述可見的食譜。結構化資料不應宣稱準備時間是五分鐘，但指示內容卻顯示並非如此。

食譜頁面通常大量使用圖片，因此結構化資料只是工作的一部分。良好的圖片、合理的壓縮與有用的 alt 文字都很重要。如果你正在整理食物、產品或編輯圖片，2026 年圖片 alt 文字實用指南 會是 schema 工作的實用搭配。

VideoObject

VideoObject 標記可以影響影片預覽、關鍵時刻、縮圖、長度、上傳日期與影片索引。當影片是頁面有意義的一部分，而不是底部偶然嵌入的內容時，它很有用。

至少請提供：

• 名稱
• 描述
• 縮圖 URL
• 上傳日期
• 長度
• 嵌入或內容 URL

對教學或長篇影片，關鍵時刻可以幫助搜尋引擎理解影片段落。這可以改善影片在搜尋中的呈現方式；但同樣地，這不保證版位。

Organization、Logo 與 WebSite

Organization 標記有助於定義網站背後的實體。WebSite 可以支援網站層級的理解，並且在某些情況下，當搜尋引擎選擇顯示時，可支援站內連結搜尋框等功能。

這類標記是基礎性的，而不是炫目的。它可以幫助釐清：

• 官方網站身分
• 標誌
• 社群檔案
• 聯絡資訊
• 母公司或子公司關係

每個認真的企業、出版物、非營利組織與產品公司，都應該在某個穩定位置放置乾淨的組織標記，通常是首頁或關於頁面。

不要把所有可能屬性都塞進去。目標是實體清晰度，而不是資料庫傾倒。

FAQPage：技術上受支援，但對多數網站很少可見

FAQPage 值得特別說明，因為它曾經是容易取得成效的方法。多年來，FAQ 標記可以用問答手風琴展開摘要。這讓它很有吸引力，也可預期地被過度使用。

Google 後來大幅限制 FAQ 豐富搜尋結果，通常只顯示給知名且具權威性的政府與健康網站。其他搜尋引擎可能仍以不同方式使用 FAQ 標記，而這種標記仍可幫助機器理解內容結構，但多數商業與編輯型網站不應期待可見的 FAQ 豐富搜尋結果。

只有在頁面真的包含 FAQ 時才使用 FAQ 標記。不要只是為了追逐搜尋版面而加入假的問答區塊。

DiscussionForumPosting 與 ProfilePage

社群內容在搜尋結果中變得更顯著，結構化資料可以幫助辨識論壇串與個人檔案頁面。

DiscussionForumPosting 可能適合論壇、問答社群與討論平台，這些地方的主要內容是使用者產生的討論。ProfilePage 可以幫助辨識關於人物或貢獻者的頁面，尤其是在專業性、作者身分或社群身分重要的情境中。

這不適合一般行銷見證或部落格留言。頁面類型應符合實際體驗。

有用但常被高估的類型

有些 schema.org 類型在語意上合理，但它們本身很少產生可見的搜尋強化。

範例包括：

• Service
• Thing
• CreativeWork
• Person
• Place
• ImageObject
• WebPage
• AboutPage
• ContactPage

這些並不是「不好」的類型。它們可以幫助更精確地描述頁面，也可能在更廣泛的知識圖譜脈絡中有用。但如果你的目標是在搜尋結果中產生可見變化，它們通常是次要的。

例如，將顧問服務頁標記為 Service，並不會可靠地創造特殊的服務豐富搜尋結果。一個結構良好、文案清楚、內部連結完整、載入快速且證據可信的頁面，對搜尋表現的幫助會大於精巧但不受支援的標記。

同樣地，ImageObject 可以描述圖片，但圖片搜尋表現也取決於周圍文字、檔名、說明文字、圖片品質、索引與可及性。Schema 不是基礎工作的替代品。

JSON-LD 通常是最佳實作格式

搜尋引擎可以讀取多種結構化資料格式，包括 Microdata 與 RDFa，但 JSON-LD 通常是最乾淨的選擇。

它讓標記與 HTML 呈現分離，更容易測試，也較不容易在設計師修改範本時壞掉。對多數團隊而言，放在頁面 head 或 body 中的 JSON-LD 是實務上的預設選擇。

一個簡單的產品範例如下：

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Acme Carbon Tripod",
  "image": "https://example.com/images/tripod.jpg",
  "description": "A lightweight carbon tripod for travel photography.",
  "brand": {
    "@type": "Brand",
    "name": "Acme"
  },
  "offers": {
    "@type": "Offer",
    "priceCurrency": "USD",
    "price": "149.00",
    "availability": "https://schema.org/InStock",
    "url": "https://example.com/products/carbon-tripod"
  }
}

這個範例刻意保持平實。多數結構化資料都應該很無聊。準確勝過聰明。

實用的優先排序模型

如果你正在決定先實作什麼，請使用這個順序：

1. 從對應受支援搜尋功能的頁面類型開始。 Product、recipe、event、job、video、breadcrumb、article 與 local business 標記，通常應該比冷門類型優先處理。
2. 只標記使用者看得到的內容。 隱藏主張是結構化資料變得不符合資格或有風險的常見原因。
3. 修正範本，而不是單一頁面。 當結構化資料由 CMS 或產品資料庫產生時，最容易維護。
4. 先驗證，再監控。 使用官方豐富搜尋結果與 schema 驗證工具，然後在可用時觀察 Search Console 強化項目報表。
5. 不要忽略頁面體驗。 豐富搜尋結果可能有助於呈現，但使用者仍會進入頁面。如果效能報表讓你的團隊緊張，請先不慌張地閱讀 Lighthouse 報表，再把 schema 變成另一個分心事項。

會降低影響的常見錯誤

標記錯誤的頁面類型

分類頁不是產品頁。徵才首頁不是職缺發布頁。即將舉辦的網路研討會清單不一定是一個活動。

搜尋功能通常是圍繞特定頁面意圖設計的。請讓標記符合頁面的主要目的。

加入不可見的屬性

如果頁面沒有顯示評分，就不要包含 aggregateRating。如果職缺頁沒有提到薪資，請謹慎處理，不要自行捏造薪酬標記。如果產品缺貨，就不要標記為有庫存。

結構化資料應該讓可見事實更容易被解析，而不是建立頁面的平行版本。

把驗證通過當成成功

通過驗證器只代表語法可接受，且必要欄位可能存在。它不代表頁面會獲得豐富搜尋結果。

請把驗證視為最低門檻，而不是成果。

實作一次 schema 後就忘記它

價格會變。職缺會過期。活動會延期。作者會離職。標誌會重新設計。

由過期欄位產生的結構化資料，可能悄悄變得不準確。每當你變更範本、CMS 欄位或商業資料來源時，都應該檢查它。

<!-- tool-cta:start -->

💡 試試這個: 在調查哪些結構描述類型真正重要之前，先用 JSON Formatter 清理你的 JSON-LD，讓結構易於稽核。

<!-- tool-cta:end -->

冷靜的建議

對多數網站而言，schema 策略應該節制且審慎。

實作符合你真實內容、且對應受支援搜尋功能的類型。保持資料準確。從可靠來源產生資料。驗證它。監控結果。然後停下來。

你不需要標記頁面上的每一個名詞。你不需要因為清單這麼說，就加入十二層巢狀 schema 類型。你更不需要讓結構化資料說出比頁面本身更多的內容。

schema.org 在消除歧義時最有用。當這種清晰度與搜尋引擎實際支援的功能一致時，搜尋結果才會改善。