結構化資料完整指南：從入門觀念到 Schema 實作

結構化資料（structured data）在 2026 年的真實角色，跟你聽過的各種「標 Schema 比較容易被搜尋引擎看懂」的說法，已經不是同一回事。大型語言模型早就讀得懂一般網頁，它不需要你幫它翻譯或鋪路。Schema.org 標記真正在做的，是降低搜尋系統與生成式摘要系統「把你這頁的內容直接放進答案」的成本與錯誤率。理解了這一點，你才會知道哪些標記值得做、哪些只是標心安，也才會知道為什麼標了 Schema 流量卻沒動。

為什麼要重新定義 Schema 的角色

過去十年最流行的 Schema 教學框架，背後假設是「搜尋引擎讀不太懂你的網頁，所以你要用結構化資料補位」。這個前提在 2014 年成立，在 2026 年站不住腳。

理由很簡單。今天的爬蟲與排序系統背後是能讀懂整頁語意的模型。你寫「2026 年 3 月 15 日下午兩點」，它知道是活動時間；你寫「4.7 顆星，1,283 則評論」，它知道是評分。它不需要 Schema 才能分辨這些事。如果你還停留在「Schema 等於幫 Google 看懂」的框架，你會對它真正的價值視而不見。

那 Schema 到底還有什麼用？答案不是「理解」，是「取用」。

搜尋引擎和生成式摘要系統在產出答案時，要的不只是懂，而是能在極低錯誤率、極低成本下，把這段內容抽出來組進答案。當它要決定是否把你的頁面變成 rich result（複合式搜尋結果）、是否在 AI Overview 引用你、是否放進語音助理的回答時，它評估的是抽取成本與可信度。Schema 就是降低這個成本的介面。

換句話說，Schema 解決的不是「看不懂」，是「抽取太貴」。這也是為什麼標了 Schema 不保證流量會動。流量要動，前提是搜尋系統本來就打算用你的內容組答案，而你只是讓這件事變便宜。

老實說，這個框架轉換會改變你所有的實作決策。如果你以為 Schema 是翻譯，你會傾向把所有東西都標上去。如果你理解它是取用介面，你會優先標那些「搜尋系統有明確版位要填、而你的內容正好對得上」的部分。這也是我整篇文章的組織邏輯：不再從「Schema 是什麼」講起，而是從「誰在讀 Schema、它們各自要什麼、怎麼倒推該標什麼」講起。

把 Schema 想成對搜尋系統的申報單，而不是翻譯

換一個比翻譯更貼切的切入點。把 Schema 想成你主動遞給搜尋系統的一張申報單，而不是把頁面翻譯成機器語言。翻譯這個比喻背後假設原文太難懂所以需要轉換，但 2026 年的搜尋系統讀得懂中文頁面，它缺的根本不是理解，而是一份你可以為自己內容負責的正式聲明。

申報單的運作邏輯跟翻譯完全不同，它有幾個固定特徵。欄位是對方開的，不是你自由發揮；Google 各 rich result 類型的 required 與 recommended properties 要分開依現行文件判斷。Product 的必要欄位會依 product snippet 或 merchant listing 情境而異，不是一律同時要求 offers 與 aggregateRating；Article 沒有 required properties，author 與 datePublished 是建議欄位。內容仍必須跟頁面上看得到的資訊一致，送出標記也不等於會被採用。

這個框架解釋了幾件翻譯框架解釋不了的事。為什麼標了 Schema 卻沒拿到版位，因為申報只是入場，對方不一定要用。無效標記通常是失去 rich result 資格或該標記被忽略；只有欺騙性、不可見或違反政策的標記，才可能遭 structured data manual action，而且不會直接降低一般網頁排名。Google 反覆強調標記要與可見內容一致，因為欄位需要能與頁面內容交叉驗證。

從申報的角度切入，你會自然問出更接近成敗核心的問題：這個欄位我頁面上真的有對應內容嗎、我願意為這個聲明背書嗎、這份申報的證據夠不夠扎實。把 Schema 當申報單看待，後面所有該標什麼、怎麼驗證、哪些違反政策的標記可能被處置，都會自然走到對的位置。

Schema 對三種讀者的不同價值

講 Schema 的文章最常把「搜尋引擎」當成單一讀者，這是根本性的誤解。你的 Schema 被至少三種系統讀，而它們在乎的事情完全不一樣。

第一種是爬蟲與索引系統。它們在乎的是這頁的實體類型是什麼（文章、產品、事件）、主屬關係是什麼（屬於哪個網站、作者是誰、隸屬哪個組織）。Schema 在這裡幫的是分類與去重，讓索引系統不會把同一件事當成三件不同的事。Organization、Person、BreadcrumbList 在這一層最有價值。

第二種是排序系統。它們在乎的是這頁的內容與查詢的實體關係有多強、作者與組織的可信度訊號夠不夠。Article 標記裡的 author、datePublished、publisher 對 E-E-A-T（經驗、專業、權威、可信）相關訊號有輔助作用，但它不是排名的直接開關。把它當排名保證，是常見的誤判。Google 多次公開說明結構化資料不是排名的直接因素，它的價值在於換取 rich result、提升分類準確度，而非把你往上排。

第三種情境是生成式摘要與 AI 引用。清楚、可查證且能脫離上下文理解的價格、規格、步驟與問答，通常較容易被各種系統解析；適用的結構化資料可協助搜尋引擎理解頁面內容及判斷部分複合式搜尋結果資格，但不保證被生成式 AI 引用。標記內容必須與頁面可見文字一致，並遵守各類型的官方規範。

把這三種讀者分清楚，你就會知道為什麼「標了 Article 卻沒看到流量成長」是正常的，因為 Article 標記的價值主要在索引與排序訊號，不在 rich result。你也會知道為什麼電商網站標 Product 的優先級遠高於標 Article，因為 Product 對應的是會直接出現在 SERP 上的評論星等與價格版位。

先看版位再標記：從 SERP 倒推的工作法

多數人標 Schema 的方式是看官方文件有哪些 type，挑看起來相關的，標上去，等結果。這是直向工作法，效果通常很差，因為它假設「標了就會被用」。實際上 Google 是用「我有這個版位需要這個 Schema 的某些欄位，你的頁面剛好對得上、且政策合規，我才給」的邏輯在運作。

我的建議是反向工作法：先看你的目標查詢在 Google 上實際出現什麼版位，再倒推要標什麼。實際步驟如下。

第一步，打開無痕視窗，搜尋你的目標關鍵字，看 SERP 上出現哪些 rich result 類型，例如評論星等、FAQ、麵包屑、價格、事件時間、食譜卡、怎麼做步驟。第二步，把這些版位類型記下來，這就是 Google 目前願意用結構化資料組裝的版位清單。第三步，針對對應的 Schema type 查 Google 官方 Rich Result Gallery，看它要求哪些屬性、有哪些政策限制。第四步，評估你的頁面內容是否真的能填滿那些屬性，且與可見內容一致。填不滿就別標。第五步，標完用 Rich Results Test 驗證，再看 Search Console 的增強項目報告有沒有錯誤。

這個順序的關鍵在於視角的反轉。你不是在「為頁面找 Schema」，而是在「為版位找供應商」。版位是稀缺的，Google 只會給那些內容真實對應、政策合規、且 Schema 正確表達的頁面。

舉個常見情境（示意）。你經營一個食譜網站，發現你的食譜關鍵字 SERP 上有圖片卡、評論星等、料理時間。這三個版位分別對應 Recipe 的 image、aggregateRating、totalTime 屬性。你優先標這三個，比你把 Recipe 全部 30 幾個屬性都填滿更有效，因為 Google 真正在用的就是那幾個欄位。

反向工作法還有一個好處：它會逼你面對「你的內容到底值不值得這個版位」。如果你的食譜頁連料理時間都沒寫、沒有任何讀者評分，那標 Recipe 也拿不到料理時間版位與星等。Schema 是放大器，它放大的是你已經做對的內容，不是無中生有。

