|

結構化資料:Google 三種都收,偏好 JSON-LD

更新 2026-10-12

網站視覺與 HTML 再完美,若爬蟲無法一致解讀頁面上的事實(例如地址、產品、活動),搜尋結果仍可能吃虧。結構化資料(structured data)是把資訊用有順序、有標準欄位的方式寫下來,讓搜尋引擎與其他系統不必只靠版面猜測語意1。它常出現在 Knowledge Graph、rich snippets、AMP 輪播等 SERP 功能背後;實作得當有助爬蟲理解脈絡,並有機會爭取富結果(不保證顯示)。

目錄(8)

編譯自 Alan Ibbett · Page One Power/Linkarati〈Creating Context with Structured Data〉 · 2018-12-10 原文

完整來源聲明

來源聲明:本文根據 Page One Power/Linkarati〈Creating Context with Structured Data〉(Alan Ibbett,2018-12-10)編譯整理為繁體中文,不是逐句翻譯;涵蓋結構化資料定義、Schema.org 起源、JSON-LD/Microdata/RDFa 取捨、Rich Results 測試與 WordPress 外掛示例。原文未標示開放授權。原文連結:https://pageonepower.com/linkarati/creating-context-with-structured-data。Page One Power 為連結建設與 SEO 服務公司,文中提及外掛與工具存在利益脈絡。文中「編輯解讀」為本站觀點。檢索日期:2026-10-12。

結構化資料是什麼?

「結構化」代表資料必須依約定格式排列。同一筆商家地址可以有多種自然語言寫法——「Main 街綠色大樓外的藍色咖啡車」對當地人可能夠用,但對全國或全球的爬蟲就不夠明確。逐步補上門牌、城市、州、國家會更好, yet 版面設計仍可能讓人類一眼看懂、機器卻抓錯欄位。

結構化資料的目的,是在不犧牲創意版型的前提下,用標準 vocabulary 標明「這是地址的哪一段、這是價格、這是評分」。Google 等引擎對一般文字中的地址抽取已相當強,但並非完美;結構化標記可減少歧義。

標準從哪來:Schema.org

早年有多套競爭的網頁結構化標準。2011 年 Bing、Google、Yahoo 等搜尋引擎共同推動 Schema.org 作為維護 vocabulary 的組織2。當時提出三種語法:JSON-LD、Microdata、RDFa;標準化組織最後三種都採納,對一般站長而言仍是「三選一(或多格式並存)」的學習成本。

若主要目標是 Google,原文指出 Google 三種都支援,但偏好 JSON-LD——通常放在 <script type="application/ld+json">,與可見 HTML 分離,較不會與主題 markup 打架。Microdata 把屬性嵌在標籤上;RDFa 較常見於特定企業或語意網路場景。

如何檢查網站是否已有結構化資料

Google 提供 Rich Results Test(原文連結至測試工具)3:貼 URL 後,左側可看原始 HTML,右側解析出的結構化資料圖。許多 CMS 主題或 SEO 外掛已自動輸出 Product、Article、Breadcrumb 等;第一次測試常會發現「原來已經有」。

看到 JSON 或嵌套屬性不必手打:原文強調可用產生器或外掛,避免人工拼錯引號與括號。

選開發/外掛工具

原文以 WordPress 生態為例(並引用 CodeinWP 關於 WordPress 市占的統計,數字未經本站核實)。搜尋「WordPress structured data plugin」會出現大量外掛;選型要在功能完整度與後台易用性間折衷——功能過強常讓編輯流程變複雜。原文點名「WP SEO Structured Data Schema」(Kansas City SEO)作為平衡示例;本站不背書特定外掛,上線前仍應在測試環境驗證輸出與主題相容。

串起流程:上線前後怎麼量

結構化資料讓搜尋引擎更快、更準確辨識內容類型,但必須符合 Schema.org 定義。動手前先用分析工具建立流量與富結果基線;上線後持續監控自然流量、CTR 與 Search Console 的富結果報表,確認改動帶來預期效果而非標記錯誤。標記與可見內容不一致,可能違反 Google 垃圾內容政策中對結構化資料的規範。

常見問題

  • Google 只接受 JSON-LD 嗎?不是;Microdata、RDFa 也支援,但 Google 文件與原文均建議優先 JSON-LD。
  • 有結構化資料就一定有 rich snippet?不一定;需符合各功能資格,且 Google 決定是否顯示。
  • 2018 年的 WordPress 外掛建議還適用嗎?原理仍適用(用工具產生正確 markup),但外掛名稱與維護狀態應重新評估。
  • 結構化資料與「關鍵字優化」是同一件事嗎?不是;原文強調它是語意脈絡,不是取代 title、內文等 on-page 工作。

編輯解讀

一句話重點:結構化資料是給機器讀的「欄位表」,JSON-LD 通常是 Google 站點最省事的起點,但必須與頁面可見事實一致。

這對你的網站意味著什麼:

  • 新專案預設 JSON-LD 模板(Organization、WebSite、BreadcrumbList),再依內容類型加 Article/Product。
  • 每次改價格、日期、評分時,同步改 markup 與可見區塊。
  • 用 Rich Results Test + GSC 富結果報告做發布前後 diff,不要只看外掛「綠燈」。

適用與不適用的情境:適合需 rich result、知識面板或 AI 摘要引用的實體頁。純形象頁若無可標記事實,不必硬塞 schema。

需要注意的限制:2018 年文章,AMP 輪播等脈絡已變;Page One Power 為 SEO 服務商。CodeinWP 市占數字為原文引用,非 Google 官方。

延伸閱讀:

可沉澱規則 · 供站點自檢2 條

從本文提煉,可供人工對照或 AI 分析站點時作為依據。全部規則

  1. JSON-LD 標記的價格、日期、評分、庫存等必須與頁面可見內容一致;改版時同步更新 markup。

    適用 商品、活動或評論頁上線與改價時
    排除 不要只為富結果虛構欄位
    • Rich Results Test 通過
    • GSC 富結果無錯誤
  2. 新站預設以 JSON-LD 輸出 Organization、WebSite、BreadcrumbList,再依模板加 Article/Product;避免三種語法混用造成重複實體。

    適用 主題或 CMS 結構化資料設定
    排除 不要同頁 Microdata 與 JSON-LD 重複同一 Product
    • 測試工具只解析預期圖譜
    • 外掛輸出已 spot check

名詞與資料來源

  1. Structured data — Google:〈Intro to structured data〉 https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data(檢索:2026-10-12)
  2. Schema.org — Schema.org:〈About〉 https://schema.org/docs/about.html(檢索:2026-10-12)
  3. Rich Results Test — Google:〈Rich Results Test〉 https://search.google.com/test/rich-results(檢索:2026-10-12)
  4. Page One Power:〈Creating Context with Structured Data〉 https://pageonepower.com/linkarati/creating-context-with-structured-data(Alan Ibbett,2018-12-10;檢索:2026-10-12)

Similar Posts

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *