Schema Markup 指南：AI 時代結構化資料怎麼做（2026）
Schema Markup 不是排名捷徑，而是幫助 Google 和 AI 系統更準確理解頁面。本文講清常見 Schema 型別、JSON-LD 寫法、驗證方法和落地順序。
Schema Markup 不是排名捷徑，而是幫助 Google 和 AI 系統更準確理解頁面。本文講清常見 Schema 型別、JSON-LD 寫法、驗證方法和落地順序。
Schema Markup，中文叫結構化資料。
簡單說，就是給搜尋引擎看的”說明書”。你的網頁內容是什麼、講的是誰、價格多少、評分幾顆星——這些資訊，人能看懂，但搜尋引擎不一定能準確理解。
Schema Markup就是用一種標準化的程式碼格式，把這些資訊明確告訴搜尋引擎。
舉個例子。你寫了一篇食譜文章，裡面有配料、步驟、烹飪時間。人看一眼就懂。但Google爬蟲看到的是一堆文字，它不確定哪段是配料、哪段是步驟。
加上Schema Markup後，你等於在程式碼裡標註清楚：這是Recipe型別，配料是這些，步驟是這些，烹飪時間30分鐘。Google一看就明白了。
明白了之後呢？它可能在搜尋結果裡直接展示你的食譜卡片，帶圖片、評分、烹飪時間。這就是Rich Results，富媒體搜尋結果。
以前很多人把 Schema Markup 當成可做可不做的附加項。
現在更實際的看法是：它仍然不是排名捷徑，但在搜尋系統理解頁面這件事上，價值比以前更明確了。
不只是 Google 的傳統搜尋結果，近兩年的 AI 搜尋摘要、問答式結果和內容抽取，也都更依賴清晰、可驗證、結構穩定的頁面資訊。
WordStream 的相關文章和不少行業討論都會提到同一個方向：結構化資料不能替代正文質量，但它能降低系統理解頁面的成本。
更穩妥的理解是，Schema 讓你的網站在“內容是什麼、誰釋出的、有哪些關鍵屬性”這些基礎問題上，說得更清楚。
如果你把結構化資料當成“加一段程式碼就完了”，通常會高估它的作用。更接近現實的做法，是把它和 技術 SEO、頁面正文清晰度、可抓取性一起看。Ahrefs 對 Schema 的長期觀察也提到，結構化資料更像幫助搜尋系統理解頁面，而不是獨立的排名捷徑。
Google 官方文件裡給過幾個公開案例，說明結構化資料更完整時，搜尋展示和使用者互動有機會變得更好：
這些是 Google 自己列出的標杆案例，更適合當方向參考、而不是照搬預期——它們都是大站、大規模實施的結果。對大多數網站來說，Schema 更常見的價值是提升理解準確性、減少標記歧義，以及爭取更完整的搜尋展現。
Schema Markup有三種寫法。
JSON-LD
Google推薦的格式。寫在<script>標籤裡，和頁面內容分開，不影響HTML結構。
長這樣：
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Schema Markup完整指南",
"author": {
"@type": "Person",
"name": "天問網路"
},
"datePublished": "2026-02-10"
}
</script>優點：乾淨、好維護、不和HTML混在一起。
Microdata
直接寫在HTML標籤裡。
<div itemscope itemtype="https://schema.org/Article">
<h1 itemprop="headline">Schema Markup完整指南</h1>
<span itemprop="author">天問網路</span>
</div>優點：資料和內容繫結，不會不一致。缺點：HTML變得很亂。
RDFa
也是寫在HTML裡，語法稍微不同。
<div vocab="https://schema.org/" typeof="Article">
<h1 property="headline">Schema Markup完整指南</h1>
</div>用得比較少。
選哪個？
用JSON-LD。Google推薦，好寫好改，出問題好排查。
Schema.org定義了幾百種型別。但Google不是全都支援。
只有Google明確支援的型別，才能觸發Rich Results。其他型別Google能讀懂，但不會給你特殊展示。
目前Google支援的主要型別：
| 型別 | 用途 | Rich Results效果 |
|---|---|---|
| Article | 文章、新聞 | Top Stories輪播 |
| Product | 商品 | 價格、評分、庫存狀態 |
| Recipe | 食譜 | 圖片、評分、烹飪時間 |
| FAQPage | 常見問題 | ⚠️富結果已下線(2026/5)，標記仍幫理解 |
| HowTo | 教學步驟 | ⚠️富結果已棄用(2023/9)，標記仍幫理解 |
| LocalBusiness | 本地商家 | 地圖、營業時間、電話 |
| Event | 活動 | 日期、地點、票價 |
| Video | 影片 | 影片縮圖、時長 |
| Review | 評測 | 評分星級 |
| BreadcrumbList | 麵包屑導航 | 搜尋結果顯示路徑 |
| Organization | 組織/公司 | 知識面板 |
| Person | 人物 | 知識面板 |
| SoftwareApplication | 軟體/App | 評分、價格 |
| Course | 課程 | 課程資訊卡片 |
| JobPosting | 招聘 | 職位資訊 |
完整列表看Google Search Gallery。
AI搜尋和傳統搜尋不一樣。它不只是匹配關鍵詞，而是理解內容、生成回答。
哪些Schema型別對AI更有用？
1. Article + Author
AI需要判斷內容的可信度。作者是誰、有什麼背景，這些資訊很重要。
加上Author Schema，標明作者姓名、職位、所屬機構，AI更容易信任你的內容。
2. FAQPage
這裡要先糾正一個普遍的過時認知:FAQ 富結果(搜尋結果裡的問答摺疊)已經被 Google 下線了——2023年8月先限制為政府/健康權威站，2026年5月7日對所有網站徹底停止顯示。但請注意:FAQPage 標記本身仍然有效，Google 官方明確表示會繼續用它來理解頁面，只是不再給你那個摺疊展示。對 AI 搜尋來說，問題-答案的結構化恰恰是最容易被抽取、被引用的格式——所以現在做 FAQ Schema，目的從”搶富結果位置”變成了”讓 AI 看懂你的問答”。
3. HowTo
同理:HowTo 富結果已於 2023年9月在桌面端棄用，搜尋裡那個步驟卡片沒有了。但 HowTo 標記把”分幾步、每步做什麼”結構化，AI 在生成操作類回答時仍然更容易理解和引用。判斷標準變了——不是為了搜尋展示而加，是為了讓機器讀懂內容而加。
4. Organization + sameAs
sameAs屬性可以連結到你的社交媒體、維基百科頁面。這幫助AI確認你是誰、你的權威性。
5. Review + AggregateRating
評分資料是AI判斷內容質量的參考。有真實評分的內容，AI更願意引用。
WordPress使用者有福了。不用手寫程式碼，外掛幫你搞定。
方法一：用Rank Math
Rank Math是目前最好用的SEO外掛之一，自帶Schema功能。
安裝後，編輯文章時右側有Schema選項。選擇文章型別（Article、HowTo、FAQ等），填寫相關資訊，外掛自動生成JSON-LD程式碼。
如果你的網站已經裝了Rank Math做SEO最佳化，Schema功能直接就能用。
方法二：用Yoast SEO
Yoast也支援Schema，但功能沒Rank Math全。基礎的Article、Organization能自動生成，複雜型別需要付費版。
方法三：用Schema Pro外掛
專門做Schema的外掛，支援的型別最全。適合需要大量不同Schema型別的網站。
方法四：手動新增
如果你懂程式碼，可以直接在主題的header.php或footer.php里加JSON-LD。
或者用Code Snippets外掛，把Schema程式碼作為snippet新增。
我的建議：普通使用者用Rank Math，夠用了。有特殊需求再考慮手動。
給幾個常用的模板，直接改改就能用。
文章（Article）
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "文章標題",
"image": "https://example.com/image.jpg",
"author": {
"@type": "Person",
"name": "作者名",
"url": "https://example.com/author"
},
"publisher": {
"@type": "Organization",
"name": "網站名",
"logo": {
"@type": "ImageObject",
"url": "https://example.com/logo.png"
}
},
"datePublished": "2026-02-10",
"dateModified": "2026-02-10"
}
</script>FAQ
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "Schema Markup是什麼？",
"acceptedAnswer": {
"@type": "Answer",
"text": "Schema Markup是一種結構化資料格式，用於幫助搜尋引擎理解網頁內容。"
}
},
{
"@type": "Question",
"name": "Schema Markup對SEO有用嗎？",
"acceptedAnswer": {
"@type": "Answer",
"text": "有用。正確使用Schema可以獲得Rich Results，提升點選率。"
}
}
]
}
</script>本地商家（LocalBusiness）
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "LocalBusiness",
"name": "店鋪名稱",
"image": "https://example.com/shop.jpg",
"address": {
"@type": "PostalAddress",
"streetAddress": "街道地址",
"addressLocality": "城市",
"addressRegion": "省份",
"postalCode": "郵編",
"addressCountry": "CN"
},
"telephone": "+86-xxx-xxxx-xxxx",
"openingHours": "Mo-Fr 09:00-18:00",
"priceRange": "$$"
}
</script>產品（Product）
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Product",
"name": "產品名稱",
"image": "https://example.com/product.jpg",
"description": "產品描述",
"brand": {
"@type": "Brand",
"name": "品牌名"
},
"offers": {
"@type": "Offer",
"price": "299.00",
"priceCurrency": "CNY",
"availability": "https://schema.org/InStock"
},
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.5",
"reviewCount": "89"
}
}
</script>Schema Markup看起來簡單，但坑不少。
錯誤1：Schema內容和頁面內容不一致
這是最常見的問題。Schema裡寫的價格是299，頁面顯示的是399。Google發現後會忽略你的Schema，嚴重的可能被懲罰。
規則：Schema裡的資訊必須和頁面可見內容一致。
錯誤2：濫用Review Schema
有些人給自己的文章加Review Schema，評分5顆星。這是違規的。
Review Schema只能用於真實的使用者評價，不能自己給自己打分。
錯誤3：缺少必填欄位
每種Schema型別都有必填欄位。比如Product必須有name和offers，Recipe必須有name和recipeIngredient。
缺了必填欄位，Google不會顯示Rich Results。
錯誤4：JSON語法錯誤
少個逗號、多個引號，JSON就報錯了。Google讀不懂，Schema白加。
寫完一定要用驗證工具檢查。
錯誤5：Schema放錯位置
JSON-LD應該放在<head>或<body>裡。有些人放在<html>外面，或者放在註釋裡，Google根本讀不到。
錯誤6：重複的Schema
同一個頁面加了兩個Article Schema，或者外掛自動生成了一個，你又手動加了一個。重複的Schema會讓Google困惑。
檢查方法：檢視頁面原始碼，搜尋”application/ld+json”，看有沒有重複。
寫完Schema，一定要驗證。
工具1：Google Rich Results Test
地址：https://search.google.com/test/rich-results
輸入URL或程式碼，Google告訴你：Schema有沒有錯誤、能不能觸發Rich Results、哪些欄位缺失。
這是最權威的工具，Google自己出的。
工具2：Schema Markup Validator
地址：https://validator.schema.org/
Schema.org官方工具，檢查語法是否符合規範。
工具3：Google Search Console
在Search Console的”增強功能”裡，可以看到你網站的Schema狀態。哪些頁面有Schema、有沒有錯誤、覆蓋了多少頁面。
如果你已經在用Search Console監控網站，這個功能直接就能用。
驗證流程
說了這麼多，Schema到底有沒有用？
先說清楚：Schema本身不是排名因素。加了Schema不會讓你排名上升。
但Schema能帶來Rich Results，Rich Results能提升點選率。點選率高了，間接對排名有幫助。
資料：
還有一個隱性好處：Schema幫助Google更準確理解你的內容。理解準確了，匹配的搜尋詞更精準，來的流量質量更高。
這是現在很值得關注的一塊。
AI 搜尋在生成摘要和回答時，同樣需要判斷頁面結構、主體資訊和欄位關係。結構化資料不能保證被引用，但能讓這件事更容易被系統識別。一個值得注意的訊號:Google 和微軟都在 2025 年春公開表示，結構化資料對它們的生成式 AI 功能”至關重要”，因為它”高效、精確、機器易處理”——這也是為什麼 FAQ 富結果雖然下線，Google 卻仍保留用 FAQ 標記理解頁面。
尤其是 FAQ、HowTo、Article、Organization 這幾類標記，如果和正文對應得很清楚，通常會比純靠一整頁散文式內容更容易被抽取。
如果你在做GEO最佳化（生成式引擎最佳化），Schema Markup是必須做的基礎工作。
建議：
Schema可以巢狀。一個頁面可以有多種型別，型別之間可以關聯。
比如一篇文章，可以同時有：
這些Schema可以寫在一個JSON-LD裡，用@graph屬性組織：
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Article",
"headline": "文章標題",
"author": {"@id": "#author"}
},
{
"@type": "Person",
"@id": "#author",
"name": "作者名",
"url": "https://example.com/author"
},
{
"@type": "BreadcrumbList",
"itemListElement": [
{"@type": "ListItem", "position": 1, "name": "首頁", "item": "https://example.com"},
{"@type": "ListItem", "position": 2, "name": "SEO教學", "item": "https://example.com/seo"}
]
}
]
}
</script>巢狀Schema的好處：資訊更完整，Google理解更準確，Rich Results更豐富。
不同型別的網站，Schema重點不一樣。
電商網站
必須有：Product、Offer、AggregateRating、BreadcrumbList
Product Schema帶價格和庫存狀態，能在搜尋結果顯示價格，吸引購買意向強的使用者。
本地服務
必須有：LocalBusiness、OpeningHoursSpecification、GeoCoordinates
本地搜尋很依賴這些資訊。營業時間、地址、電話，都要準確。
內容網站/部落格
必須有：Article、Person、Organization、BreadcrumbList
可選：FAQ、HowTo（根據內容型別）
作者資訊很重要，關係到E-E-A-T。
新聞網站
必須有：NewsArticle、Organization、Person
NewsArticle比普通Article多一些欄位，比如dateline。新聞網站用這個更合適。
影片網站
必須有：VideoObject、BreadcrumbList
影片Schema能讓搜尋結果顯示影片縮圖和時長，點選率提升明顯。
Schema Markup會越來越重要。
原因很簡單：AI需要結構化資料。
傳統搜尋引擎靠爬蟲分析HTML，能湊合理解內容。AI搜尋不一樣，它需要快速、準確地理解大量內容，結構化資料是最高效的方式。
Google也在推動這件事。每年都在增加支援的Schema型別，Rich Results的展示形式也越來越豐富。
可以預見：
現在開始做Schema，是在為未來投資。
Q：Schema Markup會影響頁面載入速度嗎？
幾乎不會。JSON-LD程式碼很小，通常只有幾KB。對載入速度的影響可以忽略。
Q：一個頁面可以有多少個Schema？
沒有限制。但要合理，每個Schema都要和頁面內容相關。不要為了加Schema而加。
Q：Schema加了多久能看到效果？
Google需要重新抓取你的頁面才能識別Schema。通常幾天到幾周。可以在Search Console手動請求索引，加快速度。
Q：Schema錯誤會被懲罰嗎？
語法錯誤不會懲罰，只是Schema不生效。但如果Schema內容和頁面不一致（比如虛假評分），可能被手動處罰。
Q：必須用JSON-LD嗎？
不是必須，但強烈推薦。Google明確表示偏好JSON-LD，而且JSON-LD最好維護。
Q：Schema對移動端有影響嗎？
Schema對所有裝置都有效。Rich Results在移動端和桌面端都會顯示。
有人擔心：加Schema會不會影響Core Web Vitals？
答案：基本不會。
JSON-LD程式碼很小，通常只有幾KB。對LCP（最大內容繪製）、FID（首次輸入延遲）、CLS（累積佈局偏移）幾乎沒有影響。
但有一點要注意：如果你用JavaScript動態生成Schema，可能會有輕微影響。建議把Schema直接寫在HTML裡，不要用JS生成。
如果你在做Core Web Vitals最佳化，Schema不是你需要擔心的問題。
如果你的網站有多語言版本，Schema也需要國際化。
幾個要點：
1. 語言標註
在Schema里加inLanguage屬性，標明內容語言。
{
"@type": "Article",
"headline": "文章標題",
"inLanguage": "zh-CN"
}2. 多語言版本關聯
如果同一內容有多個語言版本，可以用sameAs或isPartOf關聯。
3. 本地化資訊
LocalBusiness的地址、電話要用當地格式。貨幣用當地貨幣程式碼（CNY、USD等）。
4. 日期格式
Schema裡的日期統一用ISO 8601格式：YYYY-MM-DD。不要用本地格式。
Schema不是加完就完事了。需要持續維護。
定期檢查
每月用Search Console檢查一次Schema狀態。看有沒有新的錯誤、覆蓋率有沒有下降。
內容更新時同步更新Schema
文章修改了，Schema裡的dateModified要更新。價格變了，Product Schema裡的價格要同步。
關注Google更新
Google會不定期更新Schema要求。某些欄位可能從可選變成必填，某些型別可能被廢棄。關注Google Search Central部落格，及時調整。
監控Rich Results
在Search Console的”效果”報告裡，可以按搜尋外觀篩選。看看Rich Results帶來了多少點選，效果好不好。
最後說幾個常見誤區。
誤區1：Schema越多越好
不是。Schema要和內容相關。一篇普通文章，加Article Schema就夠了。硬加Product、Recipe是沒意義的。
誤區2：Schema能快速提升排名
不能。Schema不是排名因素。它能提升點選率，但不能直接提升排名。
誤區3：所有頁面都要加Schema
不一定。重要頁面（首頁、產品頁、文章頁）要加。但一些輔助頁面（隱私政策、聯絡我們）不一定需要。
誤區4：用了外掛就不用管了
外掛能自動生成基礎Schema，但不一定完美。還是要手動檢查，確保資訊準確。
誤區5：Schema只對Google有用
Bing、Yandex等搜尋引擎也支援Schema。AI搜尋引擎更依賴Schema。做好Schema，對所有搜尋引擎都有好處。
E-E-A-T是Google評估內容質量的框架：Experience（經驗）、Expertise（專業）、Authoritativeness（權威）、Trustworthiness（可信）。
Schema Markup能幫助展示E-E-A-T訊號。
展示Experience和Expertise
用Person Schema標註作者資訊，包括：
這些資訊幫助Google和AI理解作者的專業背景。
展示Authoritativeness
用Organization Schema標註機構資訊，包括：
sameAs屬性特別重要。連結到維基百科、LinkedIn、官方社交媒體，能增強權威性訊號。
展示Trustworthiness
用Review和AggregateRating Schema展示真實使用者評價。
注意：評價必須是真實的。虛假評價會被懲罰。
Schema Markup 不是什麼神秘技巧。它更像一套標註規則。
真正重要的，不是頁面裡塞了多少型別，而是這些標註和正文、價格、作者、組織資訊、FAQ 內容是不是對得上。
如果你還沒系統做過，建議先從最關鍵的頁面開始：文章頁、產品頁、服務頁、組織資訊頁。把基礎型別做好，再慢慢補 FAQ、HowTo、Product 這類更具體的標記。
如果你已經在做，重點通常不是繼續加更多型別，而是回頭排查：有沒有重複標記、有沒有欄位過期、有沒有 Schema 和頁面可見內容不一致。結構化資料不是堆得越多越好，匹配得越準越有價值。
根據你的網站型別，快速找到需要的Schema：
| 網站型別 | 必須Schema | 推薦Schema | 可選Schema |
|---|---|---|---|
| 部落格/內容站 | Article, Organization | Person, BreadcrumbList | FAQ, HowTo |
| 電商網站 | Product, Offer | AggregateRating, BreadcrumbList | FAQ, Organization |
| 本地服務 | LocalBusiness | OpeningHours, GeoCoordinates | Review, FAQ |
| 新聞網站 | NewsArticle | Organization, Person | BreadcrumbList |
| 影片網站 | VideoObject | BreadcrumbList | Organization |
| 食譜網站 | Recipe | AggregateRating, Video | HowTo, FAQ |
| 活動網站 | Event | Organization, Place | Offer |
| 招聘網站 | JobPosting | Organization | Place |
| 課程網站 | Course | Organization, Person | AggregateRating |
| 軟體/App | SoftwareApplication | AggregateRating, Offer | Organization |
按這個表格來，基本不會漏掉重要的Schema型別。