結構化資料是什麼？Schema 標記與網站 SEO 實作重點

結構化資料是什麼？先釐清這裡講的是 SEO Schema 標記

結構化資料是用標準化格式描述網頁內容的標記，讓 Google 更容易理解頁面上的實體、屬性與關係，並有機會產生複合式搜尋結果。

在 SEO 語境裡，結構化資料通常指網站在 HTML 中加入 Schema.org 詞彙，例如文章作者、商品價格、庫存狀態、麵包屑路徑、常見問題與影片資訊。這些標記主要給搜尋引擎讀取，使用者不一定會在畫面上直接看到。

結構化資料與 Schema 常被混用，但兩者不完全相同。結構化資料是標記方法，Schema.org 是常用的詞彙標準，JSON-LD 則是多數網站實作時最建議採用的格式。陳建宏建議，網站經營者先把它理解成「幫搜尋引擎讀懂頁面的欄位說明」，不要一開始就把它想成工程專案。

名詞	意思	網站經營者要理解的重點
結構化資料	用標準化格式描述頁面內容	幫搜尋引擎判斷頁面在講什麼
Schema.org	定義物件與屬性的詞彙表	例如 Article、Product、BreadcrumbList
Schema 標記	把 Schema.org 詞彙實際放到網站中	通常用 JSON-LD 寫進頁面
Rich Results	Google 搜尋結果中的強化呈現	符合資格才有機會顯示，不保證出現

SEO 的結構化資料和一般資料工程的結構化資料差在哪裡？

資料工程談的結構化資料，多半是在資料庫、表格、欄位、資料倉儲中討論資料格式。SEO 談的結構化資料，重點是網頁內容如何被搜尋引擎理解。

例如商品頁上的「價格」「庫存」「評分」對使用者來說是頁面內容，對 Google 來說，如果再用 Product、Offer、AggregateRating 標記清楚，就更容易判斷這是一個可購買的商品頁。

Schema.org 是詞彙表，Google 複合式搜尋結果有自己的規範

Schema.org 提供很多類型與屬性，但 Google 不會針對每一種 Schema 都給特殊搜尋呈現。網站實作時要同時看 Schema.org 的定義，以及 Google 支援的結構化資料項目。

實作時建議先從 Google 明確支援的項目開始，例如 Article、Breadcrumb、Product、FAQ、Video、LocalBusiness。這樣比較容易把工作量放在會影響搜尋呈現資格的地方。

結構化資料會出現在畫面上嗎？

多數 JSON-LD 結構化資料不會直接顯示在頁面畫面上，而是放在 HTML 程式碼中供搜尋引擎讀取。不過標記的內容必須和使用者看得到的頁面內容一致。

如果頁面沒有顯示評論，卻在 Schema 裡標記 Review；如果商品已缺貨，卻仍標示 InStock，這些都可能讓 Google 判定標記不可信。

為什麼網站要做結構化資料？它真正影響的是搜尋呈現與理解

網站做結構化資料的主要價值，是提高 Google 理解頁面的能力，並讓頁面符合特定複合式搜尋結果的資格，進而增加被點擊的機會。

它不是單一排名開關，也不應被包裝成保證排名工具。比較合理的期待是：讓搜尋引擎更清楚知道頁面是文章、商品、影片、商家、FAQ 或網站導覽，並在條件符合時取得更好的搜尋結果呈現。

• 幫助 Google 辨識品牌、作者、商品、服務與頁面層級。
• 讓頁面有機會取得商品結果、麵包屑、文章資訊、影片資訊等強化呈現。
• 降低搜尋引擎誤解頁面主題的機率。
• 讓 SEO 團隊能在 Search Console 追蹤有效項目、警告與錯誤。

可能觸發的搜尋結果強化：麵包屑、商品、評分、FAQ、影片、文章

常見的強化搜尋呈現包括麵包屑路徑、商品價格與庫存、評論評分、影片縮圖、文章標題與日期等。每一種呈現都有自己的資格條件，不是只要加上標記就會出現。

