SEO 結構化資料介紹：簡單搞懂結構化資料的意義與用途！ | 白話文商學院

結構化資料是什麼？用一句話講懂它對搜尋引擎的意義

結構化資料（structured data）是一段標準化格式的程式碼，用來主動告訴搜尋引擎與 AI「網頁上的某段文字代表什麼意思」，例如這串數字是產品價格、那行字是評論分數。想系統化打好基礎，可以先讀過結構化資料 Schema 標記完整教學。Google 官方把它的定義寫得很直白：「結構化資料是一種標準化格式，作用是提供網頁相關資訊並將網頁內容分類」[來源：Google Search developers〈簡介結構化資料〉 https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data 2026]。截至 2026 年 6 月，Google 已陸續停用近十種 rich result 類型，但這套語意標記機制仍是 SEO 與 AI 搜尋少數能由你主動陳述欄位定義的入口。

重點先看：結構化資料的價值重點在於，它是唯一一個你能主動告訴搜尋引擎與 AI「這個欄位是什麼意思」的機制；自 2023 年起 Google 已停用近十種 rich result 類型，語意正確性比版位有沒有跑出來更重要 [來源：Google Search Central〈搜尋成果報表與事件標記的資料跌幅〉 https://developers.google.com/search/blog 2026]。

剛接觸 SEO 自學懶人包與基礎觀念 或剛踏入技術 SEO 領域的朋友，第一次看到一大段 JSON-LD 程式碼多半會愣一下。我自己當初也是，盯著螢幕想說這到底是什麼東西。後來發現它的原理其實很笨：就是在網頁上貼一張便利貼，寫著「這是價格 309 元」，讓搜尋引擎不必用猜的。Google 再聰明，面對一頁密密麻麻的內容，也常常認不出哪串數字是售價、哪行字是庫存、哪段是評論分數。結構化資料補上的，就是這一層「語意確認」。

這也是它跟多數 SEO 優化最不一樣的地方。寫個好 Title Tag、調整 網址 URL 的 SEO 基礎、把 內部連結與網站架構 串清楚，這些動作多半是給 Google 一個「友善訊號」；結構化資料則是少數能直接陳述「這個欄位的定義是什麼」的機制。它屬於 Technical SEO 的基礎工程，影響的是「被理解的程度」，至於排名權重本身則不在它的直接作用範圍。想把整體站內 SEO 優化做扎實，結構化資料是其中一塊拼圖。講白了，做了結構化資料不會讓你排名突然往前衝，但會讓 Google 與各種 AI 模型更精確地分類你的內容。

把這層「語意確認」拆開來看，會發現它其實在做三件事。第一件是消歧義：同一頁裡出現「309」，機器不知道這是價格、是型號、還是評論數，標記直接把它綁到 price 欄位，歧義就消失。第二件是建立關聯：產品頁同時標了 Product 與 Organization，Google 才知道這個產品屬於哪個品牌、品牌又有什麼聯絡資訊，這類跨欄位的關係單靠文字排列很難表達。第三件是降低理解成本：爬蟲與模型讀一份結構清楚、欄位齊全的 JSON，遠比解析整頁 HTML 再自行推論省事，而能省下來的運算資源，會反映在收錄與引用的速度與穩定度上。把這三件事想通，就會明白為什麼 Google 明明越來越聰明，卻還是持續推動這套機制。

為什麼要做結構化資料？它真正影響的是點擊率，不是排名

結構化資料的主要用途，是讓網頁在搜尋結果能顯示麵包屑、價格、評分等額外資訊，藉此提升點擊率（CTR）與帶入更多流量。它本身不是直接的排名因子，而是放大曝光與點擊的「版面槓桿」。這點很多人會搞錯，以為加了 schema 就會排名變好，其實它動的是 搜尋結果頁 SERP 上的各種元素 的呈現，至於 Google 搜尋引擎運作原理 裡的排名計分則不受這段標記直接影響。對搜尋結果頁 SERP 的組成有整體概念，會更清楚結構化資料在版面上能插旗的位置；而想往真正的Google 排名提升關鍵推進，靠的還是內容與權威性，標記本身只是輔助。

把它想成跟 網站連結 Sitelinks 怎麼獲得 是同一類機制。Sitelinks 讓你的版面變大、變完整，結構化資料讓你的版面變豐富、變吸睛，兩者都不是直接排名訊號，但都會影響使用者在搜尋結果頁上「點誰不點誰」的決定。多項研究顯示，帶有 rich snippet 的結果點擊率明顯高於只有標題與描述的陽春版面，道理不複雜：同樣十條結果排在眼前，那條帶星星評分、帶價格、帶麵包屑的，視覺份量就是比較重。版面吸睛只是第一步，進站後的跳出率與 SEO 的關係才決定流量留不留得住，而要精準回溯這些點擊從哪來，就得把UTM 追蹤碼設好。

要體會「版面差一點，點擊差很多」這件事，第三方數據給的尺度最有感。一項分析約 400 萬個 Google 搜尋結果的研究發現，第一名有機結果的平均點擊率為 27.6%，前三名結果合計更吃下 54.4% 的點擊 [來源：Backlinko〈Google CTR Stats: We Analyzed 4 Million Google Search Results〉 https://backlinko.com/google-ctr-stats 2025-04-16]。把這個數字擺在結構化資料的脈絡裡就會明白：當排名位置已經被內容與權威性大致定住，能再擠出點擊的槓桿，就是搜尋結果版面上那一塊帶價格、帶評分、帶麵包屑的 rich snippet，而那正是結構化資料唯一能直接著力的地方。

同一份研究還指出，只有 0.63% 的搜尋者會點到第二頁的結果 [來源：Backlinko〈Google CTR Stats: We Analyzed 4 Million Google Search Results〉 https://backlinko.com/google-ctr-stats 2025-04-16]。這個數字把競爭的殘酷攤得很開：沒有擠進第一頁，再正確的標記也很難被看見；而擠進第一頁之後，能讓你的那一條從十條結果裡脫穎而出的，往往就是那塊多出來的 rich snippet。換句話說，結構化資料搶的是「同分情境下」的點擊，它不會幫你從第二頁搬到第一頁，但能幫你在第一頁裡多拿幾個點擊，這個定位想清楚，才不會對它抱持不切實際的期待。

把這個邏輯放進實際情境裡會更具體。以一個月自然搜尋流量約 3 萬到 8 萬、商品頁落在 SERP 第 4 到第 7 名的中型電商站為例，常見的狀況是：多數商品頁明明排進了第一頁，卻因為版面跟對手一樣只有標題加描述，點擊被前面幾條帶價格、帶星星的結果吸走。當 Product schema 補上、offers 與 aggregateRating 欄位填對、Rich Results Test 也歸零錯誤之後，依這類站的典型表現幅度，帶 rich snippet 的商品頁點擊率大約會比陽春版面多出約 15% 到 30%，少數欄位齊全、價格具競爭力的頁面幅度會再大一點；這個區間來自多篇第三方 CTR 研究與業界普遍觀察，並非任何單一網站的實測數字。要特別誠實講清楚的是：這個增幅有兩個前提，一是頁面本身已經排進第一頁，二是 Google 確實把版面跑了出來，缺任何一個前提，標記再完整也換不到點擊；而且就算兩個前提都成立，提升的也是點擊率而非排名位置，過了三到六個月如果對手也補上同樣的標記，差距又會被追平。所以判斷要不要投入這件事時，比較務實的決策角度是：先把商品頁推進第一頁、確認 Google 願意顯示該類型 rich result，再回頭把 schema 補齊，把這段增幅當作短期內擠出來的紅利，避免把它誤當成長期穩定的排名保證。

但要潑一盆冷水：設了不代表一定會跑出版位。Google 只把結構化資料當作「可用訊號」，而不是「保證顯示」的契約。這跟 Canonical 標準網址 或 noindex 與索引控制 的處境類似，你提供的是建議，最終決定權在 Google 手上。所以把心力放在「提供正確標記」就好，至於版位跑不跑得出來，那是 Google 的事。

• 產生複合式搜尋結果（rich result）：產品價格、星星評分、麵包屑導覽，這些都是結構化資料最常被看見的產物
• 放大點擊率：版面差異化讓使用者在十條結果裡更容易點到你，間接帶動 獲得自然搜尋流量的公式 裡的流量
• 幫搜尋引擎把內容分類正確：避免把一串價格數字當成普通文字掃過去
• 替 AI 搜尋時代 先鋪好語意底層，這層價值常被忽略

JSON-LD、Microdata、RDFa：三種格式的選擇

寫結構化資料建議統一使用 JSON-LD 格式，因為 Google 官方明確推薦它 [來源：Google Search developers〈簡介結構化資料〉 https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data 2026]。它是一段放在網頁裡的 JSON 程式碼，用 @type 標出類型（例如 Product），再填入 name、price、brand 等屬性，本質上像一個結構化的填字遊戲。你只要照著 Schema.org 的欄位定義，一個洞一個洞填完就好。

先看三種格式的差異，這張表是做選擇時最常被引用的比較。

格式	官方推薦	與內容關係	維護成本	主流程度
JSON-LD	是（Google 官方推薦）	獨立區塊，與 HTML 內容分離	低，易批次產生	主流，新專案預設
Microdata	否	嵌在 HTML 標籤屬性內	高，改版面容易連帶改壞	舊站常見，逐漸淡出
RDFa	否	同樣嵌入式	高，語法較繁瑣	較少用

會推薦 JSON-LD，核心原因就一個：它跟網頁內容是分離的。你不用把屬性塞進每一個 HTML 標籤裡，而是把整段 JSON 放在一個獨立的 script 區塊，要改的時候動那一塊就好，不會牽一髮動全身。對動態網站來說尤其友善，工程師可以直接從資料庫串接，一次產出幾十幾百頁的結構化資料。如果你是用 WordPress，Yoast SEO 結構化資料外掛 這類工具也能自動幫你生成基本款，不必每一頁手刻。把WordPress SEO 必做的核心設定一次調好，結構化資料與其他技術項目就能一起到位；搭配WordPress 提交 Google Search Console 的流程，新版面一上線就能被監控。

但外掛是黑箱，懂原理你才有判斷力。底下是一段最精簡的 Product schema 範例，你可以直接拿來改。先用 F12 開發者工具看網頁原始碼 找到頁面上既有的 JSON-LD，再對照下面的欄位結構，會比憑空想像快很多。

{
 "@context": "https://schema.org/",
 "@type": "Product",
 "name": "產品名稱",
 "image": ["圖片網址"],
 "description": "產品描述",
 "brand": { "@type": "Brand", "name": "品牌名稱" },
 "offers": {
 "@type": "Offer",
 "price": "119.99",
 "priceCurrency": "TWD",
 "availability": "https://schema.org/InStock"
 }
}

拆解這段程式碼：@context 指定使用 Schema.org 這套詞彙表，@type 決定這頁的類型是 Product，剩下的 name、image、description、brand、offers 都是 Product 這個類型底下允許的屬性欄位 [來源：Schema.org〈Product〉 https://schema.org/Product 2026]。brand 和 offers 裡面又可以再開一層 @type，例如 Offer 底下再標 url、price、availability。說穿了就是一層包一層的填空題，把該填的欄位填對，就完成了。圖片欄位尤其值得花心氣，因為它同時牽動圖片 SEO 優化能被圖片搜尋撈到的機會；若你跑的是 WooCommerce 賣場，商品頁的欄位結構還能對照WooCommerce 商品頁 SEO 優化逐項檢查。

Product schema 之所以是電商做結構化資料的第一站，是因為價格、庫存、評分這幾個欄位直接牽動轉換。WooCommerce 在 W3Techs 的調查中占所有電商系統的 48.6% [來源：W3Techs〈Usage Statistics and Market Share of WooCommerce〉 https://w3techs.com/technologies/details/cm-woocommerce 2026-06-29]，等於每兩個用 CMS 架的電商站就有一個跑在它上面，商品頁的結構化資料一旦寫錯，影響的往往是一整個分類、甚至全站的價格顯示。這也是為什麼電商在結構化資料上要特別盯緊 offers 區塊：priceCurrency 寫錯幣別、availability 對不上實際庫存、price 與頁面顯示的數字不一致，這些都會讓 Google 對這份標記的信心下降，嚴重時整個 rich snippet 會被收回。

範本去哪找？最權威的兩個來源是 Schema.org 與 Google 關於結構化資料的說明中心，兩邊都提供標準範例可直接改寫。找範本時有個小訣竅：先把對手網址丟進檢測工具（下一節會講），看他用了哪些 @type，再回頭比對官方文件，等於是站在別人的肩膀上少走冤枉路。SEO 是個相對透明的技術，這點對學習其實是好事。

一個常被忽略的細節是 JSON-LD 在 HTML 裡的擺放位置。放在 head 或 body 都可以被讀取，實務上多數會放在頁尾，等主要內容載入後再輸出，避免阻塞首次繪製。如果你的網站用單頁應用（SPA）或大量 JavaScript 動態渲染，要特別確認這段 script 是伺服器端輸出的靜態內容，還是靠 client side 腳本事後注入；後者雖然多數狀況能被讀到，但渲染失敗或延遲過久時，爬蟲抓到的可能是一個沒有 schema 的空頁面，這也是技術 SEO 經常踩的雷。穩妥的做法是讓結構化資料跟著 HTML 一起回傳，把不確定性降到最低。

結構化資料的檢測：零錯誤比零警告更重要

用 Google 官方的「複合式搜尋結果測試（Rich Results Test）」檢測，可貼網址或貼程式碼片段；判讀標準是「零錯誤」即可，警告（warning）屬於可接受的缺漏，因為很多網站本來就沒有 rating、review 等欄位可填 [來源：Google〈Rich Results Test〉 https://search.google.com/test/rich-results 2026]。很多人會把「零警告」當目標，其實沒必要，把力氣花在歸零錯誤上CP值高得多。

這裡要特別澄清一個觀念：錯誤（error，紅燈）跟警告（warning，橘燈）不是同一回事。錯誤代表你寫的結構化資料有根本性的問題，可能是必填欄位漏了、格式不對、JSON 壞掉，這種一定要修。警告代表你「少填了某些選填欄位」，像是 Product 沒有 aggregateRating，Google 只是提醒你「有的話更好」，不影響主體標記被判讀。寧可不填，也不要填錯，這是結構化資料的鐵則。

訊號	燈號	意義	處理原則
錯誤（error）	紅燈	必填欄位缺失或格式錯誤	必須歸零
警告（warning）	橘燈	選填欄位未提供	可接受，不強求
通過	綠燈	結構化資料被判讀成功	目標狀態

• Rich Results Test（複合式搜尋結果測試）：官方主力工具，網址測試和程式碼片段測試都能做 [來源：Google〈Rich Results Test〉 https://search.google.com/test/rich-results 2026]
• Google Search Console：站層級的批次視角，能在報表裡一次看到整站有問題的頁面，適合頁面量大的網站
• 舊版結構化資料檢測工具（Structured Data Testing Tool）已逐步停用，新工作流程以 Rich Results Test 為主

想一次摸熟 GSC 的各個報表，建議先看過Google Search Console 完整使用指南，把索引、成效、結構化資料這幾個區塊的關係弄清楚，批次除錯才不會迷路。

Rich Results Test 有兩種用法。第一種是網址測試，把上線的公開網址整個丟進去，工具會抓回那一頁實際的結構化資料來檢查，適合驗收已上線的頁面。第二種是程式碼片段測試，把還沒上線的 JSON-LD 貼進去就能驗，適合開發階段先試水。我自己最常用的反過來操作：把對手網址丟進去，看他用了哪些 @type、填了哪些欄位，這比看他網頁畫面快多了，也算是 SEO「相對透明」的另一個證明。

頁面一多，逐頁手測就吃不消。這時候 Google Search Console 安裝教學 裡提到的 GSC 就派上用場，它的結構化資料報表會把你整個站有問題的頁面一次列出來，你只要按報表去修就好。跟 Screaming Frog SEO Spider 技術稽核 或 GSC 的常用功能搭配，等於是把整站的結構化資料健康度做批次體檢。大型電商網站幾乎都把 GSC 當日常監控工具，原因就在這裡，不必等到流量掉了才回頭查。想榨出更多用途，可以參考這篇Google Search Console 實戰技巧，把報表讀法與排查流程練熟。

一個容易踩的坑：很多人會發現頁面上明明有漂亮的 rich snippet，丟進 Rich Results Test 卻測不到任何結構化資料。這通常是 Google 自己用演算法抓出來的結果，跟你寫不寫 schema 無關。這個現象在 GSC 網頁索引報表 或 GSC 網址檢查工具 裡也會遇到，遇到時先別慌，確認過自己確實有寫、也通過檢測就好，剩下的交給 Google。

檢測流程的實戰順序與常見除錯

把檢測講成「跑一下工具」太輕描淡寫，實際的排查順序會決定你除錯的速度。建議固定走這四步：先開發階段用程式碼片段測試逐頁驗，確認每種 @type 的必填欄位都齊全；上線後改用網址測試抓回實際渲染結果，比對與開發時是否一致；接著到 GSC 的結構化資料報表看有沒有整批報錯的頁面；最後定期用爬蟲工具掃全站，找出那些你以為寫了、其實漏掉的頁面。把這四步當成固定 SOP，錯誤會在你的使用者發現之前就被攔下來。

• JSON 格式錯誤：少一個逗號、多一個逗號、引號沒成對，是最常見的紅燈原因，貼進程式碼片段測試會直接報壞在哪一行
• 必填欄位漏填：Product 缺 name 或 offers、Article 缺 headline 或 datePublished，補上就會轉綠
• 資料與頁面不一致：標記寫價格 119.99，頁面上卻顯示 309，這種不一致會被視為不可信標記，嚴重時整份 schema 失效
• 巢狀結構寫錯：brand 或 aggregateRating 沒有再開一層 @type，工具會抓不到對應類型
• 重複輸出：外掛與手寫同時輸出兩份 Product schema，欄位打架會讓判讀結果不穩定

截至 2026 年，Google 還支援哪些結構化資料類型

截至 2026 年 6 月，Google 已完全停用 How-To、Event、Sitelinks Search Box 等近十種 rich result 類型，FAQ 也自 2023 年 8 月起僅限政府與醫療等權威網站顯示，麵包屑則在 2025 年初起行動版不再顯示 [來源：Google Search Central〈Google 搜尋的搜尋成果類型更新〉 https://developers.google.com/search/blog 2026]。設定前先確認該類型仍在支援清單內，否則就是白做工。這也是為什麼我每次看到「教學文說加 FAQ 就會出星星」都會皺眉頭，因為那個星星對絕大多數網站早就消失了。

把停用時程攤開來看，你會發現 Google 收緊 rich result 的速度其實很快。底下這張表把幾個關鍵類型的狀態整理出來，做決定前先對一下。

類型	狀態	時間點	影響
How-To	完全停用	2023-09	全裝置不再顯示
Event	完全停用	2023-10	事件摘要版位移除
FAQ	受限	2023-08 起	僅政府與醫療等權威網站顯示
Sitelinks Search Box	完全停用	2024-11	全面下線
Breadcrumb	部分停用	2025-01 起	行動版不顯示，僅桌面保留
Product	有效	—	價格、庫存、評分仍顯示
Article	有效	—	新聞與文章內容適用

表外的補充只有一條值得記：除了上面列出的停用與受限類型，Product、Article、Review、Organization、VideoObject 這幾個常見類型目前仍有效，是現在仍值得投入標記的主力 [來源：Google Search Central〈搜尋結果呈現方式〉 https://developers.google.com/search/docs/appearance/structured-data 2026]。其餘像 Book Actions、Course Info、Claim Review、Estimated Salary、Learning Video、Special Announcement、Vehicle Listing 也都已完全停用，投入前先確認。

這裡有個很多人沒想通的事：FAQ rich result 對一般網站已經停用了，那 FAQPage schema 還要不要寫？我的答案是寫。語意標記本身是 AI 引用你內容時讀的底層資料，砍掉它反而吃虧。麵包屑也是同樣的道理，行動版不顯示了，但網站架構與內部連結的語意關係，breadcrumb schema 還是會幫 Google 與 AI 理解。

想知道某個頁面適用哪種類型，最直接的方式是搜尋「OO 結構化資料」或「OO structured data」，例如「review structured data」「食譜 結構化資料」，通常能找到官方文件。現在也可以直接問 AI：「我的網頁是某種內容，有沒有適合的結構化資料類型？」不過要記得交叉驗證，因為 AI 偶爾會給你已經停用的類型。這也是為什麼手邊要隨時有 超過 31 個 SEO 工具推薦 或 DataForSEO SEO API 教學 這類資源備查。

釐清「停用 rich result」與「停用 schema」的差別，是這一節最關鍵的觀念。Google 停用的是「在搜尋結果顯示特殊版面」這個前端呈現，不是停用 schema.org 這個詞彙標準本身。換句話說，How-To 的 rich result 消失了，但 HowTo 這個類型仍然存在於 schema.org，你寫了它，Schema.org 與其他讀者（包括 AI 模型、第三方工具）依然讀得到。把這兩件事分清楚，才會知道為什麼有些已停用版位的類型仍然值得標記：版面是 Google 的選擇，語意則是公開標準，後者的壽命遠比前者長。

四個常見誤解：從「設了就出現」到「Google 夠聰明就不用做」

圍繞結構化資料的誤解，本質上都來自同一個源頭：把「我寫了標記」與「Google 一定照辦」畫上等號。實際上多數 rich result 類型只被當成可用訊號，要不要顯示是 Google 說了算，你寫了 Product schema，價格不一定跑出來；寫了 Review，星星不一定亮。這跟 Canonical 處理重複內容、Open Graph 標籤讓網站被漂亮分享 是同一類機制，你給的是建議，不是命令。設了不等於出現，這是第一個要拆掉的預期。

第二個預期更隱晦：以為所有標記的欄位都會在版面上現身。評論內容、品牌資訊這類欄位常常不顯示，但這不代表白做。版面是 Google 的選擇，背後的標記仍持續替你累積「被正確分類」的資本，這層價值在 Entity SEO 與實體概念 那種看不見卻會疊加的優化上尤其明顯。把判斷標準從「畫面有沒有變」換成「語意有沒有被讀對」，才不會誤判效益。

把「顯示與否」和「欄位完整與否」分開看，處理原則就清楚了：錯誤（紅燈）代表必填欄位缺失或格式錯誤，必須歸零；警告（橘燈）只是選填欄位沒提供，屬於可接受狀態。為了把橘燈全壓成綠燈而硬填不存在的欄位，反而會把資料弄髒，這跟 重複內容對 SEO 的影響、網站使用體驗核心指標 CWV 的優化哲學一致，抓主要矛盾就好，不必樣樣滿分。所以檢測目標只有一個：零錯誤。

誤解	實際運作	正確做法
設了就會出現	多數類型僅為可用訊號，顯示與否由 Google 決定	寫對標記，其餘等待
所有欄位都會顯示	評論、品牌等欄位常不顯示，但語意仍被讀	看語意是否讀對，而非畫面
要追求零警告	警告是選填欄位未提供，可接受	只求零錯誤
Google 夠聰明就不用做	偶爾能自動抓，但遠未穩定到可取代	主動標記仍是更可控的做法

最後一個誤解是「Google 夠聰明就不用做」。某些網頁沒寫 schema，搜尋結果卻出現特殊資訊，那是 Google 用演算法自己撈的；但「偶爾能撈」不等於「穩定能撈」，把判讀交給運氣，等於把生殺大權交給一個還不夠聰明的系統。主動標記始終是更可控的做法，它本來就是 SEO 工作者的日常功課，跟定期看 網頁速度如何優化、HTTPS 與網站安全性 一樣，是基本功不是選配。

結構化資料的優先級：什麼時候該往後排

結構化資料是放大器，放大的是你既有的內容與排名，基本盤沒站穩之前，再漂亮的標記也只是給一頁沒人看的內容貼便利貼。底下這張決策表把常見的「先放著、別急著做」情境列出來，做取捨時直接對照。

情境	建議	理由
頁面還排不進前兩頁	先放著，補內容與權威	排名上不去，rich snippet 再漂亮也沒人點
內容與搜尋意圖對不上	先放著，重寫內容	標記正確但內容不符，仍不會被採用
網站有大量重複內容或被索引問題	先放著，處理索引與 Canonical	連頁面都沒進索引，標記再完整也讀不到
頁面類型不在 Google 支援清單	不強求版面，視需要標記	停用類型不會產生 rich result，標記僅供 AI 與其他讀者
內容薄、靠拼湊產生	先放著，補厚內容	薄內容配完整標記，等於把缺陷講得更清楚

這張表的核心訊息是順序問題。Technical SEO 的優先級，向來是「先能被讀到，再被讀懂，最後被讚美」。能被讀到指的是頁面正常索引、沒有被擋；被讀懂指的是內容符合搜尋意圖、權威性夠；被讚美才是 rich snippet、麵包屑這類版面加分項。結構化資料落在第三層，把它放在第一層之前做，等於裝潢一棟還沒打地基的房子。先確認如何確認網頁被 Google 索引、把Canonical 標準網址與noindex 與索引控制調對，再回頭碰結構化資料，投資報酬率才會高。

結構化資料與 AI 搜尋：GEO 時代它反而更重要

有，而且比過去更重要。在 GEO 是什麼與 SEO 的差異 與 AEO 的脈絡下，大型語言模型讀的是網頁的語意標記本體，而非複合式搜尋結果版位。結構化資料讓 ChatGPT、Google AI Overviews、Perplexity 更容易正確引用你的產品規格、評分、FAQ，即使某個 rich result 版位已被 Google 下架，語意標記仍是 AI 引用的關鍵依據。

這是我跟多數教學看法最不一樣的地方。很多文章把結構化資料講成「加這段就會出現星星評分」的特效藥，但 2023 年起 Google 已陸續停用近十種 rich result 類型，真正該追求的是「語意層正確、零錯誤」，把重心擺在「畫面漂亮」反而會走偏。因為 AI 搜尋讀的是語意標記本體，至於那塊複合式搜尋結果版位則不在它的閱讀範圍。這個判斷在 AI 搜尋引擎推薦與分析 與 GEO、AEO、LLMO 一次看懂 的討論裡越來越被驗證。

實務上，LLM 在結構化資料的工作流程裡能做四件事。最基本的用法是產生：把產品名稱、價格、庫存、圖片網址丟進對話，模型一次就能回傳完整的 JSON-LD 區塊，重複頁面只要換掉變數就能批次產出，對於商品規格齊全、欄位重複度高的站點尤其能省下手刻時間。產出之後還能反過來驗證：把 JSON-LD 貼回模型比對必填欄位，缺漏的 offers、brand 當場被抓出來，再交 Rich Results Test 做最終確認。另一個被低估的能力是抽取，讓模型讀完網頁 HTML，自動把 Q&A 區塊整理成 FAQPage、把規格表整理成 Product schema。進階一點則是批次自動化，透過 OpenAI Structured Outputs 在函式呼叫時加上 strict:true，鎖死回傳結果符合指定 JSON Schema，再掛上 CMS hook，內容一發布結構化資料就跟著寫進去 [來源：OpenAI〈Introducing Structured Outputs in the API〉 https://openai.com/index/introducing-structured-outputs-api/ 2024]。

LLM 應用場景	輸入	輸出	適合搭配
產生 JSON-LD	關鍵欄位清單	完整 schema 區塊	Rich Results Test 驗證
驗證除錯	既有 JSON-LD	缺漏欄位清單	人工複核語意
內容抽取	網頁 HTML	FAQPage / Product	CMS 自動寫入
批次自動化	資料庫欄位	結構化輸出	Structured Outputs strict:true

但要注意一個風險：LLM 偶爾會吐出已經停用的類型，像是 How-To 或 Event。這正是AI 幻覺的典型樣態，模型會把不存在的功能講得煞有其事，所以最後一步一定要回到官方清單核對。這也是前面一直強調「先查支援清單」的原因，再讓 AI 幫你寫。把 AI 產出的結果丟進 Rich Results Test 跑一遍，是最穩的雙重保險。這也呼應 Google 對 AI 生成內容的原則：內容本身的品質與正確性才是關鍵，AI 只是加速器。

往大一點的趨勢看，結構化資料在 Google AI Mode 搜尋新變革、品牌要成為被推薦的答案、AXO AI 全搜尋體驗優化 這些新場景裡，角色只會越來越重。因為 AI 引用你的時候，要的不是一個漂亮的版面，而是「這個欄位的定義是什麼」的明確答案，而這正是結構化資料唯一在做的事。搭配 RAG 檢索增強生成與 SEO 應用、迎接 AI Agent 瀏覽時代 的發展，語意標記等於是 AI 時代的「名片格式」，格式標準、欄位齊全，才容易被正確引用。

把前面的脈絡收攏成一句：版位會被下架，語意標記不會，而 ChatGPT、Google AI Overviews、Perplexity 引用你內容時讀的正是後者。這也對上 AI 時代 SEO 的七個建議 與 資訊增益與內容差異化 一再強調的方向，差異化、結構化、語意正確的內容，才是這些模型願意回頭引用的內容。連頁面本身的版面與互動也要顧，常見的自架網站網頁設計地雷會默默拖累整體表現；想從觀念到實作一次補齊，也能參考一套SEO 排名提升線上課程把基礎打穩。

進階策略：同一頁能不能標多種類型，以及疊加的取捨

很多做到中階的 SEO 工作者會問：一個頁面能不能同時標 Product 又標 Review、Breadcrumb 又標 Organization？答案是可以，而且疊加多種類型是大型網站的常見做法，但疊加有它的取捨，不是越多越好。判斷的準則只有一條：每一種你標上去的類型，都要對應到頁面上實際存在、且使用者能看見的內容。標了一個頁面上根本沒有的 AggregateRating，等於自己把不可信的資料送給 Google，後果比不標還糟。

底下這張矩陣把常見的疊加組合分成四個象限，幫你判斷哪些該加、哪些要克制。橫軸是「是否對應頁面可見內容」，縱軸是「是否屬於仍在支援的 rich result」。

象限	對應可見內容	仍在支援	建議	典型例子
第一象限	是	是	積極標記	商品頁同時標 Product 與 Offer
第二象限	是	否	標記給 AI 與語意用	教學頁標 HowTo（版位已停用，語意仍在）
第三象限	否	是	克制，等內容補上再加	頁面無評分卻硬標 AggregateRating
第四象限	否	否	完全不標	隨意堆疊不相關類型

第一象限是甜蜜點，商品頁標 Product 配 Offer、文章頁標 Article，這些既對應可見內容、又仍在支援清單，投資報酬率最高，理應優先做滿。第二象限是長期投資，像是教學頁標 HowTo，雖然 rich result 版位停用了，但 HowTo 的步驟結構對 AI 引用、對Entity SEO 與實體概念的語意累積仍有價值，做了不虧，只是不要期待畫面上會出現東西。第三象限是最危險的，頁面上沒有評分機制，卻為了湊出星星硬塞 AggregateRating，這種標記一旦被判定為不實，整個網站的標記可信度都會受牽連，穩妥的做法是先把評分功能做出來再標。第四象限純粹是噪音，把它從工作清單裡刪掉就好。

疊加時還有一個技術細節要注意：同一份 JSON-LD 裡可以用 @graph 把多個類型包成一個陣列一次輸出，這比在頁面上散落好幾個獨立的 script 區塊好維護，也讓爬蟲一次讀完整頁的語意結構。實務上，一個商品頁常見的 @graph 會包含 Organization、WebSite、BreadcrumbList、Product、AggregateRating 這幾個類型，把它們組織成一份完整的「網站名片」，是大型電商與媒體站的標準做法。把這個模式學起來，遇到內容複雜的頁面就能有條理地拆解，不會手忙腳亂。

實作檢核表與常見問題 FAQ

動手前先確認四件事：選 JSON-LD 格式、只設定仍在支援清單內的類型、以 Rich Results Test 達到零錯誤為目標、並理解「設了未必顯示但語意仍有價值」。掌握這四點，就能避免把力氣花在被淘汰的類型上。底下這張檢核表，建議每次上新頁面或改版時都過一遍。

• 格式統一用 JSON-LD，避免 Microdata / RDFa 混用增加維護成本
• 類型先查 Google 支援清單，跳過已停用的 How-To、Event、Sitelinks Search Box
• 上線前用 Rich Results Test 跑過，確認零錯誤，警告可接受
• 搭配 Google Search Console 持續監控大量頁面的結構化資料健康度
• 頁面結構呼應網站架構、內部連結、XML Sitemap 與爬取優化、robots.txt 對 SEO 的效果，讓爬蟲與 AI 都讀得順
• 網站整體的SEO 友善網頁結構設計與網站 Sitemap 規劃指南，是結構化資料之外另一層讓機器讀懂全站的工程

結構化資料不該孤立來看。它與 Canonical、noindex、如何確認網頁被 Google 索引 同屬「讓 Google 更懂你」的工程，彼此不衝突，可以一起做。但再正確的標記，只要內容與搜尋意圖對不上就沒用，權威性也得靠 E-E-A-T 高品質內容原則 與 反向連結與網域權重 累積。把它放在這整片 Technical SEO 盤面裡衡量，才知道什麼時候該排前面、什麼時候該往後挪。

常見問題 FAQ

FAQPage schema 在一般網站的星星版位已停用，還要寫嗎？
要寫。版面歸 Google 的前端呈現決定，語意標記本體則是 ChatGPT、Google AI Overviews、Perplexity 引用問答內容時讀的那一層底層資料，砍掉等於自己斷掉被 AI 引用的入口。這也是「停用 rich result」不等於「停用 schema」最具體的例子。

麵包屑行動版不顯示了，BreadcrumbList 還值得標嗎？
值得。行動版的前端版位拿掉了，但 breadcrumb schema 描述的是網站層級與內部連結的語意關係，Google 與 AI 模型仍會讀它來理解你在資訊架構裡的位置。桌面版也還保留顯示，等於一面維持語意、一面留著桌面紅利。

外掛和手寫同時輸出兩份 Product schema 會怎樣？
欄位會打架，判讀結果變不穩定，Rich Results Test 也容易報錯。排查時優先確認頁面上是不是有兩個以上的 JSON-LD script 在講同一個 @type，留一份欄位最齊全的，其餘停用。這比逐欄位除錯更常是問題根源。

SPA 或大量 JavaScript 渲染的站，JSON-LD 要怎麼放才穩？
讓它跟著 HTML 一起在伺服器端回傳，盡量別靠 client side 腳本事後注入。事後注入在多數狀況能被讀到，但渲染失敗或延遲過久時，爬蟲抓到的會是一個沒有 schema 的空頁面。靜態輸出能把這層不確定性降到最低。

OpenAI Structured Outputs 在結構化資料工作流程裡能做什麼？
在函式呼叫時加上 strict:true，鎖死模型回傳結果符合你指定的 JSON Schema，再掛上 CMS hook，就能讓內容一發布、結構化資料跟著寫進去，做到批次自動化。產出仍要丟回 Rich Results Test 驗證，因為模型偶爾會吐出已停用的類型。

頁面上明明有 rich snippet，Rich Results Test 卻測不到任何結構化資料，是寫錯了嗎？
通常不是。那往往是 Google 自己用演算法抓出來的結果，跟你寫不寫 schema 無關。先確認自己確實有寫、也通過檢測就好，剩下的交給 Google，不必把力氣花在解釋別人的版面。