哪些 Schema 真的換得到 rich result

Google 多年來持續縮減哪些 Schema type 能換到 rich result。原因是早期太多網站用垃圾標記騙版位，所以 Google 改成政策合規加上品質門檻的雙重把關。這意味著「標了就有版位」的年代早就過去了。

從這張表可以讀出幾件事。BreadcrumbList 與 Organization 是多數站可評估的基本款，但仍要對應真實導覽與組織資料。FAQ rich result 已自 2026 年 5 月 7 日停止在 Google 搜尋顯示，HowTo rich result 也已停止支援；保留對應 Schema.org 詞彙是否有其他系統用途，要依實際需求評估，不能再用 Google 版位當投資理由。Product、Recipe、Event、LocalBusiness 對內容真實對應的要求高，標記與可見內容不一致會失去 rich result 資格，欺騙性標記則可能觸發人工處置（見 Google Search Central 的文件更新紀錄）。

簡單講，挑 Schema 不是挑你看起來像哪種，是挑你願意且能夠對著 Google 政策發誓你的內容真的符合的那種。

觀念分層：類型、屬性、詞彙與序列化格式

很多人講 Schema 時把四個不同層次的觀念混在一起，越講越亂。把它們分清楚，官方文件才看得懂。

類型（@type）是「這個東西是什麼」。Article、Product、Event、Recipe 都是類型。類型決定了哪些屬性可以用，也決定了 Google 願不願意給你哪種版位。同一個頁面可以有多個類型，但每個類型的政策門檻不同。

屬性（property）是「這個東西有哪些欄位」。Product 有 offers（價格）、aggregateRating（評分）、brand（品牌）；Article 有 author、datePublished、headline。屬性分必填、建議、選填，這是 Google 文件裡寫得很清楚的。必填沒給就拿不到版位，建議沒給會降低競爭力，選填不給無所謂。

詞彙（vocabulary）指的是 Schema.org 這套由 Google、Microsoft、Yahoo、Yandex 在 2011 年共同發起的開放詞彙表。Schema.org 是詞彙，不是格式，這是常見的混淆。你可以用任何格式來表達 Schema.org 詞彙，就像同一份食譜可以寫在不同形式的紙上。

序列化格式（format）是你把詞彙用什麼樣的語法寫出來。JSON-LD、Microdata、RDFa 是三種主流格式。它們表達的是同一套 Schema.org 詞彙，差別在寫法與維護成本。

分清楚這四層，你才會理解為什麼「我用了 JSON-LD 為什麼還是沒拿到 rich result」這個問題本身問錯了。JSON-LD 是格式，rich result 取決於類型、屬性、政策合規，跟格式幾乎無關。換格式不會解決你的政策問題，就像換信紙不會改變信的內容。

用 @id 把單頁標記串成站級實體圖

多數人停在每頁一份獨立 JSON-LD 的層次，但 Schema 真正的進階價值在於把全站標記串成一張可被搜尋系統重複引用的實體圖。關鍵欄位是 @id 與 sameAs，而這兩個欄位在入門教學裡幾乎都被略過。

@id 的作用是給每個實體一個穩定的全球識別碼。你的 Organization 標記不該只在首頁出現一次，而該在每個出現的地方用同一個 @id（例如 https://www.your-site.com.tw/#organization）指向同一個實體。Author 同理，同一位作者出現在全站多篇文章裡，每篇的 author 欄位都可用同一個 @id 指向同一個 Person 節點。穩定 @id 可減少同一實體被重複建模的歧義，但不能把它寫成可量化的作者權威累積。

sameAs 則是把站內實體連到站外的權威紀錄。Organization 的 sameAs 該連到 Wikipedia 條目、官方 LinkedIn、公開 Facebook 專頁這類第三方具公信力的紀錄，這是讓 Google 知識圖譜把你這個組織與網路上同名實體黏合的證據。Person 的 sameAs 可以連到作者本人的 LinkedIn 或社群帳號。但 sameAs 不是越多越好，連到不相干平台或低品質頁面反而稀釋訊號，原則是只連到你自己能控制、或第三方具公信力的紀錄。

實作上應盡量維持 @id 穩定，以減少同一實體被重複建模的歧義；若需要變更，應同步更新所有引用。變更 @id 不代表舊實體被殺掉或排名權威歸零。

網站改版與網址遷移：保住實體關係

改網域、URL 規則或 CMS 時，Schema 常在「頁面看起來正常」的情況下斷掉。準備階段先列出舊 URL 到新 URL 的一對一對照，再盤點哪些 URL 同時被用作 canonical、@id、url、mainEntityOfPage、作者頁與組織節點。頁面搬家後要同步更新這些引用，不能只做轉址。新的頁面使用自我參照 canonical，舊 URL 導向對應的新 URL，不要全部導到首頁。

Google 對網站遷移的官方建議包括測試轉址、用 URL Inspection 抽查、提交新 sitemap，並將轉址保留盡可能久，通常至少一年，讓搜尋系統有時間重新檢索並移轉訊號（見 Google 的網站搬遷指南）。這個一年是轉址維護建議，不是排名恢復保證。若 @id 使用舊網域 URL，改版前要決定是否維持可解析的穩定識別碼，或將所有引用一次遷到新值；不要假設只改 @id 就會自動移轉搜尋訊號。

發布不要全站一次切換。先挑少量、可代表主要模板的文章、產品與地點頁，驗證舊 URL、轉址、新 canonical、渲染後 JSON-LD 與可見內容，再擴大。上線後同時看索引、rich result 狀態與有效項目數；有效項目下降但無錯誤增加，常見原因是新模板漏掉標記，不代表資料品質突然變好。改版檢查表要把 HTML、Schema、canonical、sitemap 與內部連結放在一起，才能避免只修其中一層。

為什麼 JSON-LD 是預設選擇

Google 官方對多數情境推薦 JSON-LD，這不是宗教戰，是有具體理由的。

JSON-LD 是一份獨立的 <script type="application/ld+json"> 區塊，跟 HTML 視覺內容分離。這個分離帶來幾個實質好處。你可以不用動到 HTML 結構就加上或修改 Schema，這對既有網站很關鍵。透過 CMS、tag manager、server-side rendering 都能集中注入，維護成本最低。它與設計重構脫鉤，下次改版不會把 Schema 一起改壞。它也比較容易用程式批量生成，對電商或內容站特別友善。

Microdata 與 RDFa 把標記嵌在 HTML 屬性裡（itemprop、property），與視覺內容綁死。優點是標記與可見內容必然一致，缺點是維護成本高、改版易出錯、對大量頁面不友善。在內容管理系統老舊、或頁面結構不允許插入獨立 script 的場景，Microdata 才是合理選擇。

Google 可以在渲染後處理由 JavaScript 產生的 JSON-LD，但這會增加對渲染流程與執行時機的依賴；價格、庫存等快速變動資訊尤其要注意可見內容與標記是否同步。能在伺服器回應中輸出正確標記時，可降低實作複雜度；無論採哪種方式，都應使用 Rich Results Test、URL Inspection 與實際抓取結果驗證。

把 Schema 寫成可測試的資料契約

大量頁面的 Schema 不該靠編輯逐欄手填，而要把每個類型定義成資料契約。契約至少寫清楚主類型、欄位來源、資料型別、是否允許空值、顯示在頁面的對應位置、更新責任與 Google 功能文件版本。以 Product 為例，name 從商品主檔取值，offers.price 與可見售價共用價格服務，availability 由庫存狀態轉換；沒有真實評論時，aggregateRating 整個省略，不輸出零分或樣板值。

測試分成三層。單元測試檢查 JSON 能解析、URL 與日期格式正確、條件欄位只在有資料時輸出；模板測試用幾組固定資料，確認一般商品、售罄商品、無評論商品與變體頁都產生預期節點；發布後測試則抓實際 URL 的渲染結果，比對可見價格、庫存、作者與 JSON-LD。Google 可處理渲染後 DOM 裡的 JavaScript 產生標記，但官方提醒動態 Product 標記可能讓快速變動的價格與庫存檢索較不可靠；測試應以 URL 模式檢查實際渲染內容（見 Google 對以 JavaScript 產生結構化資料的說明）。

資料契約還要處理政策版本。Schema.org 詞彙、Google rich result 文件與站內可見內容是三個不同層級：詞彙存在，不等於 Google 仍提供對應版位；測試工具通過，也不等於內容符合品質規範。每個主類型指定負責人，在 Google 文件變更、CMS 欄位改名、資料服務改版時重跑契約測試。Google 官方建議開發時用 Rich Results Test，部署後用 rich result status report 監控模板或供應問題（見 官方的結構化資料入門說明）。

驗證與維護：被多數人忽略的真實成本

Schema 的真實成本不在實作，在維護。這句話不是老生常談，是大多數 Schema 專案失敗的原因。

實作 Schema 是一次性投入：寫好模板、套到所有頁面、跑一次 Rich Results Test 驗證、送出。但維護是持續性的，而且錯誤是隱形的。

商品價格變了，Schema 裡的 offers 還是舊的。商品下架了，Schema 還標著 InStock。活動結束了，Schema 還標著未來日期。作者離職了，Schema 還連到舊的 author URL。改版時工程師把 JSON-LD 拿掉了，沒人發現。每一條都會讓 Google 偵測到「標記與可見內容不一致」，輕則取消 rich result 資格，重則被歸類為垃圾標記。問題是這些錯誤不會跳出報錯，你只會看到 rich result 消失，然後花很長時間才追溯到是 Schema 問題。

避免這個問題的根本做法是建立單一真相來源（single source of truth）。Schema 的每個欄位都應該從同一個資料來源自動生成，不要讓人手動填。電商的 Product Schema 應該從商品資料庫直接取，不該由行銷人員在 CMS 裡手填。Article 的 author 應該從作者資料庫取，不該寫死在模板裡。價格、庫存、活動日期這類會變動的欄位，必須由即時資料源驅動，不能放在快取。

並定期做三件事。每月跑一次 Search Console 的增強項目報告，看有沒有新增錯誤。每季抽樣用 Rich Results Test 測幾個重要頁面，看 Schema 與可見內容是否一致。每次網站改版後，跑全站 Schema 一致性檢查，因為改版是 Schema 出錯的高峰期。

這三件事的成本遠低於你標完 Schema 然後三年不聞不問、最後被 Google 撤銷 rich result 資格的修復成本。很多網站不是輸在沒標 Schema，是輸在標了就忘。

常見錯誤機制與反例

Schema 的錯誤有幾種典型模式，看完就知道你的網站有沒有踩到。

隱形垃圾標記是最容易被 Google 抓到的。你標了 aggregateRating，但頁面上根本沒有讀者評論。Google 會比對標記與可見內容，這類對不起來的標記會被歸類為垃圾。常見於聯盟行銷網站、內容農場、新建電商站急著要星等。

過度標記是另一極端。把頁面上每一個小元素都標成獨立實體，一篇食譜文章標了 Recipe、HowTo、Article、WebPage、FAQPage，每個類型都半套。Google 會看到一堆不完整的 type，反而降低整體可信度。一頁一個主類型是比較安全的做法。

標記與可見內容不一致是最常見的維護型錯誤。頁面顯示 NT$1,290，Schema 裡寫 NT$890。這在動態定價的電商很常見，因為 Schema 從快取取，可見內容從即時 API 取，兩邊不同步。這也是為什麼前面強調單一真相來源。

用不存在的 type 是新手錯誤。自行發明 Schema.org 沒有的 type，例如 "@type": "AwesomeProduct"。Google 直接忽略，等於沒標。Schema.org 的 type 表是固定的，你不能擴充。

標記了但政策不符是中階錯誤。標了 Event，但活動日期已過；標了 LocalBusiness，但沒有實體店面地址；標了 Review，但評論對象不是產品而是整個網站。這些都違反 Google 政策。

重複標記同一內容是技術債錯誤。同一份 JSON-LD 出現兩次，或 JSON-LD 與 Microdata 同時標同一件事，會讓 Google 困惑該用哪一份。

這幾個錯誤的共同點是它們都不是技術錯誤。Schema 本身格式正確、可以通過 Rich Results Test。它們是政策錯誤與一致性錯誤，工具測不出來，但 Google 會默默把你從 rich result 資格裡踢掉。所以光看測試通過就放心，是常見的盲點。

Rich result 消失時的診斷順序

版位消失後先確認功能還存在，不要立刻重寫 JSON-LD。Google 會停止支援部分搜尋功能，FAQ rich result 就在 2026 年 5 月 7 日停止顯示，相關文件其後也被移除。若功能已退場，頁面沒有技術修復可做；保留 Schema.org 標記可能只剩其他系統或內部資料交換用途。功能仍存在時，再查目標頁是否可索引、Google 選的 canonical 是否正確、robots.txt 是否阻擋爬取、noindex 是否排除索引，以及登入限制是否讓 Google 無法存取內容。

接著用 URL Inspection 看 Google 取得的頁面與渲染結果，再用 Rich Results Test 檢查目前版本。測試通過只代表語法與部分資格條件成立，不代表一定顯示。Search Console 的 rich result status report 用來看整批有效、警告與無效項目的變化；Manual Actions report 則確認是否有 structured data 人工處置。Google 說明，這類人工處置會讓頁面失去 rich result 資格，不會直接改變一般網頁搜尋排名（見 Google 的一般結構化資料規範）。

技術與政策都沒問題時，才進入呈現層診斷：標記是否代表頁面主要內容、可見資料是否完整且最新、特定查詢與裝置是否仍出現該版位、排名或 SERP 組成是否改變。抽樣時保留日期、查詢、裝置、國家與截圖，不用單次人工搜尋下結論。修正後讓 Google 重新檢索，觀察有效項目與 Search appearance；不要用反覆送出索引要求取代等待。這個順序能把「功能退場、索引問題、渲染錯誤、政策不符、演算法未採用」分開，避免把所有消失都歸因成 Schema 壞掉。

不同站點類型的 Schema 優先順序

不同類型的網站，Schema 的優先順序完全不同。給你一個按站點類型的判斷框架。

內容站、媒體、部落格可評估 Article（常見建議欄位包括 author、datePublished、publisher、headline）、BreadcrumbList、Organization、Person。FAQ rich result 已在 2026 年 5 月停止顯示，HowTo rich result 也已停止支援，不要再以取得這兩種 Google 版位為理由投入。頁面真的有內嵌影片時，再評估 VideoObject。要把多支影片組織成單一主題頁，VideoObject、ItemList 與編輯評註該怎麼搭配，可以參考YouTube 策展頁的標記做法。

電商的優先級是 Product（含 offers、aggregateRating、brand、sku）、BreadcrumbList、Organization、Review。Product 的 offers 必須與可見價格同步，aggregateRating 必須來自真實評論系統。ItemList 在分類頁可以考慮，幫助 Google 理解一整組產品的關係。

本地商家的優先級是 LocalBusiness（含 address、openingHours、telephone、aggregateRating）、Organization、BreadcrumbList。LocalBusiness 與 Google Business Profile 的資料要一致，兩邊不同步會扣分。營業時間、地址、電話這三項是最容易不同步的。

SaaS 與服務站的優先級是 Organization、WebPage（含 breadcrumb）、SoftwareApplication（如果是軟體產品）、Person（作者或團隊頁）。SaaS 站很少有 rich result 機會，但 Organization 與 SoftwareApplication 對知識面板與實體識別有幫助。

論壇與 UGC 的優先級是 QAPage（問答頁）、BreadcrumbList。問答格式對 AI 引用相對友善，但政策門檻高，需要真實的社群問答而不是自問自答。