FAQPage 也要特別保守看待。依 Google 目前規範，FAQ 複合式搜尋結果主要限於知名且具權威性的政府或健康網站；一般商業網站仍可把 FAQ 做好給使用者看，但不該期待每個 FAQ 標記都能換到版位。

對 AI 搜尋與實體理解的幫助

結構化資料能把頁面中的人、品牌、組織、商品、地點與內容類型標示得更清楚。當搜尋系統或 AI 搜尋需要理解網站主題時，這些標記可作為輔助訊號。

陳建宏建議，品牌網站至少要把 Organization、WebSite、作者資訊與主要頁面的 BreadcrumbList 做穩。這些基礎標記不一定最搶眼，但對長期建立網站實體關係很有價值。

為什麼不能說加 Schema 一定會排名上升？

Google 官方文件明確說明，即使結構化資料通過測試，也不保證會在搜尋結果中顯示 Rich Result。結構化資料能提供資格與理解訊號，但排名仍受內容品質、相關性、網站技術狀態、連結、使用者需求等因素影響。

比較務實的說法是：Schema 標記可以改善搜尋引擎讀取頁面的精準度，也可能改善搜尋結果呈現，但不能把所有 SEO 成效都歸因給它。若網站速度、內容品質或索引狀態有問題，建議同步檢查 Core Web Vitals 與整體網站技術 SEO。

Schema.org、Google 支援項目與 JSON-LD 的關係

Schema.org 提供詞彙，Google 決定哪些標記可取得複合式搜尋結果資格，JSON-LD 則是網站加入結構化資料時最常用、也最容易維護的格式。

這三者的分工要先弄清楚，否則很容易出現「Schema.org 有這個類型，所以 Google 一定會顯示特殊結果」的誤會。實作時應以 Google Search Central 文件作為搜尋呈現規範，再用 Schema.org 補充欄位語意。

項目	角色	實作判斷
Schema.org	詞彙來源	用來定義 Article、Product、Organization 等類型
Google 支援項目	搜尋呈現規則	判斷是否有 Rich Results 機會
JSON-LD	標記格式	建議用來放在頁面 HTML 中，維護成本較低

Schema.org：定義物件、屬性與關係

Schema.org 像是一套共用詞彙。它定義「文章可以有哪些屬性」「商品可以有哪些欄位」「組織和網站之間有什麼關係」。

對 SEO 來說，不需要背完整詞彙表。更重要的是知道自己的頁面屬於哪一種內容，然後選擇相符的 Schema 類型。

Google 支援項目：決定是否有 Rich Result 機會

Google 支援的結構化資料項目，才是判斷搜尋強化呈現資格的核心。頁面標記即使符合 Schema.org，也可能不會產生 Google Rich Result。

因此，文章頁先看 Article 文件，商品頁先看 Product 文件，FAQ 頁先看 FAQPage 文件。不要把冷門 Schema 類型當成主要 SEO 工作。

JSON-LD：最推薦的網站實作格式

Google 支援 JSON-LD、Microdata、RDFa 三種格式，實務上多數網站建議採用 JSON-LD，因為它和頁面可見 HTML 分開，較容易由 CMS、模板或後台欄位統一管理。

不建議同一頁混用多種格式描述同一件事。標記來源越分散，越容易出現作者、日期、價格、庫存不同步的問題。

常見結構化資料類型：先從這 8 種開始

大多數網站不需要一次處理所有 Schema 類型，先從 Article、Organization、Product、BreadcrumbList、FAQPage、Review、VideoObject、LocalBusiness 這 8 種開始最實用。

選型的原則很直覺：文章頁用文章類型，商品頁用商品類型，影片頁用影片類型，在地商家頁才用 LocalBusiness。陳建宏建議，不要把 Schema 當成可以到處套用的模板，它應該跟頁面真正內容對齊。

