多數人對結構化資料標記的認知，還停在幾年前的教學版本。照著範例把 JSON-LD 貼上去，Google 的搜尋結果頁就會多長出一塊，常見問題的下拉問答、步驟教學的分步驟卡片都算。這幾年 Google 已經陸續收回好幾種標記的畫面效果，FAQ 與 HowTo 只是討論度最高的兩個，不是唯一被動過的案例。
如果你的網站現在還在照著舊教學做 FAQ、HowTo 標記，以為做了就一定會有問答清單或步驟圖卡跳出來，這個期待已經對不上現況。標記本身沒有消失，Schema.org 的型別清單也沒有變少，變的是 Google 願不願意把哪些型別拿來當版面裝飾，而且這件事一直在動態調整，完全不影響網頁在一般搜尋的排名。
這些事分清楚，比繼續照抄一份舊清單有用得多。先從結構化資料標記實際在做什麼事講起。
結構化資料標記是什麼？一段文字怎麼被拆成搜尋引擎讀得懂的欄位？
一段沒有標記的文字，對搜尋引擎來說就只是一串字元。以商品頁為例，畫面上寫著「手沖濾杯，售價 398 元，4.5 顆星」，人眼看得懂，但 Google 的爬蟲讀到的只是連在一起的中文字與數字，不知道哪個是商品名、哪個是價格、哪個是評分。結構化資料標記做的事，就是把這些資訊拆成搜尋引擎能理解的欄位：商品名對應 name，價格對應 price，評分對應 ratingValue。標記完成後，同一段內容在搜尋引擎眼中，不再是一團文字，而是一組有明確意義的資料。
這套詞彙表叫 Schema.org，由 Google、Microsoft、Yahoo 共同維護，目的是讓各家搜尋引擎能用同一套欄位定義去讀懂網頁內容，不用各自發明一套規則。「結構化資料」與「Schema」這兩個詞，業界常常交替使用，嚴格說並不完全相同，前者是比較廣義的資料組織方式，後者特指 Schema.org 這套具體的詞彙表，不過日常討論裡混著用也不影響理解，這篇後面也會沿用這個習慣。
至於實際上要用哪種語法把這些欄位寫進網頁，JSON-LD、Microdata 還是 RDFa，後面會有專門的段落示範，這裡先掌握「標記等於把文字拆成欄位」這個核心概念就夠。
結構化資料能為網站帶來什麼效果？先看清楚能與不能
先破除一個常見的誤解，結構化資料標記不是「加了就保證出現在精選摘要或搜尋結果最上方」的開關。它做的事，是提高網頁被系統正確解析、進而「有資格」被挑進特定版位（星等、價格、麵包屑這類複合式搜尋結果）的機率，決定權最終還是在 Google 手上，而且這個決定跟內容品質、權威性、使用者行為這一整套排名機制綁在一起，不是標記本身說了算。Google 在自己的官方政策裡也講得直白，結構化資料違規最多讓頁面失去複合式搜尋結果的資格，並不會影響這個頁面在一般網頁搜尋的排名。
把期待值放對之後，再看看「有做確實有差」這件事有沒有證據。Google 自己公開過四個品牌案例的數據：爛番茄（Rotten Tomatoes）替十萬個頁面加上結構化資料後，點擊率提升了 25%；Food Network 把八成頁面轉換成支援搜尋功能後，造訪量成長 35%；樂天（Rakuten）的使用者在有結構化資料的頁面上停留時間是沒有標記頁面的 1.5 倍，AMP 頁面的互動率更高出 3.6 倍；雀巢（Nestlé）出現在複合式搜尋結果的頁面，點擊率比沒有出現的頁面高出 82%。這些不是空話，是有實際佐證的效益，只是要記得，這些數字反映的是「有機會被挑選進版位之後」帶來的效果，前提條件（內容本身夠好、符合資格規則）沒做到，標記寫得再工整也不會自動生效。
FAQ、HowTo 為什麼會失效？Google 這幾年收回了哪些標記效果？
決定權在 Google 手上，這句話不是說著玩的，FAQ 跟 HowTo 標記的遭遇就是最好的例子。這不是單一意外事件，而是一項持續在推進的政策。Google 從 2025 年年中開始，就公開說明會定期檢視既有的搜尋功能，把使用率偏低、對使用者沒有明顯附加價值的結構化資料視覺效果陸續收回，同一波公告當時就先拿掉了課程資訊、事實查核、預估薪資這類比較冷門的型別。這個脈絡值得記住，因為它說明 FAQ、HowTo 不是被單獨針對，而是同一套邏輯下的其中兩個案例，未來很可能還有下一個。而且 Google 每次都講得很清楚，這些調整都是收回版面效果，跟頁面在一般搜尋的排名完全無關。
Sitelinks 搜尋框：更早的先例
在 FAQ、HowTo 之前，Sitelinks 搜尋框（Sitelinks Search Box）就已經走過一次同樣的路。Google 在 2024 年 10 月 21 日於官方部落格宣布淘汰這個功能，同年 11 月 21 日起全球生效，理由同樣是使用率下滑。這個型別本身沒有被禁用，網站繼續保留這段標記也不會出錯，只是搜尋結果不會再因為它多長出一個站內搜尋框。這個先例值得留意，這類淘汰其實常常發生，只是討論度不一定像 FAQ、HowTo 那麼高。
FAQ 的四個時間點，走到全面下架
FAQ 結構化資料走向全面下架，中間經過四個時間點：
- 2023 年 8 月：Google 宣布限縮 FAQ 與 HowTo 的顯示資格，FAQ 之後只保留給「知名、具權威性的政府與衛生機構網站」，一般商業網站原則上已經看不到這個版位。
- 2026 年 5 月 7 日：FAQ rich result 從 Google 搜尋結果全面消失，連原本還保有資格的政府與衛生機構網站也一起收回。
- 2026 年 6 月：Search Console 的 FAQ 搜尋外觀篩選器、FAQ rich result 報表，以及 Rich Results Test 對 FAQ 的檢測支援，一併下架。
- 2026 年 8 月：Search Console API 也會移除 FAQ rich result 的相關資料。
FAQPage 這個 Schema.org 型別本身並沒有被廢除，放著也不會造成頁面錯誤，這點需要說清楚。只是不論網站類型，都不用再期待它能在搜尋結果長出下拉問答的畫面效果了。
HowTo：比 FAQ 更早、更徹底撤下
HowTo 標記走得比 FAQ 更快，2023 年 8 月先在手機版收回顯示資格，隔月（9 月）緊接著連桌機版也一併撤下，是這三個案例裡收回速度最快的一個。同樣地，型別未廢除，只是不再有分步驟展開的畫面效果。
哪些類型目前還有畫面效果？依網站類型整理該做的組合
跳過已經停用的三種之後，目前 Google 官方支援清單裡，一般商業網站真正常用、確實還會影響 SERP 呈現的型別，集中在下面這幾種：
| Schema.org 型別 | 用途 |
|---|---|
Article | 標示文章標題、作者、發布與更新日期，適用於部落格、新聞頁 |
BreadcrumbList | 標示頁面在網站中的階層位置（目前僅桌機版 SERP 顯示） |
Product | 標示商品名稱、價格、庫存與評分，常見於電商商品頁 |
Review / AggregateRating | 標示評論內容與平均評分，常見於商品頁、餐廳或服務頁 |
Organization | 標示企業名稱、標誌、聯絡方式與社群連結，常見於官網首頁 |
LocalBusiness | 標示實體店面地址、營業時間、電話，常見於門市、餐飲店 |
版面有需要的話，還可以再加上 Event（活動資訊）、JobPosting（職缺）、VideoObject（影片內容）這幾種，但不是每個網站都用得到，不必整份三十幾種型別逐一套用。接下來依三種常見的網站類型，分別看該優先做哪個組合。
內容與部落格類網站
以 Article 或 BlogPosting 為主，搭配 BreadcrumbList。如果頁面本身有讓使用者互動發問的問答功能，不是店家自己整理的那種靜態常見問題清單，可以了解一下 QAPage 這個型別，它跟 FAQ 常被搞混，但目前仍受官方支援，差別在於 QAPage 對應的是使用者真的能提問、能有多個不同回答的討論頁面。搞清楚兩者的差異，才不會白白錯過一個還能用的類型。
電商網站
以 Product 為核心，標示價格、庫存、評分，搭配 Review／AggregateRating 與 BreadcrumbList。要提醒的是，標記的商品資訊要跟頁面實際顯示的內容一致，價格、庫存狀態這類會變動的欄位尤其容易忘記同步更新，這點後面「常見錯誤」那節會再談。
在地商家與服務型網站
以 Organization 或 LocalBusiness 為主，標記名稱、地址、營業時間、聯絡方式，讓搜尋結果旁能出現這些複合資訊。如果你的網站沒有商品頁，這組通常是最值得優先做的起點，做好之後，使用者不用點進網站就能先掌握基本資訊。
結構化資料會不會影響 AI 願不願意引用網站？Google 自己怎麼說？
把上面這套組合做完，通常已經能應付大多數搜尋結果的呈現需求。但這幾年討論度最高的變數，其實不是 Google 搜尋本身，而是 AI 搜尋工具願不願意引用你的內容，「加了 Schema，AI 就會引用你」這句話在 SEO 圈子裡流傳得很廣，Google 自己在 2026 年 5 月發布的〈生成式 AI 功能最佳化指南〉裡，直接把這個說法列進要破解的迷思清單。
Google 官方說法：生成式 AI 搜尋不需要結構化資料
這份指南寫得很直白：「生成式 AI 搜尋不需要結構化資料，你也不需要新增任何特殊的 schema.org 標記。」同一份「不用做」的清單裡，還包括不需要建立 llms.txt 這類機器可讀檔案、不需要為了讓 AI 讀懂而把內容特別切成小塊、不需要為了生成式 AI 專門改變寫作方式。不過指南也補了一句，結構化資料還是建議繼續做，做為整體 SEO 策略的一部分，因為它有助於在 Google 搜尋中顯示複合式搜尋結果。換句話說，結構化資料服務的主要對象一直是傳統的複合式搜尋結果，不是 AI 摘要或 AI 模式的必要條件，繼續做沒有錯，但別誤以為它是擠進 AI 答案的捷徑。
結構化資料不是必要條件，但哪些類型還是值得做？
官方沒有說結構化資料「沒用」，只是說「不是必要」，這中間還留著幾條第三方技術分析觀察到的間接路徑。Ahrefs 一篇技術分析指出，第一條路徑是 Gemini。Gemini 產生答案時，會透過查核機制（grounding）去查詢 Google 的搜尋索引，確認回答內容站不站得住腳，而搜尋索引本身在建立時就會解析結構化資料。也就是說，Gemini 不是直接讀網頁上的 JSON-LD，而是間接透過「索引已經解析過」這一層，受到結構化資料影響。
第二條路徑是品牌與作者的實體識別。即使模型不直接解析結構化欄位，Organization（品牌實體）、Author／Person（作者歸屬，呼應 E-E-A-T）、Website 這幾類標記，仍然會透過 Google 知識圖譜與語意連結，間接強化 AI 生成答案時對品牌可信度的判斷，這也是同一篇分析建議優先做的三種類型。
同一篇分析也提到一個公開的實測案例，提醒不要高估這件事。有人做過測試，只在網頁的結構化資料裡放進一個虛構公司的假地址，頁面本身完全看不到這個地址，結果幾個 AI 問答工具給出的回答，還是把這個假地址講出來了。這證明的其實是模型把結構化資料當成頁面上的一般文字在處理，不是真的解析「這是地址欄位」這件事本身，提醒我們別高估 schema 標記本身的效果，它能加分，但不是萬能保證。
還有一個技術限制值得知道。GPTBot、ClaudeBot、PerplexityBot 這類 AI 爬蟲不會執行 JavaScript，如果結構化資料是透過 Google Tag Manager 或其他前端腳本動態插入的，這些爬蟲根本讀不到。要讓 AI 爬蟲看得到，結構化資料要寫進 HTML 原始碼裡的靜態 <script> 標籤，而不是靠 GTM 事後注入。
一段可以直接套用的 JSON-LD 範例，以文章頁為主
結構化資料目前主要有三種寫法：JSON-LD、Microdata、RDFa。Google 明確建議優先使用 JSON-LD，原因是它可以整段獨立寫成一段 <script>，放進 <head> 或 <body> 都可以，Google 的 John Mueller 已經確認過這兩個位置效果一樣，不用像 Microdata、RDFa 那樣打散嵌進每一個 HTML 標籤裡。整段獨立寫的好處是出錯機率低，要修改或除錯時也比較容易找到，這也是目前多數 SEO 外掛預設輸出的格式。
以下是一段標準文章頁（Article）的 JSON-LD 範例，欄位名稱與寫法可以直接套用，實際內容依你的網頁調整即可：
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "手沖咖啡完整入門指南：從選豆到沖煮的關鍵步驟",
"image": "https://www.example.com/uploads/coffee-guide-cover.jpg",
"author": {
"@type": "Organization",
"name": "你的網站或品牌名稱"
},
"publisher": {
"@type": "Organization",
"name": "你的網站或品牌名稱",
"logo": {
"@type": "ImageObject",
"url": "https://www.example.com/logo.png"
}
},
"datePublished": "2025-01-10",
"dateModified": "2026-07-24"
}
</script>Code language: JSON / JSON with Comments (json)幾個欄位重點：headline 對應文章標題；datePublished／dateModified 分別是發布日期與最後更新日期，更新文章時記得同步改 dateModified，這是讓 Google 知道內容有持續維護的訊號之一；author 與 publisher 則是告訴搜尋引擎這篇內容的來源是誰，兩者都建議填。
麵包屑路徑同樣可以寫成 JSON-LD
對應前面提到的 BreadcrumbList，麵包屑路徑也可以寫成同樣的格式：
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "首頁",
"item": "https://www.example.com/"
},
{
"@type": "ListItem",
"position": 2,
"name": "分類名稱",
"item": "https://www.example.com/category/"
},
{
"@type": "ListItem",
"position": 3,
"name": "文章標題"
}
]
}
</script>Code language: JSON / JSON with Comments (json)itemListElement 依網站實際的階層列出每一層，position 是層級順序，最後一層（目前所在頁面）通常不用附 item 網址。寫完別急著收工，貼上網站前先送進下一段的驗證工具跑一次，語法有錯或欄位缺漏，標記等於白做。
幫網站加上結構化資料，現在建議的三種做法
知道怎麼寫之後，下一個問題是怎麼把這段程式碼實際加到網站上。目前常見的做法大致分三種。
SEO 外掛自動產生：多數 SEO 外掛都能依頁面類型自動輸出 Article、Organization、BreadcrumbList 這類基本標記，不用自己寫程式碼，是最省力的起點，大部分網站的基本需求靠這個就能滿足。
電商或系統內建：常見的電商系統通常會依商品資料自動產出 Product 標記，後台改價格或庫存，前台的標記內容也會跟著同步更新，不用另外維護一份。
手寫 JSON-LD：遇到外掛或系統沒涵蓋到的自訂需求，例如活動頁的 Event、特定結構的 Review，可以照前一段的範例手刻一段 JSON-LD，貼進頁面 <head> 或透過 Google Tag Manager 部署。不過要留意前面提過的限制。透過 GTM 動態插入的標記，對不執行 JavaScript 的 AI 爬蟲是隱形的，如果同時在意 AI 引擎讀不讀得到，寫進 HTML 原始碼裡的靜態 <script> 還是比較保險的做法。
結構化資料最容易犯的錯誤有哪些？上線前的三個自查重點
語法寫對、Rich Results Test 也顯示綠燈，不代表這段標記就完全沒問題。Google 對結構化資料訂有具體的內容政策，底下三類是最容易踩到的地方，全部都對應官方政策的明文條款，不是隨口列的經驗談。違反可能被 Google 人工判定並處分，頁面就沒辦法以複合式搜尋結果呈現，但不會影響網頁在一般搜尋的排名。
標記內容和頁面實際內容對不上
Google 官方政策明講，結構化資料必須是頁面內容的真實呈現。常見的違規情況，例如標了評論星等，頁面上卻沒有真正的使用者評論，或商品標記寫的價格跟頁面顯示的不一樣，都算是「關聯性」政策明確禁止的情況。
必要欄位沒填齊全
每種型別的說明文件都會列出必要屬性，少填了，這個項目就不會顯示在複合式搜尋結果裡，標記等於白寫。建議屬性則不是硬性規定，但填得越完整，呈現的品質通常越好，例如職缺頁面補上薪資範圍，比只填職稱容易被挑中呈現。
整個網站硬套同一種標記類型
結構化資料要放在真正相關的頁面上，對應該頁的實際內容，不是為了搶版面就整站套用同一種型別。如果一個頁面上同時有多個項目，例如食譜頁附了一段介紹影片，要用巢狀結構把兩者包在一起，還是各自獨立標記，Google 官方文件都有具體示範，兩種做法搜尋引擎都讀得懂，選哪種看你的頁面結構比較適合。
三個工具，檢查標記有沒有真的生效
上面三類錯誤，肉眼未必看得出來，寫完標記後最好靠工具交叉驗證有沒有真的生效。
Rich Results Test：複合式搜尋結果測試
這是 Google 提供的工具，用來檢查頁面是否符合特定 rich result 的資格，可以選擇電腦版或手機版檢測，輸入網址或直接貼上程式碼都可以。網址檢測能看到完整頁面的結果，網站還沒上線時則可以用程式碼片段檢測。跑完會顯示「適合複合式搜尋結果」，或列出警告、錯誤的細項，照著提示修改即可。
Schema Markup Validator：語法驗證工具
Rich Results Test 只檢查 Google 目前有支援顯示效果的型別。如果想確認語法本身寫得對不對，不管 Google 現在有沒有拿它做畫面呈現，可以改用 Schema.org 自己維護的 Schema Markup Validator，貼上網址或程式碼就能檢查標記的欄位與格式是否符合規範，涵蓋的型別範圍比 Rich Results Test 更廣。
Google Search Console 的結構化資料報表
Search Console 的結構化資料報表，可以看到網站目前有哪些頁面被偵測到標記、哪些型別有效、哪些出現錯誤或警告。定期回來看這份報表，能及早發現改版或程式調整不小心弄壞了原本正常的標記。
FAQ、HowTo、Sitelinks 搜尋框這幾個案例提醒一件事，搜尋引擎的規則會不斷調整，某個標記今天有畫面效果，不代表明年還在。比較穩妥的做法，是把目前確實還在發揮作用的型別，像 Article、Product、Organization 這類做扎實，並且養成用工具定期驗證的習慣，不要把心力全押在單一容易被收回資格的標記上。
結構化資料的意義，從來不只是讓網頁在搜尋結果多長出一塊版面。它同時也是讓搜尋引擎、以及現在越來越多會直接整理答案的 AI 工具，能夠正確理解網站內容的一套共通語言。版位效果消失了，把內容整理清楚、標記寫對這份基本功，依然用得上。