活動與票務的優先級是 Event（含 startDate、endDate、location、offers）、Organization。Event 對真實性要求極高，過期活動要即時移除，否則整站的 Event 標記可信度會被拖累。

從這個分配可以看出，Organization 與 BreadcrumbList 是跨類型的最大公約數。任何網站如果只做一件事，先做這兩個。它們的實作成本最低、政策風險最小、對索引與實體識別的幫助最穩定。

台灣本地站的 Schema 細節：幣別、地址、營業時間與語系

英文教學直接搬到台灣會踩到一批本地化的坑。這些不是邊角細節，而是會直接讓 rich result 失效或顯示錯亂的硬傷。

價格欄位是最常見的問題。Product 的 offers.priceCurrency 必須填 TWD，不是 NT$ 也不是新台幣；price 填純數字 1290，不能寫 NT$1,290 或 1290元。幣別與數字分屬兩個欄位是 Schema.org 的硬規則，混在一起就解讀失敗。庫存欄位 availability 要用完整的 Schema.org URL（https://schema.org/InStock），不能只寫 InStock 字串。

地址是另一批錯誤來源。LocalBusiness 的 address 必須用 postalAddress 結構，把縣市、區、街道分到 addressRegion、addressLocality、streetAddress 三個欄位，不能整串塞進 streetAddress。台灣地址的書寫順序是從大到小（縣市到門號），與英文相反，但 Schema 欄位不分前後順序，只要分對欄位即可。郵遞區號 postalCode 應依中華郵政現行 3 加 3 六碼資料填寫。

營業時間 openingHoursSpecification 是台灣服務業最容易標錯的欄位，因為多數店家中午有午休、週末營業時間不同。正確做法是把每個時段拆成獨立的 opens 與 closes 區塊，例如平日一個 09:00 到 12:00、另一個 13:30 到 18:00，週末另開一組。整段塞 09:00 到 18:00 會讓 Google 誤判午休時間有營業，本地搜尋帶來的到店體驗會直接受影響。

語系層面，inLanguage 應依實際內容選用合法的 BCP 47 標籤；zh-TW 本身有效，需要明示字體時也可用 zh-Hant-TW，不要宣稱只有一個正確值。統一編號可依用途使用 Organization 的 taxID，或用 identifier 搭配 PropertyValue；Google rich result 未必採用這些欄位。

結構化資料如何餵養 Google 的知識圖譜

前面談的多是 Schema 在 SERP 版位上的作用，但結構化資料還有一條長期、複利型的回報路徑，叫做知識圖譜（Knowledge Graph）。當你搜尋一個品牌名、一家公司、一個公眾人物，結果頁右側有時會跳出一個資訊面板，裡面有 Logo、官方網站連結、社群帳號、成立時間、簡介。那個面板背後的資料庫，就是知識圖譜。

知識圖譜的本質，是 Google 把網路上抓到的各種資訊，整理成一張「實體與實體之間關係」的巨大地圖。某家公司屬於哪個產業、它的創辦人是誰、它在哪些平台有官方帳號、它的 Logo 長什麼樣。Google 用這張圖譜來理解世界，也用它來即時組裝答案。

這張圖譜的原料，一部分是 Google 自己爬來推論的，很大一部分是靠站長用結構化資料主動投餵。當你在首頁用 Organization Schema 標記公司名稱、Logo、官方網址、社群連結，等於在幫 Google 的知識圖譜校正你這個實體的資料。標記得越完整越正確，Google 越不容易把你跟另一個同名公司搞混，也越有機會在搜尋你品牌名時，秀出一個漂亮的資訊面板。這跟前面的實體識別是同一條線：實體是知識圖譜的節點，結構化資料是你在幫這些節點補上正確的屬性與連結。對 Entity SEO 有興趣可以延伸讀Entity SEO 的核心概念。