Schema 類型	適用頁面	主要用途	注意事項
Article / BlogPosting	文章、部落格、新聞內容	標示標題、作者、日期、圖片、發布者	作者與日期要和頁面一致
Organization	首頁、關於我們	標示品牌、Logo、網站、社群資料	品牌名稱要全站一致
Product	商品頁	標示價格、庫存、評價、商品資訊	價格與庫存需同步更新
BreadcrumbList	多層級網站頁面	標示頁面所在路徑	不要和畫面麵包屑不一致
FAQPage	真正有問答內容的頁面	標示問題與答案	一般網站不應期待 FAQ Rich Result 穩定顯示
Review / AggregateRating	有真實評論的商品或服務頁	標示評價與平均分數	不得標記不存在或不可見的評論
VideoObject	影片頁、內嵌影片文章	標示影片標題、縮圖、上傳日期、長度	影片內容要能被 Google 存取
LocalBusiness	在地店家、服務據點	標示地址、電話、營業時間、服務區域	資料要和商家資訊一致

Article / BlogPosting：文章與部落格內容

Article 或 BlogPosting 適合部落格文章、教學文、知識型內容。常見欄位包括 headline、author、datePublished、dateModified、publisher。

如果網站長期經營內容集群，例如 Website SEO、架站、電商網站成本等主題，Article 標記能幫助搜尋引擎理解內容資產與作者關係。

Organization / LocalBusiness：品牌、公司與在地商家

Organization 適合品牌或公司網站，LocalBusiness 適合有實體服務區域、地址或店面的商家。兩者不要隨便互換。

如果網站是全台服務的公司，通常先用 Organization，再依實際據點補 LocalBusiness。若是單一門市或診所，LocalBusiness 的地址、電話與營業時間就很重要。

Product / Review / AggregateRating：商品、評價與價格資訊

Product 是電商網站最常見的 Schema 類型，通常會搭配 Offer、Review 或 AggregateRating。商品名稱、價格、幣別、庫存狀態、評分都要和頁面可見資訊一致。

WooCommerce、Shopify 等平台常會自動產生一部分商品 Schema，但主題、外掛或客製欄位也可能造成重複或缺漏。電商網站也應同步檢查 電商平台比較 與 電商網站成本 中牽涉的系統可維護性。

BreadcrumbList / FAQPage / VideoObject：導航、問答與影片內容

BreadcrumbList 幾乎適合所有有清楚網站層級的頁面，對大型內容站、分類頁、產品頁尤其重要。FAQPage 只適合頁面真的有問答內容時使用。

VideoObject 適合影片是頁面核心內容的情境，例如教學影片、產品示範、課程片段。若影片只是裝飾或無法被 Google 存取，標記價值就很低。

頁面類型 × Schema 類型對照表：不同頁面不要套同一份標記

不同頁面應使用不同 Schema 類型；首頁、文章頁、產品頁、分類頁、服務頁、FAQ 頁、影片頁與聯絡頁，都應有各自的標記策略。

這是結構化資料實作最容易拉開差距的地方。很多網站不是完全沒做 Schema，而是每頁都套同一份 Organization 或 FAQ，導致標記缺乏頁面語意。

頁面類型	推薦 Schema	必要或重要欄位	常見錯誤	Rich Result 機會
首頁	Organization、WebSite、SearchAction	品牌名、Logo、網址、站內搜尋 URL	品牌名稱和頁尾、社群資料不一致	品牌理解、站內搜尋框資格
文章頁	Article、BreadcrumbList	標題、作者、發布日期、更新日期、發布者	作者不存在、日期和頁面不同	文章強化呈現、麵包屑
產品頁	Product、Offer、Review、AggregateRating	價格、幣別、庫存、商品名稱、評價	缺價格、庫存過期、假評論	商品結果、評分、價格資訊
分類頁	BreadcrumbList、CollectionPage	分類名稱、路徑、頁面描述	把分類頁硬標成單一 Product	麵包屑、分類理解
服務頁	Service、Organization、BreadcrumbList	服務名稱、服務區域、提供者	服務內容太空泛，和頁面文案不一致	服務實體理解
FAQ 頁	FAQPage	問題、答案、頁面可見內容	頁面沒有顯示的問答也標記	特定權威網站才較可能有 FAQ Rich Result
影片頁	VideoObject、BreadcrumbList	影片名稱、描述、縮圖、上傳日期、影片 URL	縮圖無法存取、影片不是主要內容	影片搜尋呈現
聯絡頁	Organization、LocalBusiness	電話、地址、營業時間、服務區域	電話格式混亂、地址和商家資料不同	品牌與在地資訊理解

首頁：Organization、WebSite、SearchAction

首頁最重要的是讓 Google 確認品牌實體、官方網站與站內搜尋功能。Organization 可標示品牌名稱、Logo、網址、sameAs 社群連結；WebSite 可標示網站名稱與網址。

若網站有站內搜尋功能，可評估 SearchAction，但前提是搜尋結果頁真的能正常運作。沒有站內搜尋，就不要為了看起來完整而硬加。

文章頁：Article、BreadcrumbList、作者與日期

文章頁應把標題、作者、發布日期、更新日期與發布者標清楚。作者資訊不能只存在 Schema，頁面上也應讓讀者看得到。

如果文章屬於網站 SEO 主題群，可在正文中自然連到 CMS 選擇指南、網域名稱指南 等相關頁，讓內鏈與結構化資料一起支援主題理解。

產品頁：Product、Offer、Review、AggregateRating

產品頁的 Schema 最需要維護，因為價格、庫存與評價會變動。Offer 欄位中的 price、priceCurrency、availability 應該跟前台與後台商品資料同步。

實作時建議由商品資料庫或 CMS 商品欄位自動產生，不要人工貼一段固定 JSON-LD。人工固定碼很容易在促銷、缺貨或改價時失準。

服務頁 / 分類頁 / FAQ 頁 / 影片頁各自適合的 Schema

服務頁可以用 Service 搭配 Organization，但內容必須描述實際提供的服務，不要只放品牌口號。分類頁通常以 BreadcrumbList、CollectionPage 為主，避免把整個分類頁標成單一商品。

FAQ 頁只有在頁面真的有問答時才適合 FAQPage。影片頁則要確定影片是核心內容，並提供可抓取的縮圖、影片 URL 與上傳日期。

如何在網站加入 Schema.org 結構化資料？JSON-LD 實作流程

網站加入 Schema.org 結構化資料的流程，是先選對頁面類型，再用 JSON-LD 填入欄位，放進頁面 HTML 或 CMS，最後用工具測試並上線追蹤。

不要一開始就找一段通用程式碼貼上。正確流程應該從頁面目的出發：這頁是文章、商品、分類、服務、影片，還是聯絡頁？選對類型後，欄位才有意義。

1. 判斷頁面類型與想取得的搜尋呈現資格。
2. 選擇 Google 支援且符合內容的 Schema 類型。
3. 用 JSON-LD 建立標記，欄位資料來自 CMS 或後台。
4. 放進 HTML 的 head 或 body 中。
5. 用 Rich Results Test 與 Search Console 檢查。
6. 上線後定期檢查錯誤、警告與欄位同步。

Step 1：先判斷頁面類型與搜尋結果目標

先問一個問題：這個頁面最希望 Google 理解的主體是什麼？如果是文章，就優先處理 Article；如果是商品，就處理 Product；如果是公司資訊，就處理 Organization 或 LocalBusiness。

搜尋結果目標也要保守。想讓產品有價格與庫存呈現，就要確保商品資料完整；想讓影片被理解，就要提供 VideoObject 需要的影片資訊。

Step 2：用 JSON-LD 建立標記

JSON-LD 是一段以 JSON 格式撰寫的資料，通常放在 script 標籤中。以下是文章頁常見的簡化範例，實際欄位仍要依 Google 文件與網站內容調整。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "結構化資料是什麼？Schema.org 標記、JSON-LD 實作與檢查清單",
  "author": {
    "@type": "Person",
    "name": "陳建宏"
  },
  "publisher": {
    "@type": "Organization",
    "name": "makewebsites.tw"
  },
  "datePublished": "2026-05-23",
  "dateModified": "2026-05-23",
  "mainEntityOfPage": "https://makewebsites.tw/posts/structured-data"
}
</script>

這段範例的重點不是複製，而是看懂欄位邏輯：標題對應頁面 H1 或主要標題，作者對應頁面上的作者，發布者對應網站品牌，日期對應文章實際發布與更新時間。

Step 3：放進頁面 HTML 或 CMS 欄位

自架網站可以把 JSON-LD 放在模板中，由後台欄位自動帶入標題、作者、日期、商品價格等資料。WordPress 或 Shopify 則常由主題、SEO 外掛或電商系統自動產生一部分。

實作時建議讓 Schema 資料來源盡量集中。若 SEO 外掛產生 Article，主題又額外產生另一份 Article，就可能出現重複或欄位衝突。

Step 4：確認標記內容和頁面可見內容一致

Google 的結構化資料規範要求標記內容能代表頁面主要內容，且不能誤導使用者。頁面沒有顯示的價格、評分、FAQ、營業時間，不應只出現在 Schema 裡。

陳建宏建議把這件事納入上稿流程：內容發布前檢查標題、作者、日期、麵包屑；商品上線前檢查價格、庫存、評分；改版前檢查模板是否還會輸出正確 JSON-LD。

台灣常見網站平台怎麼做：WordPress、WooCommerce、Shopify、自架網站

不同平台產生 Schema 的方式不同；WordPress 常靠 SEO 外掛，WooCommerce 與 Shopify 會輸出商品資料，自架網站則應把 Schema 欄位納入內容模型。

平台不是重點，資料來源才是重點。只要價格、庫存、作者、日期、麵包屑來自正確欄位，Schema 就比較容易長期維護。

平台	常見 Schema 來源	可控程度	檢查重點
WordPress	SEO 外掛、主題、麵包屑外掛	中高	Article、作者、日期、Breadcrumb 是否重複
WooCommerce	商品系統、SEO 外掛、評價模組	中高	Product、Offer、庫存、評分是否同步
Shopify	佈景主題、商品資料、App	中	商品價格、幣別、庫存、重複標記
Webflow	自訂程式碼、CMS 欄位	中	CMS 欄位是否正確帶入 JSON-LD
自架網站 / 客製 CMS	模板、資料模型、後台欄位	高	是否把 Schema 納入發布流程與測試流程

WordPress：SEO 外掛會產生一部分，但仍要檢查作者、麵包屑與文章類型

WordPress 網站常用 SEO 外掛自動產生 Article、WebSite、Organization 與 BreadcrumbList。這能省下不少基礎工作，但不代表上線後就不用檢查。

常見問題包括作者頁不存在、文章更新日期沒有同步、麵包屑和畫面路徑不同、主題與外掛重複輸出 Schema。更換主題或外掛後，應重新跑一次 Rich Results Test。

WooCommerce / Shopify：商品價格、庫存、評價要同步

電商平台最重要的是商品資料同步。Product Schema 中的 price、availability、review、aggregateRating，如果和前台商品頁不同，就會降低標記可信度。

促銷檔期、缺貨、換幣別、多規格商品，是最容易出錯的情境。商品資料頻繁變動的網站，不適合用人工固定碼管理 Product Schema。

自架網站 / 客製 CMS：建議把 Schema 欄位納入內容模型

自架網站最大的優勢是可控，但也最容易漏掉治理。建議在 CMS 內容模型中直接設計作者、發布日期、更新日期、商品價格、庫存、服務區域等欄位，再由模板輸出 JSON-LD。

這樣內容、前台畫面與 Schema 會來自同一套資料。長期來看，比人工貼碼更穩，也比較適合大型內容站或多語系網站。

上線前怎麼驗證？Rich Results Test、Search Console 與錯誤解讀

結構化資料上線前應用 Rich Results Test 檢查資格，上線後用 Search Console 追蹤有效項目、警告與錯誤，必要時再用 Schema Markup Validator 看 Schema.org 通用語法。

驗證工具的角色不同。Rich Results Test 看 Google Rich Results 資格；Schema Markup Validator 看 Schema.org 標記；Search Console 則看 Google 實際抓取後的狀態。

