當搜尋邁入 AI 時代，網頁能否被機器「正確讀懂」，已成為決定曝光的關鍵。結構化資料（Structured Data）與 Schema Markup 正是讓搜尋引擎與 AI 系統理解頁面語意的標準語言。它不是直接的排名因素，卻是內容被搜尋引擎信任、被 ChatGPT 與 Perplexity 引用的基礎建設。本文完整解析觀念、語法、實作與驗證流程，並提供台灣中小企業的實務建議。
本篇目錄
開始實作前：結構化資料基礎回顧
結構化資料是一種標準化的標記方式，目的是讓搜尋引擎與各類機器系統精準理解網頁內容的真正意義。它的作用不只是讀取頁面上的文字，而是進一步辨識這些文字所代表的實體、屬性與彼此之間的關係。
若您想先建立基本概念，可參考結構化資料是什麼；本文則聚焦於實作面。本文屬於《新視野 SEO 完整指南》系列，完整框架請參考「搜尋引擎優化完整指南」。
結構化資料的本質，是把「人類看得懂的文字」翻譯成「機器能精準判讀的語意」。
以「蘋果：NT$35」為例，對一般使用者而言，這代表商品名稱與價格；但對搜尋引擎來說，「蘋果」可能是水果、品牌名稱，甚至是店名，「NT$35」也未必能直接判定為售價。
若透過結構化資料明確標示這是一項商品（Product），名稱為蘋果、價格為 35、幣別為 TWD，搜尋引擎便能準確理解內容，而非依賴推測。
Schema.org 是什麼
結構化資料通常依照 Schema.org 的標準撰寫。它是由 Google、Microsoft、Yahoo 與 Yandex 共同維護的開放式語意詞彙標準，提供網站描述各類資訊時可遵循的共同語言。
涵蓋範圍包含商品、文章、人物、組織、活動、評論、食譜與在地商家等類型。對網站經營者而言，價值在於：只要採用一致的標記規則，搜尋引擎與 AI 系統便更容易讀懂頁面內容，不需要逐字猜測。
結構化資料的三種主流格式
<script type="application/ld+json"> 中，與 HTML 結構完全分離，維護彈性高，不會因為版型調整而失效。新專案應一律優先選擇 JSON-LD。itemscope、itemtype、itemprop 等屬性直接嵌入 HTML 標籤內。仍被支援，但會讓 HTML 結構變得複雜、維護成本高，目前已逐漸被 JSON-LD 取代。為什麼結構化資料重要
結構化資料不是直接的排名因素，但仍具有明顯的價值。它的重要性主要體現在三個層面：
- 提升搜尋結果的可見度 正確標記能讓頁面有機會以複合式搜尋結果（Rich Results）呈現，例如商品評分星等、價格、麵包屑路徑，讓搜尋結果更顯眼，間接提升點擊率。
-
幫助機器精準理解內容
結構化資料消除了搜尋引擎對內容的猜測，明確告訴機器「這段文字是什麼、屬於哪個實體」，是建立內容信任的重要基礎。
範例：同一頁面寫著「3,000」，加上 Product 與 offers 標記後，機器才知道這是售價而非瀏覽次數。
- 提高被 AI 搜尋引用的機率 在 AI 搜尋時代，乾淨、與頁面內容一致的結構化資料能讓 AI 系統更容易擷取與摘錄，提高內容被引用為答案來源的可能性。
JSON-LD 語法基礎
JSON-LD 是以 JavaScript 物件格式撰寫的結構化資料，放在獨立的 script 區塊中，與頁面 HTML 分離，是目前最推薦的實作方式。它的語法清晰、容易維護，也是 Google 官方文件一再建議的首選格式。
JSON-LD 的基本結構
一段最基本的 JSON-LD，必定包含 @context 與 @type 兩個欄位，再依類型補上各項屬性。以一項商品為例：
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Product",
"name": "手沖咖啡濾杯",
"image": "https://www.example.com.tw/images/dripper.webp",
"description": "陶瓷材質單孔濾杯，適合手沖入門者使用。",
"brand": { "@type": "Brand", "name": "新視野選物" },
"offers": {
"@type": "Offer",
"price": "680",
"priceCurrency": "TWD",
"availability": "https://schema.org/InStock"
}
}
</script>
三個必懂的核心欄位
-
@context：宣告語意詞彙來源
幾乎一律填
https://schema.org，告訴機器這份資料使用 Schema.org 的詞彙標準解讀。 -
@type：宣告這是什麼類型
指定實體類型，例如
Product（商品）、Article（文章）、LocalBusiness（在地商家）、Organization（組織）。 -
屬性（properties）：描述細節
依類型填入對應欄位，如商品的
name、image、offers，文章的headline、author、datePublished。
JSON-LD 要放在哪裡
JSON-LD 可以放在頁面的 <head> 或 <body> 內，兩者皆可被正確讀取，差異不大。重點不在位置，而在於標記內容必須與使用者實際看得到的頁面內容一致。
例如 JSON-LD 標示的價格、評分、作者，都必須在頁面上真實存在。標記不可見或不存在的內容，違反 Google 結構化資料的品質規範，可能導致無法顯示或被視為作弊。
常見 Schema 類型總覽
Schema 類型多達數百種，但對多數台灣中小企業而言，真正常用且仍能帶來複合式搜尋結果的，集中在少數幾種。與其全部都標，不如把最貼近網站性質的幾種做正確、做完整。
| Schema 類型 | 適用情境 | 對應的搜尋呈現 |
|---|---|---|
| Organization | 公司、品牌官網首頁，描述組織名稱、Logo、官方連結 | 知識面板、品牌資訊整合 |
| LocalBusiness | 實體店面、診所、餐廳，含地址、營業時間、電話 | 在地搜尋與地圖資訊強化 |
| Product | 電商商品頁，含名稱、圖片、價格、庫存狀態 | 商品複合式結果、價格與供應狀態 |
| Review / AggregateRating | 商品或服務的評論與平均評分 | 星等評分摘要 |
| Article | 新聞、部落格、教學文章，含標題、作者、發布日期 | 文章與頭條新聞呈現 |
| BreadcrumbList | 頁面的階層導覽路徑 | 麵包屑路徑取代冗長網址 |
| Recipe | 食譜內容，含食材、步驟、烹調時間 | 食譜複合式結果與圖片輪播 |
| Event | 活動、課程、展覽，含時間、地點、票價 | 活動資訊呈現 |
已停用或淘汰的類型，請勿再依賴
Schema 類型會隨著搜尋引擎策略調整而增減，近年 Google 已陸續移除多種較少使用的類型。其中與內容網站最相關的兩項變動，需要特別留意：
同一波精簡中，Google 另有七種較少使用的類型一併退場，包括 Book Actions、Course Info、Claim Review、Estimated Salary、Learning Video、Special Announcement 與 Vehicle Listing。
需要釐清的是：FAQPage 與 HowTo 作為 Schema.org 詞彙仍然有效、合法，留在頁面上不會造成扣分，Bing、Perplexity 等搜尋引擎與 AI 爬蟲也仍會解析。
改變的只是「Google 不再給予視覺呈現」，而非「結構化資料失去意義」。實務做法應從「為了排版效果而標記」轉向「為了讓內容被機器與 AI 正確理解而標記」。
常見類型的 JSON-LD 實例
理解語法之後，最快上手的方式就是直接看可套用的範例。以下整理台灣中小企業最常用的四種類型，您可以替換成自己的資料後直接使用，實際使用時請確認標記內容與頁面可見內容一致。
在地商家（LocalBusiness）
實體店面、診所、餐廳、工作室最適合使用 LocalBusiness 或其子類型，如 Restaurant。重點欄位是名稱、地址、電話與營業時間，有助於強化在地搜尋與地圖呈現。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Restaurant",
"name": "新視野咖啡 台中店",
"image": "https://www.example.com.tw/images/store.webp",
"address": {
"@type": "PostalAddress",
"streetAddress": "市政路 100 號",
"addressLocality": "台中市",
"addressRegion": "西屯區",
"postalCode": "407",
"addressCountry": "TW"
},
"telephone": "+886-4-1234-5678",
"openingHours": "Mo-Fr 09:00-18:00",
"priceRange": "$$"
}
</script>
文章（Article）
新聞、部落格與教學內容適用 Article。除了標題與圖片，建議補上作者與發布者，通常就是您的組織，並填入發布與更新日期。日期請使用 ISO 8601 格式，並填入文章實際的發布日。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "結構化資料與 Schema Markup 完整教學",
"image": "https://www.example.com.tw/images/cover.webp",
"datePublished": "2024-01-15",
"dateModified": "2024-03-20",
"author": { "@type": "Organization", "name": "新視野" },
"publisher": {
"@type": "Organization",
"name": "新視野",
"logo": {
"@type": "ImageObject",
"url": "https://www.example.com.tw/logo.png"
}
}
}
</script>
麵包屑路徑（BreadcrumbList）
BreadcrumbList 可讓搜尋結果以階層路徑取代冗長網址，提升可讀性。position 從 1 開始遞增，最後一層，也就是當前頁面，通常不需填 item。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{ "@type": "ListItem", "position": 1, "name": "首頁",
"item": "https://www.example.com.tw/" },
{ "@type": "ListItem", "position": 2, "name": "SEO 教學",
"item": "https://www.example.com.tw/seo/" },
{ "@type": "ListItem", "position": 3, "name": "結構化資料" }
]
}
</script>
評分與評論（AggregateRating 與 Review）
商品或服務若有真實評論，可在 Product 內加上 aggregateRating 平均評分與 review 個別評論；電商商品頁的完整標記可參考Product Schema。
務必注意：這些評分必須是頁面上真實存在的內容。捏造評分違反品質規範，是最常見且最嚴重的錯誤。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Product",
"name": "手沖咖啡濾杯",
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.6",
"reviewCount": "128"
},
"review": {
"@type": "Review",
"reviewRating": { "@type": "Rating", "ratingValue": "5" },
"author": { "@type": "Person", "name": "陳小姐" },
"reviewBody": "濾杯品質很好，出水穩定，很適合新手。"
}
}
</script>
複合式搜尋結果的取得條件
正確的結構化資料只是取得複合式搜尋結果的「必要條件」，不是「充分條件」；標記無誤不代表一定會顯示。Google 官方明確表示，結構化資料只是讓某項呈現「有資格出現」，最終是否顯示仍由演算法依整體品質與情境決定。
取得複合式結果的基本門檻
- 標記內容與頁面一致 JSON-LD 描述的資訊必須在頁面上真實可見，不可標記隱藏或不存在的內容。
- 符合該類型的必填欄位 每種類型都有必填與建議欄位，缺少必填欄位通常無法取得對應呈現。
- 頁面可被正常檢索 不可用 robots.txt 封鎖、不可加上 noindex，否則機器讀不到結構化資料。
- 符合內容與品質規範 內容須真實、原創、即時；過期或違反垃圾內容政策的標記，可能不顯示甚至被處以人工處置。
常見導致無法顯示的錯誤
- 標記了頁面上看不到的內容 例如頁面沒有評論，卻硬塞 AggregateRating 評分。這違反品質規範，是最常見也最嚴重的錯誤。
-
缺少必填欄位
例如 Product 沒有填
name或image，導致無法取得商品複合式結果。 - 仍在追逐已淘汰的呈現 為了搶版面大量堆砌 FAQ 或 HowTo 標記，但這類複合式結果早已停止顯示，徒勞無功。
- 標記與實際內容不符 標示的價格、庫存與頁面顯示不一致，不僅無法顯示，也會傷害使用者信任。
結構化資料的實作方式與驗證工具
替網站加上結構化資料，並不一定需要寫程式；依您使用的平台不同，可以選擇平台內建、外掛套件或手動撰寫三種路徑。選對方式，能讓沒有開發背景的中小企業也順利上線。
三種常見實作路徑
三個必備的驗證工具
標記完成後，務必驗證語法是否正確、是否符合呈現資格。以下三項工具搭配使用，最為穩妥：
- Rich Results Test（複合式搜尋結果測試）：Google 官方工具，檢查頁面是否符合複合式結果資格，並預覽呈現樣式。
- Schema Markup Validator（Schema.org 驗證器）：純粹檢查 JSON-LD 語法是否合法，不限定 Google 呈現，適合做基礎語法檢查。
- Google Search Console：上線後持續監測實際被索引的結構化資料狀態與錯誤，是長期維運的核心儀表板。
用 @graph 與 @id 串連實體
當一個頁面需要描述多個彼此相關的實體時，用 @graph 把它們收在同一段標記裡，再以 @id 互相參照，是目前最被推薦的進階做法。這種寫法讓搜尋引擎不只看到零散資訊，而是理解實體之間的關係，也是實體 SEO 的基礎。
@graph：把多個實體收在一起
過去常見的做法是「一個頁面放好幾段獨立的 JSON-LD」，現在更建議用 @graph 把多個實體放進同一個陣列。這讓組織、網站、文章、麵包屑等實體集中管理，彼此關係更清楚，也更容易維護。
@id：讓實體互相參照
每個實體都可以擁有一個唯一的 @id，通常用網址加井號片段，例如 #org。當文章要指明發布者是哪個組織時，不必重複寫一遍組織資料，只要用 @id 參照即可。
組織通常是被其他實體參照的基礎節點，可作為文章的 publisher、商品的 brand、服務的 provider。
sameAs：連結到權威來源以強化身分
sameAs 用來指向同一實體在其他權威平台上的頁面，例如官方臉書、LinkedIn 公司頁，乃至 Wikipedia 或 Wikidata。
這能幫助搜尋引擎消除同名歧義、確認您指的是哪一個實體，並把您的品牌與既有的知識圖譜實體連結起來。對台灣中小企業而言，至少把官方社群連結填入 sameAs，是性價比很高的一步。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Organization",
"@id": "https://www.example.com.tw/#org",
"name": "新視野",
"url": "https://www.example.com.tw/",
"logo": "https://www.example.com.tw/logo.png",
"sameAs": [
"https://www.facebook.com/example",
"https://www.linkedin.com/company/example"
]
},
{
"@type": "Article",
"headline": "結構化資料與 Schema Markup 完整教學",
"publisher": { "@id": "https://www.example.com.tw/#org" }
}
]
}
</script>
結構化資料與 AI 搜尋的關係
在 AI 搜尋時代，結構化資料的角色從「爭取 SERP 版面」轉變為「幫助 AI 系統正確理解與引用內容」。它不再只是為了複合式結果而存在，而是內容能否被機器信任、被 AI 摘錄為答案的重要基礎。
若想了解完整做法，可延伸閱讀網站被 AI 引用。
AI Overviews 與 AI Mode 不需要特殊 Schema
Google 官方對 AI 功能的說明指出：AI Overviews 與 AI Mode 並不需要特殊的 Schema 標記，也沒有所謂「AI 專用結構化資料」這種捷徑。但同一份指引也強調：您所使用的結構化資料，都應該與頁面上可見的內容一致。
換言之，結構化資料的價值不在於「討好 AI」，而在於讓您原本就清楚呈現的內容，能被機器更乾淨、更精準地解讀。
結構化資料不是 AI 搜尋的萬靈丹，而是讓「已經寫清楚的內容」更容易被機器讀懂的一層整理。
其他 AI 爬蟲仍在解析結構化資料
雖然 Google 的部分複合式結果已淘汰，但 Bingbot、PerplexityBot 等 AI 與檢索式爬蟲，仍持續抓取與解析開放網路上的結構化資料。
對台灣中小企業而言，這代表正確標記商品、組織與在地商家資訊，依然有助於跨平台被理解與引用，不應因 Google 取消 FAQ 呈現就全面放棄結構化資料。
實體一致性，是被 AI 信任的關鍵
AI 搜尋系統在擷取與引用內容時，需要能明確辨識「您是誰、您在談哪個實體」。前一節提到的 @id 與 sameAs，正是讓機器消除同名歧義、確認身分的工具。
當您的組織資訊在全站一致，並透過 sameAs 連結到官方社群與權威來源，AI 系統就更容易把分散的內容歸屬到同一個可信實體上，提高被引用為答案來源的機率。
換言之，乾淨且一致的實體標記，是 AI 時代的信任基礎，其重要性已不亞於傳統的複合式結果。
結構化資料的長期價值，來自「頁面內容」與「標記資訊」之間完全一致。當兩者對齊，無論是傳統搜尋、複合式結果或 AI 引用，都站在同一個穩固的基礎上。
本文重點整理
結構化資料是讓搜尋引擎與 AI 系統正確理解網頁的標準語言，雖非直接排名因素，卻是內容被信任與被引用的基礎建設。把握以下重點，就能在 AI 搜尋時代穩健佈局：
- 結構化資料的本質，是把人類看得懂的文字翻譯成機器能精準判讀的語意。
- JSON-LD 是 Google 官方建議的首選格式，新專案應一律優先採用。
- 常用且仍有複合式結果的類型，集中在 Product、Article、LocalBusiness、Organization 與 BreadcrumbList。
- FAQ 與 HowTo 複合式結果已停用，標記仍合法但不再有 Google 視覺呈現。
- 正確標記是顯示複合式結果的必要條件，但不保證一定顯示。
- 標記內容必須與頁面可見內容一致，這是品質規範的核心，也是被 AI 引用的基礎。
完成標記前，不妨先自問以下三個問題：
- 我標記的每一項資訊，使用者都能在頁面上實際看到嗎？
- 我選用的類型，是否真的對應網站的核心內容，而非為了搶版面硬加？
- 我是否已用官方工具驗證過語法，並在 Search Console 持續監測？
想系統性掌握更多 SEO 與 AI 搜尋的實務策略，歡迎延伸閱讀「SEO 是什麼？完整指南」，建立從基礎到進階的完整觀念。
常見問答 FAQ
結構化資料會直接提升 SEO 排名嗎？
JSON-LD、Microdata、RDFa 三種格式該選哪一種？
FAQ 複合式搜尋結果取消後，FAQPage Schema 還要繼續使用嗎？
沒有開發背景的中小企業，要如何替網站加上結構化資料？
結構化資料對 ChatGPT、Perplexity 等 AI 搜尋有幫助嗎？
如何檢查與驗證網站的結構化資料是否正確？
參考來源
- Google Search Central，〈結構化資料標記簡介〉，Google 官方文件。
- Schema.org，〈Schema.org 官方詞彙庫〉。
- Google Search Central，〈AI 功能與您的網站〉，Google 官方文件。
- Search Engine Land，〈Google to no longer support FAQ rich results〉，2026。
- 新視野網頁設計，〈結構化資料是什麼〉，本站自有內容。
- 新視野網頁設計，〈SEO 是什麼？2026 搜尋引擎優化完整指南〉，本站自有內容。