Google 官方也把這些呈現方式整理成一份清單，讓你知道哪些類型的內容有機會爭取豐富結果。重點是：豐富結果不是你寫了標記就保證出現，Google 還會看你的內容品質、標記是否正確、是否違反規範，但標記是入場券，沒有標記連被考慮的機會都沒有。

點擊率才是結構化資料的實質回報

Schema 既然不是排名的直接開關，那它的報酬到底從哪裡回收？答案是點擊率。豐富結果的真正價值，是在不動排名的前提下，讓更多人心甘情願點你。

用具體場景體會最有感。兩個賣同一支耳機的電商頁面，排名差不多。一個站沒有任何結構化資料，搜尋結果就是乾乾的標題加描述。另一個站標記了 Product Schema，搜尋結果上直接秀出 4.6 顆星評分、特價 2990 元、寫著「庫存中」。同樣在第五名的位置，多數人會點後者，因為它在視覺上更可信、資訊也更完整。

這個直覺有數據支撐。Backlinko 在 2025 年 4 月分析過 400 萬筆 Google 搜尋結果，發現排名第一的結果大約吃掉整頁近三成的點擊，而結果頁上的各種視覺豐富元素會明顯改變使用者的視線分布與點擊行為。換句話說，結構化資料的因果鏈是：標記 → 豐富結果 → 更高的點擊率 → 這些行為訊號回流影響整體表現。它不是直接因素，卻是一條重要的間接路徑。想知道 SERP 上還有哪些元素在影響點擊，可以看SERP 搜尋結果頁全解析。

用 Search Console 量化 Schema 的實際報酬

Schema 既然不是排名開關，要說服團隊或自己繼續投入，就必須能量化它的報酬。很多人標完 Schema 就停在那裡，從來沒回頭量過到底換到了什麼，這也是很多 Schema 專案做完就荒廢的原因，因為沒人講得出它賺回了什麼。

量化的核心工具是 Search Console 的成效報告，搭配增強項目或 rich result report 交叉看。先用 rich result report 驗證標記的資格與錯誤狀態，再到 Performance 的 Search appearance 確認實際曝光；前者不能證明豐富結果真的顯示過。

量測時可採同頁前後比較，並按相近查詢、位置與裝置分層。即使觀察到 CTR 差異，也可能受排名、查詢、裝置、版面與頁面品質影響，因此只能視為觀察性差異，不能用兩組平均直接證明 Schema 的因果溢酬。

Product 的 CTR 變化沒有可通用的固定範圍，應以實際 Search appearance 量測。Article 則只量實際可觀察的搜尋呈現與錯誤狀態；若要評估品牌搜尋或 AI 引用，需另設研究方法，且不可把結果歸因給 Article Schema。

與 AI 搜尋同向：結構化輸出的收斂

把生成式摘要系統視為 Schema 的第三種讀者之後，還有一個更長期的方向要思考。OpenAI 在 2024 年推出 Structured Outputs，讓模型在輸出時強制遵守你指定的 JSON 結構。從 Schema.org 到 Structured Outputs，整個網路世界正在往同一個方向收斂：用結構化、機器可讀的格式交換資訊。你用 JSON-LD 標記的 Product、Article、FAQ，正好也是 AI 模型最順口的資料格式。

這個收斂對在地商家尤其關鍵。一家診所的營業時間、地址、電話、看診科別，如果只寫在網頁文字裡，AI 在組裝「我家附近週日還開的牙醫」這種答案時很可能抓錯；用 LocalBusiness 把這些欄位結構化標記清楚，等於直接把一份機器可即取即用的營業名片交出去，出錯率自然降低。

這也把結構化資料拉進一個更大的新戰場，叫做 GEO（Generative Engine Optimization，生成式引擎優化）。它的核心邏輯跟傳統 SEO 一脈相承：讓你的內容對機器來說最容易正確理解、最容易可信引用，你就更容易成為 AI 答案裡被點名的那一個。想理解 SEO 與 GEO 的差異與機會，可以看GEO 是什麼，延伸閱讀可以看品牌如何在 AI Overviews 勝出與品牌要成為被推薦的答案。