1. 先用 Rich Results Test 測試草稿頁或上線 URL。
2. 修正必要欄位缺失與語法錯誤。
3. 確認頁面可見內容和 Schema 欄位一致。
4. 上線後用 Search Console 的強化項目報告追蹤。
5. 改版、換主題、換外掛、調整商品欄位後重新驗證。

Rich Results Test：確認是否符合 Google 複合式搜尋結果資格

Rich Results Test 可以測試 Google 能否讀到結構化資料，以及該頁是否符合特定 Rich Result 資格。若工具顯示不支援某種 Rich Result，代表 Google 不一定會用那段標記產生特殊呈現。

測試通過只代表技術上符合基本條件，不代表搜尋結果一定顯示。這一點在對內溝通時要講清楚，避免把測試通過當成成效保證。

Search Console：追蹤有效項目、警告與錯誤

Search Console 的強化項目報告可以看到 Google 已偵測到哪些結構化資料，以及有效、警告、錯誤的狀態。這比只在本機測一頁更接近真實搜尋狀況。

有效代表 Google 可讀取並接受該項目；警告通常表示可用但有建議改善欄位；錯誤則可能使該頁失去對應 Rich Result 資格。修正後可送出驗證，讓 Google 重新檢查。

常見錯誤訊息怎麼判斷優先順序

優先處理會影響資格的錯誤，例如必要欄位缺失、JSON 語法錯誤、標記內容和頁面不一致。警告欄位則依影響程度安排修正，不一定每個警告都需要立刻處理。

實務上，商品頁的價格與庫存錯誤通常比文章頁缺少次要欄位更急。因為商品資訊錯誤會直接影響使用者信任，也容易造成搜尋呈現資格問題。

結構化資料的常見錯誤與修正方式

結構化資料常見錯誤包括必要欄位缺失、內容不一致、錯用 Schema、假評論、過期活動與 JSON 語法錯誤；修正重點是讓標記回到真實頁面內容。

錯誤不只會讓 Rich Result 失效，也會增加維護成本。對內容站與電商站來說，最好的做法不是等 Search Console 報錯才修，而是把 Schema 檢查納入發布與改版流程。

錯誤	常見原因	可能影響	修正方式	檢查工具
必要欄位缺失	Product 沒有價格或庫存	失去商品 Rich Result 資格	補齊後台欄位並同步輸出	Rich Results Test、Search Console
內容不一致	Schema 標記頁面沒有顯示的評論	降低信任，可能違反規範	移除標記或讓頁面顯示真實內容	人工檢查、Search Console
錯用 Schema	分類頁硬塞 Product 或 FAQ	Google 無法正確理解頁面	改用 CollectionPage、BreadcrumbList 等相符類型	Rich Results Test
JSON 語法錯誤	逗號、引號、巢狀格式錯誤	整段 JSON-LD 無法被讀取	修正語法並重新測試	Rich Results Test、Schema Markup Validator
過期資訊	活動、價格、庫存沒有更新	搜尋呈現與使用者期待不一致	改由 CMS 或資料庫自動帶入	Search Console、人工抽查

欄位缺失：Product 沒有 price 或 availability

Product Schema 如果缺少 price、priceCurrency、availability 等關鍵欄位，就可能無法取得商品相關搜尋呈現。這通常發生在商品資料沒有填完整，或模板沒有把後台欄位輸出到 JSON-LD。

修正時不要只補 Schema，要回頭檢查商品後台欄位是否完整。若後台資料本身不穩，前台和 Schema 都會跟著不穩。

內容不一致：頁面沒有顯示的評論卻標記 Review

Review 與 AggregateRating 必須對應真實、可見、和該頁內容相關的評論。頁面沒有評論區，卻標記五星評分，是高風險做法。

修正方式很直接：沒有真實評論就不要標記 Review；有評論就讓頁面可見內容、後台資料與 Schema 三者一致。

錯用 Schema：分類頁硬塞 Product 或 FAQ

分類頁通常是一組商品或文章的集合，不應直接標成單一 Product。服務頁也不該因為想取得 FAQ 呈現，就把頁面沒有的問答塞進 FAQPage。

選錯類型會讓搜尋引擎接收到混亂訊號。頁面類型越清楚，Schema 的價值越高。

JSON 語法錯誤：逗號、引號、巢狀格式出錯

JSON-LD 對格式很敏感，少一個逗號、多一個引號、巢狀括號錯位，都可能讓整段標記失效。這類錯誤常發生在人工複製貼上範例碼時。

建議由模板或 CMS 自動產生 JSON-LD，再用測試工具驗證。若必須人工修改，至少在上線前跑一次 Rich Results Test。

三階段實作策略：先做基礎，再做 Rich Result，再做治理

結構化資料不必一次做完；比較穩的路線是先完成基礎標記，再處理可帶來搜尋呈現機會的標記，最後建立欄位同步與定期檢查機制。

很多網站卡住，是因為一開始就想把所有 Schema 做滿。實作時建議用成熟度分階段推進，先把最常見、最不容易出錯、最能支援網站架構理解的項目做好。

階段	優先 Schema	檢查標準	維護頻率
Level 1 基礎	Organization、WebSite、BreadcrumbList、Article	品牌、網站、麵包屑、作者與日期一致	改版或新增模板時檢查
Level 2 搜尋呈現	Product、FAQPage、VideoObject、LocalBusiness	符合 Google 支援項目與頁面內容	內容或商品資料變動時檢查
Level 3 維護治理	全站模板與內容模型	Schema 欄位和 CMS、前台內容同步	每月或每次重大發布後檢查

Level 1：Organization、WebSite、Breadcrumb、Article

基礎階段先處理全站都用得到的標記。Organization 與 WebSite 建立品牌和網站關係，BreadcrumbList 幫助理解頁面層級，Article 則支援內容站的文章理解。

如果網站還在規劃 CMS 或改版，應同步考慮 CMS 選型 是否能穩定管理作者、日期、分類與麵包屑。

Level 2：Product、FAQ、Video、LocalBusiness

第二階段處理和搜尋呈現更直接相關的標記。電商網站優先 Product；有影片內容的網站優先 VideoObject；有店面或服務區域的商家優先 LocalBusiness。

FAQPage 要謹慎使用。頁面有真實問答仍可標記，但一般網站不應把它視為穩定取得 FAQ Rich Result 的手段。

Level 3：欄位同步、內容模型、Search Console 追蹤

成熟階段的重點是治理。價格、庫存、作者、日期、評分、營業時間都會變，這些欄位若不能自動同步，Schema 很快會過期。

建議建立固定檢查清單：每月看 Search Console 強化項目，重大改版後跑 Rich Results Test，商品欄位調整後抽查 Product Schema。這比一次性導入更能保護長期成效。

如何衡量結構化資料成效？不要只看有沒有排名上升

結構化資料成效應看搜尋呈現資格、有效項目數、錯誤數、曝光、點擊、CTR 與實際 Rich Result 呈現，不應只用排名變化判斷。

Schema 的成效常出現在「搜尋結果更清楚」「CTR 改善」「錯誤減少」「商品或麵包屑呈現更穩」這些地方。若只盯單一關鍵字排名，很容易低估或誤判它的價值。

指標	查看工具	判讀方式	限制
有效項目數	Search Console 強化項目	有效頁面增加代表 Google 讀取狀態改善	有效不等於一定顯示 Rich Result
錯誤與警告	Search Console	錯誤下降代表技術品質改善	警告需依重要性判斷
曝光	Search Console 搜尋成效	觀察標記頁面是否有更多搜尋出現	受排名與需求量影響
點擊與 CTR	Search Console 搜尋成效	觀察搜尋呈現改善後是否更容易被點擊	需排除標題、描述、排名波動影響
Rich Result 呈現	實際 SERP、Rich Results Test	確認商品、麵包屑、影片等是否出現	不同裝置、地區、查詢可能不同

Search Console 強化項目：有效、警告、錯誤

Search Console 的強化項目報告，是追蹤 Schema 健康度的主要入口。有效項目增加，代表 Google 能讀到更多可用標記；錯誤增加，代表需要優先處理。

警告不一定等於失效，但也不該長期忽略。若警告欄位和搜尋呈現高度相關，例如商品評價、價格資訊，就應安排修正。

搜尋成效：曝光、點擊、CTR、查詢與頁面

結構化資料上線後，可以在 Search Console 比較標記頁面的曝光、點擊與 CTR。觀察時要看頁面層級與查詢層級，不要只看全站平均。

若商品頁新增 Product Schema 後 CTR 改善，但排名沒有明顯變動，仍可能代表搜尋呈現更吸引使用者。反過來，若標記有效但 CTR 沒變，也要檢查標題、描述、價格競爭力與頁面內容。

觀察 Rich Result 是否真的出現在 SERP

Rich Results Test 可以確認資格，但實際搜尋結果會受查詢、裝置、地區、搜尋意圖與 Google 系統判斷影響。建議用核心查詢、品牌查詢、商品查詢分開觀察。

實作時建議保存上線前後的測試結果、Search Console 截圖與修正紀錄。當網站改版或流量波動時，這些紀錄能幫助判斷問題來自 Schema、內容、技術或搜尋需求變化。

FAQ

結構化資料是什麼？

結構化資料是用標準化格式描述網頁內容的標記，讓搜尋引擎更容易理解頁面中的文章、商品、品牌、作者、評分、麵包屑或影片等資訊。

結構化資料和 Schema 是一樣的嗎？

不完全一樣。結構化資料是標記方法，Schema.org 是常用詞彙標準，Schema 標記則是把這些詞彙實際放進網站頁面的做法。

SEO 結構化資料和資料庫裡的結構化資料有什麼不同？

資料庫裡的結構化資料重點是資料儲存與欄位管理；SEO 結構化資料重點是用 Schema.org 與 JSON-LD 幫搜尋引擎理解網頁內容。

加了結構化資料會讓排名變好嗎？

不能保證。結構化資料能幫助 Google 理解頁面並取得某些搜尋呈現資格，但排名仍取決於內容品質、相關性、技術狀態、連結與搜尋意圖等因素。

Google 一定會顯示我加的 Rich Result 嗎？

不一定。即使結構化資料通過 Rich Results Test，Google 仍會依查詢、裝置、地區、頁面品質與搜尋結果需求決定是否顯示。

WordPress 網站需要自己加 Schema 嗎？

很多 WordPress SEO 外掛會自動產生部分 Schema，但仍需要檢查作者、日期、麵包屑、Organization 與文章類型是否正確，避免主題和外掛重複輸出。

商品頁最重要的結構化資料欄位有哪些？

商品頁通常要注意商品名稱、價格、幣別、庫存狀態、商品描述、評價與平均評分。價格和庫存尤其要和前台商品頁同步。

FAQPage Schema 還值得做嗎？

如果頁面真的有問答內容，FAQPage 仍可作為清楚描述內容的標記。但一般商業網站不應期待它穩定觸發 FAQ Rich Result，因為 Google 對 FAQ 呈現有更嚴格限制。

結構化資料可以幫助 AI 搜尋理解網站嗎？

可以作為輔助訊號。結構化資料能把品牌、作者、商品、服務、文章與頁面關係標得更清楚，有助於搜尋系統理解網站實體與內容脈絡。

結構化資料錯誤會影響 SEO 嗎？

錯誤標記可能讓頁面失去對應 Rich Result 資格，也可能讓 Google 對標記信任降低。嚴重誤導或違反規範的標記，還可能產生結構化資料相關風險。

我要用 JSON-LD、Microdata 還是 RDFa？

多數網站建議用 JSON-LD。Google 支援這三種格式，但 JSON-LD 比較容易放進模板或 CMS 管理，也比較不會干擾前台 HTML。

結構化資料多久需要檢查一次？

基礎網站可每月檢查 Search Console 強化項目；電商網站、活動頁、常改價格與庫存的網站，應在每次重大更新後重新測試。改版、換主題、換外掛時也要重新驗證。